That said, it looks like a really cool project, with many nice language features Go is clearly missing. Attacking Go on performance is a bit silly though, this is purely by the choice of being a frontend for LLVM, not by language design. The choice for LLVM is understandable, and at first I thought Go made a mistake here, LLVM is really nice - but it also clearly has it's downsides. On one hand I wish Go had access to the optimization power of LLVM, on the other hand I'm glad it has no dependency on it and is standalone. Thanks to this, cross compiling is a breeze, and adding support for new platforms is entirely controlled by the Go team and it's contributors, although I don't know how they're going to handle iOS support now that Apple switched to LLVM bytecode for application distribution which they then compile to native code on their servers before delivering to the device. Maybe Go can add an LLVM bytecode target, which would mean it could also benefit from it's optimisations.
But in most cases, once you've passed a certain treshold, performance is not that important anymore, and once you're running reasonably fast native code, that should not be a problem anymore. I'm already happy with the current trend of going back to native code instead of thinking that CPU's are fast enough to interpret everything and that memory is cheap.
I also quickly tested compiling a 'hello world' example with both Go and Crystal, and the binary sizes were quite similar:
- Go (1.4.2): 620K
- Crystal: 619K
- Crystal release: 528K
So Crystal is a little bit more compact at first glance, but at first glance not that spectacular. Go is notorious for generating quite big binaries. The thing is however, that Go always produces static binaries - it does everything with it's own stdlib, unless it involves DNS resolving. A quick LDD on the crystal binaries revealed it wasn't a static binary and depended on libc. So I tried compiling the same hello world staticly in crystal, which gave me some warnings and a whole different picture: a whopping 1.8M binary. So more compact? Not necessarily.
Library-wise however, Go is lightyears ahead of Crystal. Go's stdlib is amazing, and there are an surprising amount of 3rd party libraries written in native go. Crystal on the other hand has the advantage of being able to use existing C libraries with ease and little overhead, but this could also be a downside and impact clean library design and consistency in the long run. It not being 100% Ruby compatible and not able to blindly use any Ruby library is a handicap here.
All in all, I think both Go and Crystal could learn from each-other. Go is a bit more mature and has clearly been accepted in the server/sysops space, many new projects there being written in it (docker, consul, etcd, heka, kubernetes, prometheus, influxdb, the grafana backend, ...). For crystal to earn it's place somewhere, it will need a lot of work.