The Crystal Programming Language

by necrodome • 11 years ago

254 171 11 years ago

kibwen9• 11 years ago

Crystal looks like a neat language, and it's fun to see how many entrants there are in the modern renaissance of scripting languages that compile to native code. I wish there was some more documentation about it though... for example, does the bullet point "Never have to specify the type of a variable or method argument" from the home page imply gradual typing as per Dart and TypeScript, or is it something else entirely?

asterite19• 11 years ago

It has global type inference, there's nothing dynamic in the language. You can specify type restrictions to allow overloading methods, for example, or doing multiple dispatch. But in the general case you don't specify types (except for generic type arguments) and the compiler figures out everything.

kibwen9• 11 years ago

I'm curious how possible it is in practice to write large software that relies exclusively on global type inference. Does the compiler itself go without ever explicitly specifying a type?

seanmcdirmid6• 11 years ago

What algorithm are you using? How do you deal with subtyping and paramatricity?

_RPM• 11 years ago

How long did it take to become self hosting? I checked the first tag on GitHub and it was still implemented in Crystal. Did you originally implement it in C or another language?

rajahafify• 11 years ago

From what I understand in another post of their's, Crystal used to be written in ruby, before they successfully compiled it using Crystal.

asterite19• 11 years ago

It took about one year. We originally implemented the compiler in Ruby and because of its similarity with Crystal (or the other way around ;-)) porting it to Crystal was pretty easy in the end.

There's this tag: https://github.com/manastech/crystal/releases/tag/ruby

You can read about the bootstrapping moment here: http://crystal-lang.org/2013/11/14/good-bye-ruby-thursday.ht...

earleybird• 11 years ago

originally Ruby http://crystal-lang.org/2013/11/14/good-bye-ruby-thursday.ht...

trengrj• 11 years ago

I've been looking at the benchmarks https://github.com/kostya/benchmarks and am pleasantly surprised about the speed. It definitely smokes Ruby, but also is usually faster than Go. I know that all benchmarks are relative but Crystal seems a great language from a performance viewpoint.

ezdiy3• 11 years ago

Indeed it's becoming quite promising (using crystal already for few pet scripts which were too slow even for rubinius). Where it's most lacking at the moment is gc - it uses stop-world off the shelf boehmgc which is ok but not exactly great for memory heavy tasks.

kephra• 11 years ago

imho, starting a new language with Boehm GC is a very bad design choice. It means, that one just allocates memory, and does not care for managing it. Even worse, it prevent linking any library, e.g. a 2nd thread running Lua+C, that cares for its own memory, because Boehm GC runs over the complete memory, not only the one the language has to manage.

You basically need 3 types of memory: First for the objects in your language, 2nd for foreign light weight objects, where you only know a pointer, and 3rd for foreign heavy weight objects, that gets their memory from your GC.

it uses stop-world

A fully concurrent GC is impossible, if variables are mutable. Regardless how tricky your GC delays the problem, there will come a point, where it has to stop all threads to collect the edge cases. This creates the GC dilemma, because currently only number of cores and amount of memory becomes cheaper, while single core performance stayed same for nearly 15 years.

rtpg• 11 years ago

http://crystal-lang.org/2013/07/13/null-pointer-exception.ht...

The Null pointer analysis is great, hope this stuff pollinates some of the more mainstream languages

raindev3• 11 years ago

I don't see a reasons for null to exist in a new language in 2015.

asterite19• 11 years ago

How do you model a "zero or one" relationship without null?

Maybe your answer is "with Optional" (or Option, or Maybe). We just choose to use union types and have "Nil | T" (Nil or T) be the same as "Option(T)" in other languages.

MCRed• 11 years ago

I love that we're getting new languages lately, but almost all of them seem to be ignore the significant new requirement of our age: parallelism & concurrency.

Specifically, you need lightweight processes and no-shared-memroy architecture.

While the number of cores on a machine is remaining relatively low, the number of machines in a system are going up.

Erlang got this right and build a lot of infrastructure around it (OTP) and while you can't replicate that infrastructure quickly you can get the fundamentals right.

Simply getting this wrong rules out a lot of languages from consideration (because why learn a new language that is going to be obsolete, or only chosen by people who don't understand how to build systems?)

It's a lot easier to get this in when you're new and can make major changes to the language. Once you start to solidify it would break things- this is why Go's fake concurrency is a tragedy and a huge missed opportunity.

rifung• 11 years ago

I largely agree with what you are saying, but doesn't it only apply to languages that will be used in back end systems? If you are just making a phone app or something, it doesn't seem like parallelism is nearly as important.

oconnor0• 11 years ago

Phones are getting more and more cores. It won't be long before languages for mobile need to solve the same issues - parallelism and concurrency.

asterite19• 11 years ago

You are right, it wouldn't be wise to create a new language without having concurrency in mind.

Starting from the last version there's spawn (lightweight processes) and channels for communications, similar to Go (although it's in a very experimental stage right now). We aren't sure immutability everywhere is the solution for everything, some algorithms and programs are much more efficient with mutable data.

I think Go is quite popular and have an amazing concurrency support. It's true, you have to make sure to communicate using channels and not via shared memory, but if you follow that rule than you won't have problems, and you can get pretty efficient programs.

dmgbrn• 11 years ago

I have to disagree with you on this.

A language should be expressive enough that it can easily support correct concurrent programming, and readily expose runtimes (OTP is a great example) that have support for concurrency and distributed programming.

However, patterns like message passing instead of shared memory are not a panacea. Deadlocks and non-deterministic behavior can still happen in such systems if programmers do something stupid.

Enforcing these patterns at the language level smells of the old "let's make a language that doesn't allow programmers to write bugs!" trap.

westoque2• 11 years ago

> I love that we're getting new languages lately, but almost all of them seem to be ignore the significant new requirement of our age: parallelism & concurrency.

Yes. I expect this to be the norm in future languages. App developers shouldn't have to worry about these kind's of things, and we can just focus on making apps. Parallelism and concurrency should just work out of the box.

anonyfox2• 11 years ago

http://elixir-lang.org - ruby-like syntax on the erlang VM, -> massivly scalable, really fast and fault tolerant.

seanmcdirmid6• 11 years ago

Specifically, you need lightweight processes and no-shared-memory architecture.

No you don't. I mean, that's one way to do it, but its not the only way and is often not an option if you want real performance. CUDA (a language specifically designed for SIMT parallelism) supports shared memory for good reasons; the threads are also not lightweight in that way (though they rely on memory and branch coherence).

kayamon• 11 years ago

It can be argued that shared memory should be explicit-when-needed rather than everywhere-by-default though.

zeeone2• 11 years ago

Just curious, why Crystal? It looks just like Ruby. What problem(s) are you addressing with Crystal?

umhan35• 11 years ago

It's a compiled language.

wtetzner6• 11 years ago

A statically-typed compiled language.

hk__2• 11 years ago

The important thing is that it’s statically-typed. All languages are compiled nowadays, except Bash. Ruby, Python and the likes all use VMs, and the code you write is compiled in VM bytecode before being executed.

asterite19• 11 years ago

We like the way Ruby lets you quickly prototype things, but its performance isn't very good (it's just good) and it also lacks static type checks (for example "undefined method '...' for Nil" is a very common runtime error).

So, we are trying to create a language with all the nice aspects of Ruby but with static checks and better performance. Of course that comes at a price: no dynamic aspects (no eval, no instance_eval, no methods or classes created at runtime, no methods redefined at runtime, etc.). But we try to compensate those with macros and compile-time reflection.

One thing that is definitely not one of our goals is to replace Ruby: every tool has its place.

Sodel• 11 years ago

I recommend adding something about static type checking to the list at the top of Crystal's homepage. I saw "never have to specify the type of...", and believed it was another dynamically typed language.

I actually didn't know it had static type checking until I had closed the tab, and glanced at this comment you posted here. (I know, I didn't read very far in the linked page.)

That aside, it looks neat! :)

chrisseaton2• 11 years ago

People talk about how Crystal's performance is better because it's statically compiled and removes Ruby's dynamic features, but I'm not sure static compilation is the best way to achieve performance, and I don't think the dynamic features need to damage performance.

For example, JRuby+Truffle runs Crystal's own sample programs around twice as fast as Crystal does, without static compilation, and while still supporting all the metaprogramming and dynamic features of Ruby such as monkey patching, send, method_missing, set_trace_func, ObjectSpace etc.

https://gist.github.com/chrisseaton/91c7cbf8f6f4f6ea44bb

However Crystal does start faster, and I'm sure it has lower overhead.

wedesoft• 11 years ago

Macros is something I really miss in Ruby. But static classes strikes me as a bit of a limitation. E.g. a Crystal REPL can't create classes if I understand it correctly.

singularity20015• 11 years ago

Awesome! Did you consider synchronizing your syntax with Mirah / typed ruby? Also what's your opinion on the Vala/Gini toolchain?

AKifer• 11 years ago

At first look, I like it. Would be great if we can build a ruby-to-crystal bridge so all the ruby goodness can run on top of it without requiring programmers to learn a whole new language. No GIL, faster than ruby but syntactically close enough, the dream.

ezdiy3• 11 years ago

Current channels implementation uses fibers, ie everything runs on single thread and only stack is switched. There is no GIL.

If you want true multithreading, simply use pthreads like you would in C. Just make sure to mark gc roots of new thread stacks (gc is thread aware). But this also comes with a lot of headaches as you're now responsible to synchronize everything and manage mutexes by hand.

sergiotapia• 11 years ago

I'm looking for something beautiful like Ruby but fast like Go. Do you think Crystal fits this bill?

Also, are there packages/libs/gems for Crystal? What are they called? What do I google for?

One of the major reasons why I dumped Go is that it's just too verbose and makes me write too much boilerplate code. I want to sort a collection and I have to write the same algorithm every single time for every single type. It's just boring and my time could be better spent elsewhere.

I appreciate the feedback HN!

seunosewa• 11 years ago

You're looking for Scala. The "good parts".

zak_mc_kracken3• 11 years ago

Still looking for them ;)

singularity20015• 11 years ago

CrystalGems would be really a boon!!

anonyfox2• 11 years ago

http://elixir-lang.org may be even faster than go. web apps respond in microseconds.

jacquesm• 11 years ago

Elixer and Erlang are not faster than go.

The ability to respond in microseconds is a latency issue, not a raw speed issue. Erlang and Elixer can do that because of the way the core systems are architected but the underlying VM and language constructs are quite a bit slower than anything that Go has to offer.

For maximum throughput out of a given chunk of hardware you'd want Go.

Erlang / Elixer and the associated VM and eco-system have their own strength, reliability for instance, with some C code thrown in for heavy lifting if required.

infraruby3• 11 years ago

I'm looking for something beautiful like Ruby but fast like Go.

Have you tried InfraRuby? InfraRuby is a compiler and runtime for statically typed Ruby: http://infraruby.com/blog/why-infraruby

wtetzner6• 11 years ago

What makes InfraRuby better than Crystal (or vis-versa)?

jagtesh• 11 years ago

Nim perhaps? There's very little boilerplate but it is statically typed. Someone mentioned infra-ruby, which is worth checking out. Lastly, crystal-lang is pretty awesome. You could use this opportunity to create what is missing in the ecosystem and make it open source. This will encourage others to chime in, accelerating development for everyone.

CyberDildonics3• 11 years ago

You definitely should at least look into Julia. I would say it is more elegant than any other language I've seen while being faster than pretty much anything except for straight C / C++ / D / Rust (native systems languages).

It should be easy to beat Go in performance and match or exceed Ruby in elegance and simplicity.

It's Achilles heel(s) right now though are multi-threading and JIT compilation times (which should be alleviated once caching is implemented).

It sounds really close to what you want. Its package management is even based off of github. Want to get a package to write out image files? Pkg.add("Image"). Update all your libraries? Pkg.update()

Over the next 5 years I think it might eat into a lot of the territory of scripting languages.

Also the generic programming focus means you should never have to write anything more than a new comparison for your new types.

zeeone2• 11 years ago

Julia's 1-based array indexing is counter-intuitive and a turn off.

CyberDildonics3• 11 years ago

Wow, are people really that offended by someone suggesting Julia? It is a bullseye answer to the question.

wtetzner6• 11 years ago

From your description, it sounds like Crystal is exactly what you want. But yeah, I don't know if it has a library ecosystem yet, or anything like that.

asterite19• 11 years ago

I think Crystal could fit this bill, yes: it has Ruby syntax and the concurrency model will be something like Go (spawn and channels, but we are still working on this). And the code ends up without much repetition, as you have generics, macros, very few type annotations, and things like sort, map, select, inject, etc.

The community likes to call a library as "shard", so I think we'll eventually end up using that name :-)

You can see a list of shards here: http://crystalshards.herokuapp.com/

For now that just lists GitHub repositories. Right now there's a very basic package manager that fetches repositories from GitHub, but it's too basic. Someone is working on a much better package manager ( https://github.com/ysbaddaden/shards ) that we'll probably incorporate in the future.

FraaJad• 11 years ago

will beautiful like python and faster than Go do? then Nim - http://nim-lang.org will do just fine. Anecdotal benchmarks like this one https://github.com/kostya/benchmarks will show you that Nim comes out at the top (so does Crystal for some, FWIW).

steveklabnik2• 11 years ago

As always, take benchmarks with a grain of salt: https://github.com/kostya/benchmarks/pull/26

Or this discussion (which is two months old, so unsure what exactly has changed since. Looking at commits, not much?) http://www.reddit.com/r/programming/comments/30y9mk/go_vs_ru...

Or this one, though it goes off track a bit: http://www.reddit.com/r/rust/comments/38s1n3/why_is_rust_muc...

agluszak• 11 years ago

Wow! Ruby was the first programming language I learnt and I still love it. Crystal is going to add features I've always missed: static typing and compilation. Thank you guys, it will be awesome!

sir_akshay• 11 years ago

You missed compilation?

singularity20015• 11 years ago

He probably meant the results of compilation: superfast binaries ;)

keypusher• 11 years ago

Python is to Nim as Ruby is to Crystal.

singularity20015• 11 years ago

More like Crystal could become to Ruby what RPython is to python

masklinn3• 11 years ago

That makes no sense. RPython is not a general-purpose development language, it's a strict subset of Python for writing VMs. From what I understand Crystal aims to be a general-purpose statically-typed native-compiled language with a syntax similar to Ruby in much the way Nim aims to be a general-purpose statically-typed native-compiled language with a syntax similar to Python.

Neither Nim nor Crystal exist solely to write VMs and auto-implement JITs, and programs in neither is expected to run unmodified on a VM for the inspiration language.

singularity20015• 11 years ago

Now someone convince Matz to reimplement Ruby in crystal, add optional typing to CRuby, and you have won big time.

atmosx2• 11 years ago

Actually, that's already happening[1]. Also note that there is a library for "ruby contracts[2]" (which I didn't try yet, but I'm very eager to do so) which could give the same result as a statically typed language.

[1] https://www.omniref.com/blog/blog/2014/11/17/matz-at-rubycon...

[2] http://egonschiele.github.io/contracts.ruby/.

masklinn3• 11 years ago

Except for the parts where you've lost spent years reimplementing an implementation-defined language and you've lost the existing C API so most any C extension which doesn't use Fiddle (or similar FFI mechanisms) is incompatible.

davexunit5• 11 years ago

I don't understand why Ruby's syntax is seen as so elegant. It's ambiguous and a nightmare to parse.

http://programmingisterrible.com/post/42432568185/how-to-par...

Lrigikithumer• 11 years ago

Elegant to program with. Not write a parser for.

davexunit5• 11 years ago

An ambiguous syntax is not elegant to program with. Is this a variable reference? Is it a method call? I dunno!

asterite19• 11 years ago

I don't think it matters much that it's hard to parse: very few are going to write a parser for that language compared to the ones that are going to write programs in the language. It goes the same for everything else in a language: prefer a fast compiler rather than an elegant (compiler) but slow one.

Ruby's syntax is very short and concise if you compare it to other languages. To know if "x" is a variable or a method you just need to see if "x" was assigned a value in the method, that's all.

john2x• 11 years ago

Yeah, the Ruby-like syntax of Elixir made me stop looking into it more. I remember reading an article (or was that a chapter in a book), which basically said something like "ok, these parentheses are optional, but only for this case. For other cases, parentheses are required." Which is a shame, since the tooling built for it is the most amazing I've ever seen.

I know syntax shouldn't matter, but personally I think consistency is very important.

Reefersleep• 11 years ago

I think syntax matters a lot - if it incurs development costs through inconsistencies, for example.

I'm going to a meetup in a couple of days where Elixir and Phoenix will be presented, I think I'll keep your comment in mind and maybe ask about inconsistencies in the syntax, as I wasn't aware of this. What I know of the syntax relation to Ruby is that it is only superficial - the semantics are very different.

dragonwriter2• 11 years ago

Lots of people find it elegant in actual use because of the same features that make it hard to parse; this is much the same thing that is true of natural languages.

atmosx2• 11 years ago

I don't understand what parsing has to do with elegance in this context. There are some 'best practices' but I don't see the different syntax support as a bug. I feel that it's a trademark of a modern language.

Let's take rust as a counter example. IMHO this is ugly:

    fn foo() {...}

To make it elegant I should be able to remove the parenthesis because there's no argument inside:

    fn foo {...}

But this will come up with an error: "expected one of `(` or `<`, found `{` ...", which is fine. It's easy to parse, but it is not elegant IMHO.

Elegance != easy parsing.

kibwen9• 11 years ago

It's not just about making parsing easy (which is usually motivated by the promise of better tooling), it's about making costs explicit. `foo.bar` with no trailing parentheses is always a field access in Rust, and a field access is basically the fastest thing one can do: take a known offset from a memory location. In comparison, `foo.bar()` has a relatively tremendous cost, depending on various factors. It's for this same reason that Rust requires you to write `(foo.bar)()` if you want to call a function stored in a struct.

This isn't a tradeoff worth making in all languages. But it is a tradeoff, and not a rejection of elegance.

MrBra3• 11 years ago

Try to build a class with it and you will understand.

davexunit5• 11 years ago

I've built many a class in Ruby.

Nob-suz• 11 years ago

I made a Crystal Language Web/Git information collection pages. https://github.com/nob-suz/crystal/wiki/1.-Read-First-%28gen...

See Wiki 1. to 9. If you enjoy your first try for Crystal Language, it's nice.

westoque2• 11 years ago

Now. I just can't wait till Rails or something similar gets ported to Crystal.

aikah• 11 years ago

I'm a go user right now, but I really want to ditch it because I'm in total disarray with the way the go language is managed and the deafness of the go team. Been looking at D,Nim and Crystal.

- D is neat but I'm not interested at all in unsafe stuffs and don't want to have to debug programs or 3rd party libs that relies on that, I want a safe language.

- Nim looks really good, although some features like (foo_bar = FooBar ) are just disgusting

- While Crystal is new and libs is non existent, it feels like a good candidate for the long run. I hope it will have the same concurrency capabilities as go. Good luck with the language.

p0nce• 11 years ago

D has a memory safe subset (@safe). You could argue that Rust 3rd party libs rely on unsafe blocks.

kibwen9• 11 years ago

The person you're replying to wasn't even talking about Rust. You'd also be vastly overestimating the amount of Rust libs that need unsafe code. For example, Rust's most mature web framework, the one powering crates.io, doesn't use unsafe code at all: https://github.com/iron/iron

zak_mc_kracken3• 11 years ago

Have you looked at the new generation languages on the JVM such as Kotlin or Ceylon?

kodablah• 11 years ago

I am assuming your requirements are statically typed with GC, no separate VM, and lightweight runtime. One language I have been watching with a keen eye lately is Pony[1] though the docs are not quite complete.

1 - http://ponylang.org/

Dewie35• 11 years ago

If you don't like unsafe stuff perhaps you should be a bit wary about Nim as well. The attitude seems to be that unsafe things aren't that big of a deal as long as you decent tools to debug them.

Pharohbot• 11 years ago

Well if you have decent tools to debug them, why should he be wary?

jwecker• 11 years ago

Quick fix, in nim:

  foo_bar = fooBar
  Foo_bar = FooBar
  foo_bar != FooBar

That is, it's case sensitive with the first character of the identity.

I've mentioned elsewhere that this one bugged me at first, but in practice it simply means that you get to use the language as if your preferred convention (whether snake or camel) is the "official" one- even when calling other libraries. Nothing more and nothing less. Cases where you need both styles but need them to be different things tend to be non-existent / code-smell.

aldanor2• 11 years ago

What about Rust though?

zero_iq• 11 years ago

Wow, I started designing a language called Crystal in the 90s, which a) looks similar to this, and b) I'm pretty sure I even bought the domain crystal-lang.org at one point, but I never did anything with it! I had a very similar logo too :)

elcct• 11 years ago

Please don't be inspired by Ruby, please... aaaah god dammit!

The Crystal Programming Language

Related Stories