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.

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 ?

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

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.

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.

I agree with this sentiment, Crystal, for the better, lacks Go's obsession with odd tooling conventions (see vendoring saga) while retaining the ease of use when it comes to actual programming and cross compilation capability.

If I'm already using, say, OCaml, why would I want to switch to Crystal? (assuming that multicore takes the same amount of time to arrive in each). Whenever I've read about Crystal it sounds like a broadly sensible language, but it doesn't sound like it brings anything new to the table - in which case I'll favour the more mature language with the bigger library/tool ecosystem.

Ruby itself never brought anything new to the table, just a really well polished collection of ideas taken from other languages. Crystal is mostly the same, marrying Ruby stdlib with go channels and compilation to native code.

Thanks for the summary; helpful as I've not checked out Crystal at all yet. Maybe they can steal it as their everywhere blurb.

Most of the popular languages over the last 20 years haven't brought anything new to the table, they've just had the right mix of pre-existing features (I use features in a very broad sense to mean any reason why a developer would use it) at the right time.

> it doesn't sound like it brings anything new to the table

A fast and typed Ruby, isn't it enough? ;)

It's not a Ruby. It doesn't even pretend to be a Ruby. I mean, to be a Ruby, this needs to work:

    a = Object.new
    list_of_modules.each { |mod| a.extend(mod) }

Ruby cannot be separated from its dynamism and to claim it can is misleading.

OCaml (well, actually Scala in my case, but I can understand why people wouldn't want to have to use the JVM) is already that, as far as I can see. What is it that Crystal offers that OCaml doesn't?

Doesn't share the fugly OCaml syntax.

Not a great way to convince OCaml fans to use something else.

All 3 of them? Jokes aside, they're probably aiming for Ruby fans (or fans of other dynamic languages).

I doubt Crystal's marketing goals are to convince OCaml fans...

A gentle learning curve for developers with a Ruby background.

Is this the same with Crystal, as shown in Ruby:

  irb(main):001:0> "".methods.size
  => 170

  irb(main):002:0> 0.methods.size
  => 133

If it is, I mean, I don't see it being so fast.

What on earth has the size of the list of methods to do with performance?

The number of methods in the standard library really doesn't impact performance in a compiled language since you can tree shake the stuff that isn't used. And even if you don't tree shake having lots of methods isn't really a noticable performance loss in compile to binary languages since you don't need to spin up a VM

I think tho might be easy. OCaml might have OO,but it is meant to be used as FP. The ecosystem isn't honestly that impressive and isn't winning over people from Ruby or Python and isn't going to catch on more than it already has. If Crystal catches even 1/4 of Ruby's base it will be huge. OCaml is hard to get into btw (big language). Crystal looks easy.

If you write a FOSS project, more people will help you if it's Scala or Crystal over Ocaml. My guess at a little over 1,000 stars for Ocaml but 7,000 for Crystal. There's that. ;)

For psychological reasons, things that build on what's familiar get increased adoption. Trend started with C syntax that I can tell.