[RX14]

I think crystal has several advantages over go, first of which is the type inferrence. In crystal, you never specify types in method bodies. You don't have to specify types in method arguments either. Type unions are really expressive, and handing nil is as easy as `raise/return unless nillable_variable`.

Second of which is `yield`, ruby's extremely powerful way of passing code to functions. In crystal, functions which take blocks are actually inlined, meaning that abstractions such as `3.times {}` or `5.upto(20, step: 5) { |i| ... }` have zero cost. For example, take a look at how simple the HTTP server example is on the crystal homepage. Very useful for building DSLs.

Macros are another powerful (but hopefully not overused) tool for building clean programs. Crystal macros receive AST nodes but return source code as text. This text is then compiled and placed inside the program. This may sound like it would have the disadvantages of C macros, but as they're more integrated into the language, the compiler can insert the generated AST of the compiled macro into the original AST in a clean way. Using "dumb" text templating has several advantages: it's really easy to use because you're essentially just writing crystal code, and it's powerful as you get access to the AST. It also has the advantage that it's actually quite hard to make large scale modifications to a method body, preventing a lot of the silly macro uses.

[obl]

Text templating can't possibly be better than (quasi)quoting.

> you're essentially just writing crystal code

even more so in a quasiquote, since you don't have to worry about adding extraneous parenthesis "just in case" etc.

Having structured input is already way better than full token-level solutions like C, but why not go all the way ?

[chrisseaton]

Ruby implementations with a JIT can also inline blocks, of course.

[RX14]

Of course they can, however I was describing the advantages of crystal as opposed to go.

Crystal vs Ruby don't really compete in the same way Crystal and Go do, it's very much a dynamic vs static typing split. Crystal is in general a bit more cleaned up but Ruby's community is much larger.

[gravypod]

That still comes at a cost. The macro/lazyeval approch is usually seen as "zero cost" because the JIT engine usually only spends time inlining if it's a hot block.