It's like a language was picked first and then the blog written backwards to come to the conclusion. So there's some languages in bullets and subjective pieces that are reasons not to use them. I can do that with Crystal too...it doesn't even support one of the most popular OS's natively. I mean, the author says C++ is a better language than Go, that Google is the ultimate reason for success, and that Go takes us back to C. That doesn't even make any sense. "doesn't seem to click to me...generally didn't feel...feel the language is rough" etc. How about just use the best language for the problem, instead of choosing the language before the project. As I've mentioned on many of these language-comparison posts (more like tweets) these days, just ignore them and remain wise to your problem space. They are very juvenile.
Crystal is a Ruby inspired compiled language, allowing it to run blazingly fast with a very low memory footprint. It uses LLVM for emitting native code, thus making use of all the optimisations built into the toolchain.<p>Website: <a href="https://crystal-lang.org/" rel="nofollow">https://crystal-lang.org/</a><p>Github: <a href="https://github.com/crystal-lang/crystal" rel="nofollow">https://github.com/crystal-lang/crystal</a>
Hey guys, thanks for reading my blog post and posting it on Hacker News. :)<p>It was just an informal brain dump for me and nothing too serious, so please don't take anything to heart. And indeed, I have only spent a limited amount of time with the other languages on my list. I still intend to keep a close eye on them all as time goes on.<p>I'll try to respond to various comments :)<p>Update: Hacker News is rate limiting me, sorry folks. I'll try again to post some replies in a little while.
The results he got for C and C++ make no sense and I question what optimization flag was actually used if any. From the looks of it, he uses "-O" which is equivalent to "-O1" which is really not the flag you want (this optimizes for both time and code size).<p>*edit: with O2 I get a dramatic improvement and the C and C++ versions compile to essentially the same disassembly. Using O1 is definitely not going to produce an apples to apples comparison.
I feel like the author dismissed Nim pretty unfairly. Github stars and issues are one signal for a project status, but its hardly conclusive. Nim's development has been pretty consistent and is approaching 1.0. Ultimately, a lot of language choice is subjective, but I think anyone looking for a language in the fast-but-expressive category should at least try Nim.
I'm often curious as to what people are doing that makes them really think they need to venture outside their chosen scripting language. I use Ruby thinking I'll 'drop to Rust/Crystal' whenever I need to do something "serious", but that need never seems to manifest. Whatever I code in Ruby seems to just do the job and I can solve perf issues with asynchronous constructs like a jobs server, or something like caching.<p>At this point I'm really starting to wonder if Ruby really is the One True Language and everyone's going to be using it in 100 years. Like how PG thought Arc would be the hundred-year language.<p>Does static typing really offer that much more over dynamic? I'm not at all convinced that it does, when you get right down to it. Once Ruby gets a built-in typing system, we'll get to answer that question.<p>I do believe that Ruby will eventually solve its perf problem and once it does, its pleasing syntax and semantics will just draw everyone back to it the same way it did the first time.
Crystal looks great in many ways, but it's hard to go all-in with a new language that lacks parallel processing. Go, Elixir, and Rust all have great concurrency stories, and their adoption has a lot to do with that.<p>It is a gorgeous language, though, with a very easy to read syntax. I'd love using it if it had something like goroutines, which would look great with its block syntax. Good luck to the team working on it; I hope it's a contender.
It's just me, but I view the lack of OO features in Elixir as a really good thing. You still have structs and some other OOish type stuff, but the emphasis on composition and modularity has really made Elixir programs a joy to read and understand.<p>The lack of a single binary isn't a fully fair criticism. While technically it is true, it doesn't describe the shipping experience. You will need Erlang installed on the target machine, but using escript you basically ship a "single binary/file" and it includes everything it needs to run. It's quite elegant, and erlang is super easy to install on basically all *nix systems.
As a Rubyist, I was about to jump on the Crystal train, but then server-side Swift started getting really good. Crystal is awesome, but I feel it’s not solving any problem particularly better than Swift. With Swift being compilable even on a Raspberry Pi and of course Linux and Mac, it seems like Crystal is now a solution in search of a problem. Definitely a great language, but probably destined to be relatively niche in production contexts simply because the community is so small and it’s loosely competing against the rapidly maturing Swift world.
I think this thread has no shortage of criticisms, but too many are uninformed. The blog post doesn't mention these important things:<p><i>Package management</i> (from [0]): "Crystal libraries are packed as Shards, and distributed via Git without needing a centralised repository. Built in commands allow dependencies to be easily specified through a YAML file and fetched from their respective repositories."<p><i>Concurrency</i> (from [0]): "Crystal uses green threads, called fibers, to achieve concurrency. Fibers communicate with each other using channels, as in Go or Clojure, without having to turn to shared memory or locks."<p>[0] <a href="https://crystal-lang.org/" rel="nofollow">https://crystal-lang.org/</a>
I've been dabbling with Crystal a bit lately, and have been impressed with it, especially the speed and low memory footprint. Still only developing small utility app with it at the moment [0] but eventually might look at creating production API servers with it.<p>[0] - <a href="http://devan.blaze.com.au/blog/2017/10/28/racing-along-building-a-telemetry-system-using-crystal-rethinkdb" rel="nofollow">http://devan.blaze.com.au/blog/2017/10/28/racing-along-build...</a>
I used to like OO, but ever since I got a taste of functional programming with Elixir, I haven’t looked back. It’s a very elegant language and an absolute joy to program in.
From a recovering OO developer: one of the things I find funniest now is that OO is constantly treated as a plus in these “why I picked” posts, while I’ve long concluded that the cost of this easy polymorphism is way too high.
For those who are interested in Crystal, these are some of the major features currently in dev:
1. Windows support
2. Parallelism
3. New Immix GC<p>Crystal is going to be an insane language in a year's time.
Is this the language of 2018?<p>Will this join the ranks of Julia, Rust, Go and the others?<p>I'm skeptical because the last few years I've seen these trends come and go on HN. They do nothing but scatter my focus. I've learned to ignore them now though.
I would love to see Crystal take off but it seems like some decent funding/backing and then some time to settle from there will be needed. I seriously hope that can happen; but, who knows.
Maybe it's because I learned Ruby after Perl and Python (and C and C++ for that matter), but I find it too quirky.<p>e.g. These three expressions have three different values:<p><pre><code> 1 + 2
+ 3 + 4
(1 + 2
+ 3 + 4)
1 + 2 +
3 + 4
</code></pre>
3, 7 and 10 respectively. Because newline is equivalent to semicolon and Ruby allows void expressions.<p>I just tested Crystal and it does the same.
Another language worth considering is Kotlin.<p>You get the JVM ecosystem with a modern syntax.
It's a higher investment then Nim/Crystal but also has higher payoff due to existing libraries and peak performance of the JVM.
Running the same algorithm in my system, C/C++ with -O3 are almost equivalent, and Crystal too:<p>Clang C++ 1.069s<p>C++ 4.2.1 1.075s<p>Crystal 1.082s<p>But using a different algorithm (non–recursive) in C++ (<a href="http://rextester.com/discussion/OGIF47151/fibonacci" rel="nofollow">http://rextester.com/discussion/OGIF47151/fibonacci</a>) you can achieve<p>C++ 4.2.1 0.005s<p>someone should port it to Crystal :)
We support Crystal at <a href="http://fiatjaf.alhur.es/module-linker/#/crystal" rel="nofollow">http://fiatjaf.alhur.es/module-linker/#/crystal</a>!
I'd suggest giving a try to data types + type classes as opposed to OOP. E.g. Haskell and Rust. Or OCaml, F# or Scala for combination of OOP + functional style.
>CPython 3.6.5 128.172<p>Am I reading this correct? it took CPython 128 seconds for a simple Fibonacci test? Can anybody explain to me why this is so slow?
Why is Fibonacci the standard performance test? I want to know how it runs on complex objects with complex computations.<p>Also this entire article seems to be content marketing for crystal.<p>And, oh, btw, crystal isn't windows compatible.
When i chose a programming language, here is what i look for:<p>1. Amount of things I've to learn to completely utilized 100% features of the language.<p>2. Availability of well supported packages for stuff like elastic search, stripe, postgres etc...<p>3. Ease of making a function asynchronous. I love how go routines make it trivial and hated pythons way.<p>4. IDE and debugger: I am using goland now, and it is magical.<p>GO has provided me everything, finally i can focus on building my product.