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.

▲

npn 5 hours ago | parent | next [-]

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!

▲

vidarh 5 hours ago | parent [-]

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.

▲

npn 4 hours ago | parent [-]

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.

	▲	Jach 4 hours ago \| parent [-]
		> 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.)

▲

Jach 4 hours ago | parent | prev | next [-]

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.

▲

Lio 5 hours ago | parent | prev [-]

Truffle is very good.

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).

https://github.com/matz/spinel

	▲	ModernMech 5 hours ago \| parent [-]
		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. https://youtu.be/XVaRRryB_cQ?si=CuXiMDdwccH6wOra&t=760 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.