Why to choose Crystal over Go

[Guirec Corbel]

Hello,

Crystal and Go have similar performances but Go is more popular. I know Crystal has a Ruby-like synthax but I don't think it's a reason to not learn something new if the app can be better. So, why a developper should choose Crystal instead of Go?

Thanks!

[jmascis]

Obviously Go runs on many more architectures than Crystal and it is more stable , Crystal is still alpha . In the future ? if Crystal gets Windows and ARM support , there is no debate for me. While I like the simplicity of Go , I value the expressiveness of Crystal even more. My 2 cents. I can't wait to be able to develop GUI apps in crystal.

[Ryan Gonzalez]

Go makes you type so much your fingers hurt...

No, really. The main difference between them is coding style. Go favors an explicit coding style with Wirth-style OO and little syntactic sugar, along with explicit error handling (no exceptions; most functions return two values, a normal value and an error value). It also allows nil values pretty much everywhere, which kind of sucks like heck. There are no generics, and the type system is super simple (although that's not necessarily a bad thing). All in all, it's kind of nice, but it's verbosity drives me crazy. Feels like Java all over again. :/

Crystal is the complete opposite. It has full Ruby-esque OO (not surprising!) with lots of syntactic sugar, a really cool type system, macros, and, of course, nil tracking. Now, I don't mean to bash Go, but Crystal programs tend to be a lot shorter.

For an example, compare:

https://github.com/kostya/benchmarks/blob/master/havlak/havlak.go

to:

https://github.com/kostya/benchmarks/blob/master/havlak/havlak.cr

I personally find Crystal easier to read because it's more concise (although that may stem from the fact I frequently script in an APL derivative :). And it takes less scrolling and typing. In addition, it can actually be *faster* than Go! (Though that's probably mostly due to LLVM and the explicit nils.)

Of course, Go is more mature, compiles like lightning, and has lots of tooling available.

--
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

[Jean-Baptiste Barth]

This kind of thread can quickly become a troll, so happy this is not a big mailing list ;-)

Four random arguments in no particular order:

1- learning curve:  Crystal retains a lot of Ruby semantics, not just syntax. Go (and others) have *lots* of different concepts and foundations. Sure you can learn a new language, but being good at something takes time. A lot of time. So for a person who comes from a Ruby world, Crystal is just awesome because you can get started in minutes and actually gain a lot of things (performance, easy deployments, type safety, etc.) without requiring you to spend 3 weeks doing beginner tutorials

2- type inference: most of the time, you'll get type safety without even thinking of it, while langages like Go (or Java, etc.) will require you to specify any type on any variable, entry parameter or return value ; you'll sometimes have to help the compiler understand that some type is not possible at some point (for instance: nil) but that's easy

3- union types: this is a super great thing to have if you need some kind of flexibility ; in Go you'd achieve this with pointers and manual verification when dereferencing I guess, and that's a lot of burden ; here you have an expressive type system that let you keep some level of duck typing and all the goodness that comes with it, without sacrificing type safety anywhere

4- contrib opportunities: this is more personal but.. the language is young, the stdlib still needs some work, and there are lots of contribution opportunities ; the community is welcoming ; and crystal is bootstrapped (compiler written in crystal), making it very easy to learn a lot of low level things by just reading (or contributing) to the stdlib or the compiler ; that's the case for Go I think, but think of Ruby: it can be frustrating at times to be stuck on a C function you cannot edit nor instrument easily

Of course, you can also learn both and act depending on the project. You may also have different subjective arguments depending on the projects (I have a hard time modelling big "objects" hierarchies in Golang, but maybe I missed something, while Crystal looks familiar, easy, and more expressive).

Cheers,

--
You received this message because you are subscribed to the Google Groups "Crystal" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crystal-lang...@googlegroups.com.
To post to this group, send email to crysta...@googlegroups.com.
Visit this group at http://groups.google.com/group/crystal-lang.
To view this discussion on the web visit https://groups.google.com/d/msgid/crystal-lang/9055de38-2450-4ad2-9b58-85d9e387815c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Santiago Palladino]

One of the main differences for me is the target audience of the language. This article points out that Go's main goal is to provide a simple procedural language, favouring very simple, explicit and easy-to-understand constructs, in detriment of expressiveness; operations that abstract computations over collections have to be made explicit (ie there is no map, filter or reduce as part of the language), and error checking is excessively explicit. These decisions were geared towards building a language that favours young (not as of age, but as of experience) programmers. 

Crystal, on the other hand, was designed with many lessons learned from Ruby, which has great expressiveness and is truly a breeze to use for a programmer willing to work with more complex constructs. The language was built after what his creators wanted in a language, who are two of the best and most experienced programmers I've ever met; and not adapted to be used for a different audience. At least for me, this makes programming in Crystal a much more enjoyable experience than in Go, which is a very important factor to consider when choosing a language.

Last but not least, please bear in mind that my observations on Go come from having built a relatively small project in it, as well as from the linked article; it might be the case that I lack enough exposure with the language.