One of Ruby’s pillars is metaprogramming. Crystal lacks that entirely, making it a non-option for many Rubyists.
Which is fine since the language is not really aimed at replacing Ruby (despite this blog post's headline)
Switch from Ruby to Crystal
21–30 of 37 posts
Re: Switch from Ruby to Crystal
#22Earlier quoted context omitted.
Crystal does global type inference to be performant while “feeling like a dynamic language” - as claimed by the article. This leads to very high compilation times (which is non-linear so a program double the size will likely take more than double the time to compile) and last time I asked I was told it is not a solvable problem.
> Crystal does global type inference I think they stepped back from this a few years ago. It's not globally inferred anymore - you need to specify some types manually.
Yes. The basic rule is that things that could be stored on the heap will need to be explicit or inferrable directly from the constructors. But as method parameters generally (except sometimes, like in procs) don't need typing it is quite possible to build full programs using only global inferrence. But that is usually not how programs are built - that would do away with things like objects and structs and other constructs that are extremely ideomatic.
Re: Switch from Ruby to Crystal
#23> Electric Vehicle Startup Nikola Motors is using Crystal to power their software in production Not necessarily a ringing endorsement.
Well, not from a PR standpoint (and the author may not even be aware of what’s up with Nikola lately), but it’s used in production which is a huge positive.
Re: Switch from Ruby to Crystal
#24Anyone have production experience with Crystal? I know it's not 1.0 yet, but there are some fairly mature web frameworks available that make the language look pretty attractive.
At my previous job there was a need for a microservice that would compute a PhotoDNA hash of images and then compare that to a list of "known bad" material. Since this was very CPU-intensive we opted for Crystal instead of the usual Ruby that was used for almost everything else there. When I left it was churning away at ~500 images per second (over many cores, obv).
Development was pretty smooth and it was pretty easy to get new people onboarded since it look so much like Ruby. Some caveats though:
- If you want every last bit of performance, type signatures are very needed. Otherwise the compiler will still have to determine at runtime if the argument to a function is a uint32 or a uint64 for example.
- Library support is definitely lacking compared to Ruby. For example, AWS has an official SDK for Ruby with support for everything you can think of. Crystal has a 3rd party library with support for a few services. It's just not comparable.
Re: Switch from Ruby to Crystal
#25Seeing as this is published in the LogRocket blog, is it being used by the company? Would be great to hear more about experiences in production.
Probably not, they have like hundreds of thousands similar articles, which they use as marketing and SEO for their product AKA content marketing.
Re: Switch from Ruby to Crystal
#26I tried Crystal at the start of this year for an experiment and found the language is still in its infancy stage. Thou there are good things happening in their community but still a long road towards becoming a serious contender for switching.
Having said that, Crystal can definitely be considered for building micro-services to delegate more resource intensive tasks.
Re: Switch from Ruby to Crystal
#27I have a love-hate relation with Crystal. Every few months, disenchanted with the core maintainers' priorities, lack of platform and tooling updates and overall deadland syndromes -
I denounce Crystal, promise I will never use it again, startup a golang or Rust project, make some non trivial toy stuff and then come crawling back to Crystal.
I hate the fact that I love this language and the fact that nothing else (except perhaps f# and nim) seems to have the same effect on me.
My favorites Crystal features are its do-end syntax, dat sexy type system hnnnnghhh... , domain modelling using sum types, null checking using types, ultra simple OOPs, insanely productive std and its sheer performance.
The bits about the language I detest are the overuse of macros, the utter lack of any platform (windows, http/2 etc.) or tooling improvements (IDE support, slow compilation). The core maintainers are amazing but have a weird obsession with just refactoring the language semantics. Things which really would matter for any language usage are just relegated to GH issues which haven't had any comments on it for months (if not years).
The lack of a BDFL and corporate sponsorship really hurts Crystal bad. Its a language without directed growth. For a language which seems to be used the most for web servers, it lacks http/2, db pipelining and async db drivers. There have been plans for redoing the http module for years but it hasn't been done yet.
Yet, I love this language despite all its shortcomings. I find it to be one of the most readable languages out there. The community is full of amazing individuals who are ever helpful and welcoming. The core maintainers are super talented developers who really value quality of code.
Right now I am working on an api servers and have 3 early implementations - one in Rust-actix, one in pure crystal (no framework) and one in Go-Fiber. The joy of using Crystal and feeling like I am in control of the project are reasons which are pushing me towards using Crystal for the project. But I know that by the next few years, we likely still wouldn't have http/2, async drivers, nice IDE support and many other features that I really need.
And so, I will likely have to go with Go. (Rust syntax is just too complex for my taste. And I am not talking about the celebrated borrow checker).
I like go.
Go is simple.
Go is Productive.
Go is... just not Crystal.
Re: Switch from Ruby to Crystal
#28One of Ruby’s pillars is metaprogramming. Crystal lacks that entirely, making it a non-option for many Rubyists.
It's true the runtime meta programming is missing. Other comments mentioned some compile time options. But in my experience most Ruby doesn't really use metaprogramming for really hard cases. I've translated some larger modules to crystal recently and while there are magic things like activerecord out there, most metaprogramming is... simple. Often a glorified "I'd rather write a loop than repeat 3 similar method implementations". Outside of generic framework code I never ran into something meta which can't be trivially expanded to slightly repeating (and more readable) code.
Re: Switch from Ruby to Crystal
#29Crystal is impressive work and the tools work seamlessly; it demonstrates how a statically compiled language can look when intelligent type inference is involved; wonder why a similar approach has not been taken by Python (well, Nim is a rather different language); the major point which concerns me is that the compiler get's rather slow when the codebase is large.
Re: Switch from Ruby to Crystal
#30> Electric Vehicle Startup Nikola Motors is using Crystal to power their software in production Not necessarily a ringing endorsement.
Well, not from a PR standpoint (and the author may not even be aware of what’s up with Nikola lately), but it’s used in production which is a huge positive.
> Nikola .. production
Well, that is the crust of the issue. Nikola has not really shown that they are not vaporware, and hence there really is no production.