Crystal is a Ruby inspired compiled language, it's blazingly fast with a very low memory footprint. It uses LLVM for emitting native code, thus making use of all the optimizations built into the LLVM toolchain.
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.
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.
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.
We use Crystal at RainforestQA to replace our heavy-load / slowish Ruby microservices. It's been great so far and we love it. We're also increasing the adoption to Crystal inside the organization.
Also Crystal has a dedicated a wiki page for production users
While elixir's syntax is inspired by ruby, the semantics are vastly different. That change in semantics is really good for elixir, because it means it can take advantage of the unique properties of the erlang vm, but it's worth noting that crystal is far far closer to ruby than elixir. For better and for worse.
The syntax similarities between Elixir and Ruby stop as soon as one moves on from reading short blog post to writing real code. They are extremely different languages. Knowing Ruby helps only to remember the names of some standard library modules and functions, which were designed on purpose to match the name of the corresponding Ruby modules and methods, but not all of them. A vanilla example:
which by the way highlights the extra verbosity of Elixir compared to Ruby. It's less verbose on more complex examples, mainly because of pattern matching, but the proof would be too long for this reply.
I believe that Ruby also has that & shortcut (or similar) but it's totally unreadable. I never used it and I don't even want to check the exact syntax. Is it the only way it works in Crystal?
I hear this a lot but I keep seeing more and more Ruby devs moving to it trivially and as someone who reads-not-writes Ruby code I find it just as trivial to grok it.
So I think the differences are there but they’re being overstated from a transfer of skills standpoint.
Differences don't necessarily make it hard to move to another language. Many developers moved from Java to Ruby between 2006 and 2010, including me, and Ruby is pretty different.
Elixir would probably not have been a huge improvement over Ruby if they switched languages for performance reasons. Elixir is great for many things, but raw number-crunching performance is not one of them.
Their developers are already proficient in Ruby. Crystal is a very, very close cousin of Ruby, syntactically and structurally. This isn't like jumping from Java to Haskell.
>What is it about Crystal that outweighs the very boring practical downsides of production use of obscure and immature languages?
Tons of startups, and tons of billion dollar companies, run on Ruby / Rails. How is it "obscure"?
Crystal sure.
Then again, PG who created Hacker News used Common Lisp, which at the time had about the same developer pool as Crystal give or take (well, not really, but close enough, compared with industry favorite languages).
In silicon valley and among most of the startup community, Ruby still dominates the landscape, even when compared with Node.js, Python, etc. There's plenty of talk of companies re-writing their infrastructure in node, but why would you do that when you can have Rails and/or Crystal? Furthermore, if you ever need something from NPM, you can just throw it in a Google Cloud Function or in Lambda.
It's interesting that everyone's still using rails in silicon valley. Here in the UK, Laravel (PHP) and Django (python) are both more popular than Rails for new projects. But I hear that PHP isn't popular at all in the US?
PHP in the U.S., especially in the startup world, is seen as "oh, you develop in third world countries". That's the perception these days unfortunately.
That said, I was an avid PHP developer in the U.S. about 10-15 years ago and I always liked the language. There's just no one learning PHP anymore since all the kids just learn js, and no one trying out "hipster" languages like ruby/crystal/go/python/elixr/d/nim/rust/etc is going to try crusty old PHP.
I will say though that PHP, without any frameworks, is probably my favorite thing to develop a simple standalone site specifically because it lets you break all conventions and just output some damn content possibly with some simple logic involved and without using classes/mvc/etc.
Probably because they loved the language. Humans are humans, and not everything is made with a rational financial decision. If you use the language, and like ruby and static typing, you'll find that there's a lot to love.
I see your point, but I sympathise with it less and less as time goes on. Programming languages are just tools. Software development should strive to be a proper, rational, engineering discipline.
Humans aren't robots, but one's choice of development tools is steered by real forces, both technical and business. I don't see that whim, unconstrained by such forces, has any place in the decision. Same goes for curiosity.
If it were my decision to choose a language to use in production, I'd want to go with a safe boring choice like Python/Java. Mature and stable on lots of platforms, easy to hire for, plenty of libraries and tooling.
Taking a risk is sometimes the right thing to do, but I don't see choice of programming language as being one of those times.
It's not that I don't like neat languages like Crystal - I really do - and I'm certainly not trying to put them down. I just wouldn't want to try to argue to management that using it is in the company's best interest.
> Software development should strive to be a proper, rational, engineering discipline.
Well, to use an analogy from civil engineering, I don't think choosing a programming language is always as critical as which type of concrete you choose and how it's reinforced. While it's true you wouldn't choose just any language, there is more room for preference here. Especially because you can switch languages for a project, but practically can't switch the material used in the foundation of a building.
> I just wouldn't want to try to argue to management that using it is in the company's best interest.
In some companies you don't need to argue with management about that decision. Also, a language being less popular or obscure doesn't mean you can't evaluate it's stability and feel comfortable enough with where it's at to use it. I'm glad people do because otherwise we wouldn't even see any language as popular as it is.
What do you mean? If you're 100kloc in, you pay a considerable price in jumping ship. Rewriting means throwing out your investment. Interfacing two different languages for one project is rarely a good move.
> I'm glad people do because otherwise we wouldn't even see any language as popular as it is.
Sure, me too. Like I said, I do like new programming languages, I just don't see myself using one for serious work.
It's always a tradeoff between having fun and accepted practice, and I'm glad for the brave souls who do use Crystal in production. After all, every mature language was once someone's toy, and you can never get from one to the other without many successive firsts.
I'm not here to recommend people use it in production, but I can understand the mindset of people who do.
Even today, a tiny proportion of software development is actually done with a respectable engineering process.
It's not a myth, and I don't see that it should be dismissed as a pipe-dream to think that this sort of serious engineering approach could be adopted outside the critical-systems industry.
