Crystal: Differences from Ruby?

[ylluminate]

Having just stumbled across Crystal, I have seen a lot of talk about similarity with Ruby, which is excellent, but I am curious: What are the differences? (Especially at the language grammar level?)

I am thinking that a comparison of differences might make it easier for one to understand Crystal and its objectives better than discussing commonalities. Further, what are your goals in being able to take native Ruby code and running it straight out of the box or at least very nearly doing that with very minor modifications?

Don't get me wrong: I'm exceptionally excited about the similarity aspect. I wouldn't even be interested in touching Crystal right now if that were not the case, but I'm definitely trying to ascertain their closeness in order to understand library / gem portability, etc. and how much work will really go into such efforts.

[refi64]

• No for loop and fewer aliases (in a good way)
• Abstract classes
• Static typing
• Compile-time nil checks
• Character literals
• Much better speed!

[ylluminate]

Hmm, that's interesting (and seemingly odd) re: the for loop. What's the logic behind that?

Is there an enumeration of the absent aliases?

[refi64]

@ylluminate

1. Apparantly, use of the for loop is discouraged in Ruby anyway. You can just use .each and related.
2. No clue. I've never actually _used_ Ruby before...

[ylluminate]

Well, I'm no fan of for loops, but for the sake of compatibility I would have thought that it would be important to implement. We are particularly interested in isomorphic software development where we maintain the language from top to bottom. We've had great results with Opal and now with Volt being essentially a Meteor for Ruby. Having Crystal for the server side and Opal for the browser seems exceptionally intriguing, but the challenge would be having a robust enough support for Ruby proper that it would not create overly burdensome porting headaches. Hmm.

Thanks for the input so far! This does indeed look interesting.

[bcardiff]

@ylluminate Crystal does not aim to compile out of the box Ruby code. In some cases it happens. But metaprogramming is quite different. Due to the type inference in crystal there are some mandatory type annotations that any Ruby programmer will encounter pretty soon.

http://play.crystal-lang.org/#/r/64i

Although Crystal inherits it's syntax from Ruby, it is a different language. We like the comfort of Ruby, but also the fine control of other languages.

We hope to see lots of shards (crystal gems) all around and see if/how this language has it's place among the others.

Regarding the for loop, check #830 .

There are some grammars differences that comes from the type annotations, type restrictions, tuples, macros. Don't forget to check crystal-lang.org/docs and welcome to Crystal :-)

[ssvb]

@ylluminate I myself became aware of Crystal a few months ago and had similar hopes, see #593

Well, I'm no fan of for loops, but for the sake of compatibility I would have thought that it would be important to implement.

If you are in control of your code, then you can always change it to use the syntax constructs which work the same. For example, if one had for loops in the code, then they can be just easily rewritten using the iterators and the problem is solved. This works as long as there is at least one common way to do it both in Crystal and Ruby. There are some dangerous differences though, such as the single line while handling, see #549 (this is very easily fixable in the parser if anyone decides to take any action).

The mandatory type annotations when creating empty hashes or arrays are the biggest source of incompatibility between Crystal and Ruby, but this can be solved by introducing the #of keyword hack as mentioned in #593 (such keyword is treated as a comment by Ruby, but still provides the type information to Crystal). Today the incompatibilities between Crystal and Ruby are really minimal, but I guess that this is not going to last long and the languages will diverge a lot more in the future.

Also the old style native threads support is broken since Crystal 0.7.0 and apparently there is no intention to fix it and keep in a working shape as can be seen in the #747 bug comments. The higher level concurrency/parallelism abstraction using channels is currently in development.

[Codcore]

@ylluminate also Crystal doesn't support passing hash without curly braces as a last argument. But instead of this you can use syntax with : for default arguments. I think it is better and faster way than passing hashes : http://crystal-lang.org/docs/syntax_and_semantics/default_and_named_arguments.html

[classyPimp]

Will or does Crystal have the meta-programming capabilities of Ruby, like method_missing and etc.?

[Codcore]

@classyPimp no, it has macroses for this.

[jhass]

@classyPimp No, but it has replacements for a lot already through the macro language. For example there are a couple of automatically called macros which indeed has a method_missing macro that gets you quite close to the Ruby functionality.

[bcardiff]

@ylluminate Another nice difference is the &. vs &: http://crystal-lang.org/2013/09/15/to-proc.html

[asterite]

As many here say, Crystal has Ruby-inspired syntax (and some semantic and API, of course). But there are many differences. I don't think, for a real app, there would be a chance that the same code would run in Crystal and in Ruby without huge modifications. For example JSON parsing is done in a very different way. Or we have HTTP::Client. And so on...

Please contribute to this page to add the differences you want. I'll close this issue for now.

[opensas]

I think this information should be in the official docs, it will save some headaches to people coming from ruby

[007lva]

@opensas also this could be useful http://www.crystalforrubyists.com/book/book.html.

[RX14]

@opensas we already have that: https://github.com/crystal-lang/crystal/wiki/Crystal-for-Rubyists