> [...] I’ve used a number of languages and dabbled in a few frameworks but nothing I’ve used brings me joy like ruby does.
Totally agree, 100%. Ruby isn't "perfect", but it's a pleasure to use. As in, I actually want to use it, not just am "ok" or ambivalent about it. I have my nitpicks about Ruby, about Rails and other things just like anyone, but I second your comment that nothing else has been able to match that sweet spot of great productivity that is a direct result of a fantastic developer experience created through a programming language that just "flows" linguistically so much easier than...well, everything else I've personally ever seen (with Python being an arguable tie there).
My biggest gripes about Ruby and its ecosystem have been the pain in the posterior it is to deploy apps (all those gems, which eventually wind up abandonware and now you've got dependency hell, especially with apps not maintained in 5 years or something) and its relative sluggishness when compared against some other deployable artifacts.
Personally, I think Crystal (https://crystal-lang.org/) fixes pretty much all of this, as long as you're willing to cede a few things due to the nature of the beast (compiled vs. interpreted).
And that's not considering the speed improvements Ruby's gained in the last few years (3x3); it's undoubtedly far better now than when I last released an app with Ruby or Rails (circa ~2016, maybe ~2017ish). I'm just so disappointed that everything's "JavaScript this" or "Go(lang) that". Not that I have a problem with Go (I do have many problems with JavaScript, which I strongly dislike, but that's a separate topic), it's just that this industry acts like lemmings in a lot of cases. "New shiny!" attracts the horde, and that critical mass creates a new tyranny of being the "snowflake" technology/stack/developer, which has a lot of risks for both the organization paying for what you build in tech stack $X (rare language, can I replace this hire later, can I find somebody that knows $X, lower risk if we use $Y b/c we can find plentiful/cheap talent in $Y or $Y salaries are lower than $X), and by that token therefore it's a risk to the developer's career to get hard core on anything perceived as "snowflake" or otherwise not "flavor of the $(month || year || interval)".
Which is just so sad, and I feel like it's a contributing factor in Ruby's decline (in terms of hiring demand for full time positions). It's not at all the technology's fault, and it's not a performance "issue" whatsoever anymore (really wasn't in the first place unless you were nickel and diming literally everything or did stuff just plain stupid).
Go, Rust and friends all have their own benefits and drawbacks too, and they're fine languages with their own killer features and/or quirks. They can produce pre-compiled code for a variety of platforms from a single machine, resulting in (if desired) a single file binary deployable artifact that can be installed and simply run, no dependencies to install, no OS configuration necessary. Ruby, without lots of hacks potentially questionable hacks and potential future abandonware, doesn't do that at all AFAIK, but Crystal can also produce fat binaries just like Go can (and I assume Rust can too), making it the best of both worlds in my opinion.
Crystal: compile Ruby-like code to a "fat" binary for single file, zero-config/dependency deployment that runs true multithreaded apps as native code. And most of those tradeoffs you'd have to give up because "compiled" - most of those you can work around pretty easily and I've heard you can even have it embed source code in the binary to be run in interpreted mode at runtime, so you can have your app compiled for the vast majority of use cases, then have it run its own code inside itself interpreted/JIT'd when run, giving you access to many (all?) of the features you'd otherwise think you'd have to sacrifice.
So yeah, I love Ruby, and I think Crystal is definitely the next evolutionary step for that language and ecosystem. No hate on Ruby there whatsoever, I just see it as a more mature option for a lot of use cases, but definitely not all. I don't know if you can do that metaprogramming magic Ruby is so amazing at any faster in Crystal since you'd have to run the code as interpreted at runtime, not pre-compiled (AFAIK), so it's not an outright replacement. Still, I think it's damn near one, and you can probably "color outside the lines" just a tiny bit as needed when you absolutely MUST have that feature anyway.
Okay, end stream-of-consciousness. I haven't been able to sleep for 3 days, so rambling is a sort of unavoidable side effect...sorry about that. But yeah, try Crystal if you haven't already, you'll likely be very happily shocked at how amazing it is!
I wonder why Crystal is not more popular today that it reached 1.X, as you say, it fixes some important Ruby issues but most importantly it also fixes Elixir's weaker points.
I can't comment on the Elixir stuff since I haven't really touched it at all yet (only ever seen one job opening in hundreds over 5+ years mentioning Elixir - only one, total!). But I have a theory on the rest...
I think the actual reason why it's not more popular is something I personally call "The Tyranny of the Masses". In short, what's popular/flavor-of-the-month is automatically "right", and everything else is automatically "wrong" or "high risk" in our industry. These are of course not real demonstrable facts, but people's perceptions that influence choice of technology stack.
Take JavaScript/Node.js for server-side apps for example. MASSIVE ecosystem. Near total ubiquitous skill availability in the developer market (with one major caveat I'll explain below). Not perceived as a rare or difficult skill to pick up, so salaries can be on the lower side than, say, a C developer with Linux kernel experience, for example. To employers and managers, this is a much more attractive mix than something where all of the above are in any way seen as "less true".
Compare that to Elixir. Not around nearly as long as JS, far fewer learning resources, relies on perceived turbo-nerd/esoteric "Erlang" runtime, so support availability may be harder to find and more expensive (so what's that mean for the employer's support and availability contracts, uptime agreements, and/or regulatory environment should something go sideways?). Not nearly as many available published libraries as on NPM (yes I'm sure Elixir's are far higher quality, but remember: it's perception, not fact, at play here). Skilled hires in market not nearly as common or ubiquitous as JavaScript devs are. Nobody has 20 years of Elixir experience. 20+ JavaScript experience does exist though (again, perception matters, not the fact that JS 20 years ago was laughably bad and would almost never even run today!).
Then there's the "safety" factor for production apps. JavaScript? Billions of apps all over the place. Nearly ever prod scenario imaginable has happened and 90% of them have at least been blogged about. Async/await in single threaded runtime using multiple processes for concurrency? Yep, somebody's done it. True multi-threaded single-process concurrency? Yep. Big, perceived as financially stable tech company behind it? Yep. Large market/ecosystem of firms that provide high quality support at reasonable prices to compete for business? Yep. Elixir? Arguably none of that, and definitely not to the quantity - again, not quality, quick-glance perception, optics here is all people look at - that JavaScript has behind it.
Is Elixir a better language, runtime, and ecosystem than JavaScript/Node.js? Almost certainly, and you can probably prove that pretty objectively with only some very obscure/esoteric exceptions having merit. I mean, dude, it's JavaScript, that's a low fucking bar! (Yes I'm a JS hater, go ahead, flame away! "YOUR BOOS MEAN NOTHING TO ME, I'VE SEEN WHAT MAKES YOU CHEER!" - Rick Sanchez)
But is it popular? Not compared to JS! JS is like that air-headed valley girl high school cheerleader that every guy wants to sleep with, and Elixir is that nerdy girl with a good heart, a great head on her shoulders, who can respect people and while she covers nearly every inch of her skin with clothing, leaving everything to the imagination, even a blurred photo would tell you that underneath all that, hot damn! She's the total package. But you want the cheerleader because of the popularity contest. You'll be the big man on campus if you get with her! Well, maybe not "the", more like "a", one in an ever-growing series.
Fast forward to 5-10 years post HS graduation. Cheerleader? Trailer trash with 6 kids on food stamps and zero drive in life whatsoever. Nerd girl? CEO of her own startup, and somehow even hotter now than she was back then!
Oh how foolish we are for falling into the trap of popularity. And while some may feel justified in their subservience to that popularity because reasons, some of them even good, we'll all feel curse the lack of choice, the absence of competition, the void of creativity and innovation - that we inevitably acquiesce to the clamors of the mob. Our future's bright hope will be made dim indeed when we succumb to the Tyranny of the Masses.
EDIT: The caveat on JS skills I mentioned above? Almost everybody who says they "know" JS is really at best an intermediate-level developer with it. It has a lot of special use cases, variations in how things work depending on engine, execution context (server app? browser engine?), and even today in 2021 we still see even self-described "experts" telling you to use alert() to get debug data instead of at the very least console.log/warn/error, etc. The language has made some frankly just plain weird (IMO flat out bad) design choices, like allowing more arguments to a method than its signature declares, and used to be so vastly snowflaked (nearly zero consistency between browsers) that you absolutely had to write an ENTIRE new JS app for each browser you wanted to target. Granted, that was the Netscape Navigator days, when Internet Explorer (Exploder?) was version 5, the rightly-maligned version 6 didn't exist yet, Firefox was a twinkle in somebody's eye, and Microsoft even shipped IE for the Mac (like OS X 10.1 or 10.2! Remember Aqua, the striped textures? Ahh, the good 'ol days...) It's come a long way since, but it still fundamentally suffers from having more bad documentation than good, and while most consider it a "lowest common denominator", that's unfair to people who really are true experts in the language, who will tell you that when you get real deep with Node or V8, you can see some gnarly shit. It's a god-awful security nightmare; why the hell would I let whatever website in the world run whatever code they want directly on my machine all willy-nilly, automatically accepting every API call by default, denying almost nothing, with unrestricted access to some pretty advanced/low-level APIs that can do some serious damage if abused? And people say Flash was bad (well, they did only after Steve Jobs made a big deal about it; he wasn't wrong, but virtually NO ONE hating on Flash back then had any idea how it even worked before Steve bitch slapped it into oblivion and rightly so). Its syntax is arguably archaic (we don't need semicolons to end statements/lines these days, language parsers are much more capable now; look at Python, Ruby!), it's littered with inconsistencies in the language itself, and since everybody's a hammer (JS "expert"), everything looks like a nail (a suitable use for Node/JS/DOM/Script), even when it's damn well obvious, painfully so, that it's absolutely NOT. All this, and yet everybody's somehow an "expert" with JavaScript. Really? Really?
In all these years the only thing I've seen has been despise against JS, if it was popular it was 'cause we hated it, we hated how bad designed it was, but then Node appeared and someone said that isomorphic JS would be a good idea as looking for backend engineers would be easier.
Now there are tons of JS libs in npm, but a big percentage are quite minimal, unnecessary and of questionable quality.
It isn't complicated. Crystal doesn't work on Windows. If elixir ecosystem is small, Crystal is 10 times smaller. Unless there is an active community that decide to do the grind and fill in all the missing pieces. Crystal may remain a niche in the foreseeable future.
Totally agree, 100%. Ruby isn't "perfect", but it's a pleasure to use. As in, I actually want to use it, not just am "ok" or ambivalent about it. I have my nitpicks about Ruby, about Rails and other things just like anyone, but I second your comment that nothing else has been able to match that sweet spot of great productivity that is a direct result of a fantastic developer experience created through a programming language that just "flows" linguistically so much easier than...well, everything else I've personally ever seen (with Python being an arguable tie there).
My biggest gripes about Ruby and its ecosystem have been the pain in the posterior it is to deploy apps (all those gems, which eventually wind up abandonware and now you've got dependency hell, especially with apps not maintained in 5 years or something) and its relative sluggishness when compared against some other deployable artifacts.
Personally, I think Crystal (https://crystal-lang.org/) fixes pretty much all of this, as long as you're willing to cede a few things due to the nature of the beast (compiled vs. interpreted).
And that's not considering the speed improvements Ruby's gained in the last few years (3x3); it's undoubtedly far better now than when I last released an app with Ruby or Rails (circa ~2016, maybe ~2017ish). I'm just so disappointed that everything's "JavaScript this" or "Go(lang) that". Not that I have a problem with Go (I do have many problems with JavaScript, which I strongly dislike, but that's a separate topic), it's just that this industry acts like lemmings in a lot of cases. "New shiny!" attracts the horde, and that critical mass creates a new tyranny of being the "snowflake" technology/stack/developer, which has a lot of risks for both the organization paying for what you build in tech stack $X (rare language, can I replace this hire later, can I find somebody that knows $X, lower risk if we use $Y b/c we can find plentiful/cheap talent in $Y or $Y salaries are lower than $X), and by that token therefore it's a risk to the developer's career to get hard core on anything perceived as "snowflake" or otherwise not "flavor of the $(month || year || interval)".
Which is just so sad, and I feel like it's a contributing factor in Ruby's decline (in terms of hiring demand for full time positions). It's not at all the technology's fault, and it's not a performance "issue" whatsoever anymore (really wasn't in the first place unless you were nickel and diming literally everything or did stuff just plain stupid).
Go, Rust and friends all have their own benefits and drawbacks too, and they're fine languages with their own killer features and/or quirks. They can produce pre-compiled code for a variety of platforms from a single machine, resulting in (if desired) a single file binary deployable artifact that can be installed and simply run, no dependencies to install, no OS configuration necessary. Ruby, without lots of hacks potentially questionable hacks and potential future abandonware, doesn't do that at all AFAIK, but Crystal can also produce fat binaries just like Go can (and I assume Rust can too), making it the best of both worlds in my opinion.
Crystal: compile Ruby-like code to a "fat" binary for single file, zero-config/dependency deployment that runs true multithreaded apps as native code. And most of those tradeoffs you'd have to give up because "compiled" - most of those you can work around pretty easily and I've heard you can even have it embed source code in the binary to be run in interpreted mode at runtime, so you can have your app compiled for the vast majority of use cases, then have it run its own code inside itself interpreted/JIT'd when run, giving you access to many (all?) of the features you'd otherwise think you'd have to sacrifice.
So yeah, I love Ruby, and I think Crystal is definitely the next evolutionary step for that language and ecosystem. No hate on Ruby there whatsoever, I just see it as a more mature option for a lot of use cases, but definitely not all. I don't know if you can do that metaprogramming magic Ruby is so amazing at any faster in Crystal since you'd have to run the code as interpreted at runtime, not pre-compiled (AFAIK), so it's not an outright replacement. Still, I think it's damn near one, and you can probably "color outside the lines" just a tiny bit as needed when you absolutely MUST have that feature anyway.
Okay, end stream-of-consciousness. I haven't been able to sleep for 3 days, so rambling is a sort of unavoidable side effect...sorry about that. But yeah, try Crystal if you haven't already, you'll likely be very happily shocked at how amazing it is!