From this post, Crystal appears to have some of the things many people have been lusting after in Rust: sophisticated metaprogramming, fewer sigils, a bigger standard library, fibers/coroutines/whatever-they're-called-now.<p>But it still has a GC :(. Rust has completely spoiled me with making it easy to minimize dynamic memory allocation and copies, and to know (almost always) deterministically when something will go away.<p>EDIT: I should also say that if you want to bash on Rust's lack of these things, 3 out of the 4 items I cited have solutions being actively worked on (either at planning, RFC, or implementation phase). I don't think Rust's sigils are going away any time soon, but I have no idea how you'd do that and preserve semantics anyway.
The claim is "fast as C", so I was surprised that the performance comparison was with Ruby, not with C. On my machine, the Ruby Fibonacci program executes in 47.5s, while a corresponding C program executes in 0.88s - that's a factor 54 difference, while the article reports a factor 35 for Crystal. That's good, but what causes the difference? This benchmark is pretty much all function call overhead, so I doubt it's representative of real performance-sensitive code.<p>The Crystal website itself makes a more modest claim than "fast as C" under its language goals: "Compile to efficient native code", which it clearly does.
Looks very nice. I hope it gains momentum.<p>For now, if you want a fast language with the beauty and productivity of Ruby, check out Elixir [0] and its web framework, Phoenix [1]. I've been using Phoenix for a year, and it's the first framework that I've actually liked <i>more</i> over time. And I've been a web developer for a decade. With its recent 1.0 release, Phoenix is gaining a lot of momentum.<p>If you want some idea of the performance differences between Phoenix and Rails, see [2] and [3].<p>[0] <a href="http://elixir-lang.org/" rel="nofollow">http://elixir-lang.org/</a><p>[1] <a href="http://www.phoenixframework.org/" rel="nofollow">http://www.phoenixframework.org/</a><p>[2] <a href="https://github.com/mroth/phoenix-showdown/blob/master/RESULTS_v3.md" rel="nofollow">https://github.com/mroth/phoenix-showdown/blob/master/RESULT...</a><p>[3] <a href="http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections" rel="nofollow">http://www.phoenixframework.org/blog/the-road-to-2-million-w...</a>
I'd like to put out there that Crystal is absolutely awesome. The language itself is Crystal clear, but the language documentation and API documentation - oh my!<p>I had never worked with compiled languages before I tried Crystal, but had always had a huge interest in getting into that. When I wanted to learn the compiled ecosystem I looked at languages like Go and Rust, but the learning curve for those was a bit overwhelming for a newbie. A while later I found Crystal, and much thanks to the simple syntax of the language I learned a ton of new things about compiled languages very quickly.
The absolutely best part of the language is that it is written in plain Crystal, and I've been looking at their own implementations for various things a lot - something I've never done before, having worked mostly with Node, Lua and PHP before.<p>Nowadays I can delve into Go documentation, packages are clear to me and I just understand how things should and should not be implemented to achieve a good efficiency and performance level. The Little Go Book makes sense, the I/O package is simple and this is probably all thanks to the syntax of Crystal, the amazing language & standard library documentation but most importantly the source of Crystal being written in Crystal.<p>I'm currently working on building a business using Go, because I absolutely need Windows target support - something which Crystal does not yet have. But the second it gets that, I'm moving back. Don't get me wrong, Go is really great and nice to work with - but Crystal is my mentor. Please note that I have not worked with Ruby before, so the whole language was new to me.<p>To summarize; even if you only wish to learn, Crystal is in my personal opinion the best choice to go with.
The Fibonacci comparison is a poor example of performance gains because Ruby is using large number data types to ensure the correct result. This is according to the crystal language website itself.<p>"However, Crystal might give incorrect results, while Ruby makes sure to always give the correct result."<p><a href="https://crystal-lang.org/2016/07/15/fibonacci-benchmark.html" rel="nofollow">https://crystal-lang.org/2016/07/15/fibonacci-benchmark.html</a>
I recently gave a quick 10 minute talk on Crystal if anyone wants a video introduction <a href="https://www.youtube.com/watch?v=oC9IknG40po" rel="nofollow">https://www.youtube.com/watch?v=oC9IknG40po</a>
First thing I look for whenever I run across another "C competitor" is to look which language it is implemented in. Usually that's C, or C++, but this time, it does look like Crystal is implemented in Crystal, which is, to me, a very good indication that this is a "real" system language.<p>I believe Rust is also implemented in Rust and Go, after a few years of being implemented in C has now a compiler written in Go.
I've done some coding Crystal when I have Ruby scripts I really need to run faster. I generally see about a 5x performance over Ruby.<p>It certainly is great to be able to jump right into Crystal coming from Ruby. It isn't very hard to convert most Ruby code to Crystal -- you just have to go through and "typify" everything. A few methods have different names and of course some don't exist but most of it is there.<p>My one grip with Crystal however, and why I haven't adopted it more generally, is that much of the "Lisp-like" features of Ruby are all but lost. Crystal makes up for some of this with macros, but it doesn't quite cut it. For example, you can't splat an array into a lambda in Crystal. Arguments have to be tuples which are compile-time bound. Little things like this feel very limiting to an experienced Ruby developer.
Was wondering how many companies actually use Crystal in production.<p>I was interested in Crystal but the lack of apps using it in production and proof of concept on the field is making me doubt its usefulness.
And it already got a port of Sidekiq: <a href="https://github.com/mperham/sidekiq.cr" rel="nofollow">https://github.com/mperham/sidekiq.cr</a>
For anyone interested in building web applications with Crystal i recently gave a talk about Kemal at PolyConf <a href="https://www.youtube.com/watch?v=KJB-nAoRSr8" rel="nofollow">https://www.youtube.com/watch?v=KJB-nAoRSr8</a>
scoped includes are a deal breaker for me when looking at new programming languages.<p>ex: non-scoped (everything in foo is added to the global scope)<p><pre><code> inport foo
{
bar.do()
}
</code></pre>
ex: scoped (everything in foo is added to the local scope, and assigned a name-space)<p><pre><code> {
bar = inport foo
bar.do()
}
</code></pre>
I find it much easier to manage programs where there are no "hidden" global variables. It's especially hard when the included files also can include files, witch all adds to the global scope.
cool.<p>can you make it faster than C though please? (seriously) i think it might even happen by accident in some cases already though. the places where C can be beaten for performance are, in my experience, from design choices in the C standards, users not understanding or leveraging those things for performance and the architecture of the compilation-unit/link process.<p>things like the struct layout rules - instead of the compiler organising things to be optimal it follows those rules for memory layout, or the calling conventions - you often have to use funky extensions to get efficient function calls.<p>other things are the lack of ability to hint the compiler that e.g. mathematical structures underly types that can be leveraged for optimisation. that const or functional purity can be trusted... etc.
The really important questions in any modern language:<p>(0) Does Crystal have a lot of undefined behavior like C?<p>(1) Does understanding Crystal programs require a lot of trial and error just like in Ruby?<p>(2) How good a job does Crystal do at preventing me from shooting myself in the foot?<p>A language isn't to be judged just by the amazing programs you can write in it. (Turing-completeness and I/O facilities have that covered.) Far more important are the totally stupid programs that you <i>can't</i> write in it.
I think the macro system looks really interesting. The main ideas seem to be that meta programming can be done anywhere and that everything is quoted by default in macros. What are thes kind of macros called, and where do they come from?
Great stuff. I love Ruby. Any idea when this will be production worthy, or at least stable enough to trust on internal projects? Will the language change much going forward?
> Have you ever dreamed of a programming language as beautiful as Ruby but as fast as C?<p>Yeah, I discovered Common Lisp back in 2006 and have been using it ever since …<p>I discovered Go back in 2009 and have been using it ever since, too.<p>What does Crystal get me that these two don't?
Crystal isn't fit to carry Nim's jockstrap as far as I'm concerned. Ruby's syntax is verbose and illogical compared to Python's. Plus Crystal has a much more restrictive license.
Stopped reading when I saw the `end` keyword... the most annoying part of Ruby.<p>Edit: I'm getting hella downvoted but I'm leaving this here. Ruby fanboys can't silence me!!! ;)
I seldom whine about blog posts but his one clearly justifies as click-bait. Not because of it's otherwise good content. But if it takes me a Google search instead of having within the very first sentences a link to the obvious target,<p><a href="https://crystal-lang.org/" rel="nofollow">https://crystal-lang.org/</a><p>there is something f~*#ing wrong with the article.
If you require the use of a GC, you can never be as "fast as C" in the general case, since there will always be specific cases where manual memory management will do something more efficient than what an automatic GC would have done --- just like a car with an automatic transmission can never be quite as efficient as a car with a manual transmission used competently.<p>If you want to talk about efficient GCed languages, you have many choices, most of which have more tooling and mindshare advantages than you language has tooling advantages.<p>Really, GCed languages are commodities these days. A lot of people have put a lot of work into the fundamental building blocks, and now people are just combining them in various ways.