Re:Crystal Language That Aims at C Performance with Ruby Syn...
by rvz on Friday April 02, 2021 @04:10PM
(#26675422)
> If you want a fast language that is mature and has a big community with lots of documentation and resources, I'd go with Rust.
I'm sure that when Rust had their 1.0 release 6 years ago, there was little to no documentation and a small immature community at the time. We had the same people saying that it isn't mature and the same fans using it in production since pre-1.0. This is also the case with Crystal.
Fast forward today, Rust itself has matured, but unfortunately the crates ecosystem is still immature.
Each time I see a crate on crates.io, the version is below 1.0 and it is reflected on the "work in progress" disclaimer warning of unsafety guarantees in the mountains of other dependencies it uses, which makes me think twice about importing it; especially if it isn't pure Rust. I would expect better quality crates in the Rust ecosystem especially 6 years on from 1.0, but today, this is still not the case. I have the same expectation with Crystal's ecosystem, as it is now 1.0.
Suppose you are using Ruby in a system (Not using Rails) for dispatching events and then calculating how long these events take with tens of thousands of users and you then realise that the language itself was the bottleneck. Yes, I'm talking about Deliveroo: [0]. Yet for them maintaining two languages and using Ruby FFI and rewriting it in Rust somehow sounds much more better than adapting it to Crystal. (since there were those who also used Rust in production in pre-1.0)
If this was in C, C++ or Java then [0] would make sense. Ruby to Rust and still using both languages after the rewrite doesn't make sense when I can just 'adapt it' to Crystal in 5 mins and it just works. Even Elixir makes much more sense.
I'm sure that when Rust had their 1.0 release 6 years ago, there was little to no documentation and a small immature community at the time. We had the same people saying that it isn't mature and the same fans using it in production since pre-1.0. This is also the case with Crystal.
Fast forward today, Rust itself has matured, but unfortunately the crates ecosystem is still immature.
Each time I see a crate on crates.io, the version is below 1.0 and it is reflected on the "work in progress" disclaimer warning of unsafety guarantees in the mountains of other dependencies it uses, which makes me think twice about importing it; especially if it isn't pure Rust. I would expect better quality crates in the Rust ecosystem especially 6 years on from 1.0, but today, this is still not the case. I have the same expectation with Crystal's ecosystem, as it is now 1.0.
Suppose you are using Ruby in a system (Not using Rails) for dispatching events and then calculating how long these events take with tens of thousands of users and you then realise that the language itself was the bottleneck. Yes, I'm talking about Deliveroo: [0]. Yet for them maintaining two languages and using Ruby FFI and rewriting it in Rust somehow sounds much more better than adapting it to Crystal. (since there were those who also used Rust in production in pre-1.0)
If this was in C, C++ or Java then [0] would make sense. Ruby to Rust and still using both languages after the rewrite doesn't make sense when I can just 'adapt it' to Crystal in 5 mins and it just works. Even Elixir makes much more sense.
[0] https://deliveroo.engineering/2019/02/14/moving-from-ruby-to...