My first thought as well. I personally don't find these types of "studies" very interesting, but I assume I'm not the target audience. For someone not well exposed to AI, it might be interesting.
Especially for someone not "well exposed" to generated text, they might think the words carry meaning the way they do when someone thought about the question and came to an answer. If anyone can interpret this, it's the people who know what they're dealing with (be it from exposure or, better, from a conceptual understanding)
what does this language excel at in particular? havent heard of it before and didnt find a clear use case / mission statement on the webpage. unless I'm missing where to find it. just curious to learn more.
Crystal is for when you want to write C with Ruby-ish syntax. It's been around for awhile, all the way back to when Ruby was required to get VC funding.
In my opinion, it doesn’t excel at anything beyond being pleasant to read. Maybe if Go hadn’t come along, it would have gained more traction and developed a better concurrency runtime. Very few companies are publicly using it.
Plus, since 00s Ruby = Ruby on Rails, so it didn't appeal to ruby (on rails) developers back then.
It's somewhat similar to Ruby, but it categorically is not Ruby. If you want fast compiled Ruby, TruffleRuby is actually Ruby and relatively compatible with MRI.
I surely don't want a fast compiled Ruby for the tasks I would use crystal for though.
Like every one else I also used ruby for almost everything back then, usually some hundred of lines or less for processing stuff. but for tasks that run for several hours using ruby was a frustrating experience. slowness and memory consumption aside, the duck typing system and lazy evaluation of method meaning you can run to typo after hours of running session. sure, you can fix it by write the code more carefully, running smoke tests beforehand and other stuff, but it still a chore, and when you write code all days it makes you sloppier.
having a strong typed compiled language helps it immensely, and with crystal you don't have to sacrifice the easiness of programming. and you can compile it to a portable binary and run it everywhere, no need to reinstall a huge toolchain again. (yeah rust or go can also do that, but not for ruby level expressioness language)
I'm sure crystal is not the ideal language for everything you want to use, and ruby is still helpful for what you use daily. but for some tasks, crystal surely has it own advantages. you can write very capable CLI programs without have to install a single library!
You're free to like Crystal of course, but for me even for long running tasks (almost my entire desktop, including my wm, terminal, editor are Ruby - I still use Ruby for almost everything; if anything, for more than ever), the Ruby ecosystem beats the steadily diminishing performance gap between MRI and an AOT compiled language to the extent that even going to TruffleRuby where I could keep almost all of my code, is rarely worth it for me.
But my main point was that people who do want a fast Ruby should be aware that Crystal isn't a Ruby in any meaningful sense - if you like Crystal for Crystal, by all means use it.
no, I meant when your script crashes because some careless typo in the middle of the file, then you will value a compiled language. and even when there is no typo, your program can still crash due to the huge memory consumption.
also, using crystal you have parallel and concurrency to speed up your task. sure it is not as good as other matured languages, but it still does the job.
when doing with large amount of data, and with IO involved, you will see that your JIT or AOT engine for ruby still can not cut it, because in ruby there is so many layers of safety check and failure guard it is really hard to make it faster (number calculation is not everything). with crystal you can manipulate the io stream directly, avoiding a lot of intermediate steps. you can check yourself, they make a full page for it: https://crystal-lang.org/reference/1.22/guides/performance.h...
personally I do not use a single language, I just pick the most suitable language for the job I'm doing, let it be ruby, python, crystal, rust, go or typescript. but surprisingly crystal is the one I use the most everyday.
> when your script crashes because some careless typo in the middle of the file, then you will value a compiled language
How about the crashes for all the other more common reasons? It seems like a concern unrelated to whether a language is strictly AOT-compiled or not, and whether such compilation runs through a static type checker or not, and in any case surely differs a lot among programmers' experience. (Crashes from typos basically rarely if ever happened to me in Python, same with memory constraint crashes. But I've never tried running Python on anything with less than 1 GB/core, if you don't count possibly some educational usage on ancient 90s hardware or a 2004 laptop; the lowest power device was probably a Cubietruck3 from 2013 that still had a generous dual-core ARM cortex-a7 and 2 gigs.)
But I agree with the sentiment, I hate it when programs crash and take out their work in progress or other state. I wish more languages adopted the Common Lisp condition system model, where errors don't crash or unwind anything by default and you can dynamically fix things and retry, or resume, or restart from a specific stack frame. There's even a book about implementing it: https://www.amazon.com/dp/B0DF5YVJKJ (And despite being dynamically typed, Common Lisp is compiled to native machine code, and some implementations like SBCL offer some bare-bones static checks to flag trivial typo or type mismatch issues during compilation, before running the code in question... You can also bolt on a full static type system language on top as a library if you want.)
> no, I meant when your script crashes because some careless typo in the middle of the file, then you will value a compiled language. and even when there is no typo, your program can still crash due to the huge memory consumption.
If your code is poorly enough tested for a typo to cause it to crash, a typo is the least of your concerns.
> also, using crystal you have parallel and concurrency to speed up your task. sure it is not as good as other matured languages, but it still does the job.
So you do in several Ruby implementations.
> when doing with large amount of data, and with IO involved, you will see that your JIT or AOT engine for ruby still can not cut it
I've used Ruby for large scale IO with Ruby for 20 years without problems, even on CPU's far slower, and with Ruby versions far slower than today. If you're doing IO with Ruby and the performance of your language implementation is what is limiting you, rather than spending most of the time in kernel space waiting for system calls to complete, you're doing something wrong.
It's sort of like how Nim was sometimes advertised as similar to Python but fast, even though the similarities were pretty surface level. And by having a low level alloc/free available and a principle of performance (it's the first section in their Guides) Crystal could pretend to be a mythical C or C++ replacement. I also remember likening it to Pony at some point, and/or Red, but when I went through a bunch of them years ago they all kind of blended together as just existing because of dissatisfaction (either with performance issues in Python and Ruby, or with various issues of C and C++) while not wanting to join an existing Rust/Go/whatever faction.
Could also use Matz's Spinel Ruby compiler. That's Ruby with static types using RBS but you have to give up some metaprogramming to get it.
I love the idea that we could get ractors written with Spinel and compiled ahead of time. I also love the idea that I can use Ruby for self contained binary tools.
(And for the sake of avoiding confusion, Crystal is also a great project. I'm really pleased to see them continue making progress).
Personally I don't like the thought of giving up meta programming, and I don't think it's necessary. Spinel is great as a pragmatic way of getting an AOT compiler for a Ruby subset though, but it's not that hard to support meta programming in an AOT compiler.
Though it makes it harder to generate fast code, it's not impossible given that most Ruby meta programming runs early and then doesn't change the program again, and most patterns are recognisable and it seems likely to be (I'm on and off working on my own Ruby AOT compiler) possible to statically verify for most programs that after a given point most code will not change types and so do static type inference to elide most type checks (a type in such a Ruby program will not be a given class, but a given version of a given class or meta class)
That's very funny to see, as I was just watching a presentation Matz gave last year where he was arguing static types won't be needed in the future because LLMs will just figure it all out, so Ruby with its dynamic types was well positioned to be the language of LLMs.
Basically he's saying static typing is needed for AI today because it's "junior level", but for senior level programmers they are more experienced so these types blend into the background; therefore when AI is a senior level in the future, it will also not require static typing to not make mistakes. That writing correct code will be as natural to the LLM as moving your arm is to you.
Everyone wants their favourite language to be well positioned to be the language of LLMs, in reality they will eventually be good enough to generate code directly.
And in what concerns interpreted languages, they will be replaced by agentic runtimes as it is already the case in iPaaS cloud products.
I've been waiting for something like this article for a month. The other AI companies are being left in the dust. I rip about 200 million tokens at least a day and spend maybe $3 with deepseek flash v4.1 for self hosted related coding tasks for ~20 projects i work on / maintain in parallel. Its a daily driver for sure. not even worth considering anything else, but maybe a locally run model on my GPU at the moment.
I call the API directly using a custom Open WebUI plugin (pipe function) I had Flash/Sonnet write/iterate on. I have a similar pipe function for Anthropic's API but even just Sonnet is prohibitively expensive for the same performance I get with Flash for pennies.
This is exactly how I feel. I can roughly understand why people feel sad, but I cannot relate. I feel more capable than ever before and am simply excited. LLMs have been a great learned tool for me especially to venture into new programming domains in my personal projects.
reply