We have all of this running on a 16 MHz machine, yet on todays computers with 32GB RAM we have highly memory intensive desktop apps that use java and even electron.
Even a text editor today written in javascript using Electron will take 1GB+ without considering the user could open multiple documents which can increase the RAM usage.
I banned any Electron turd in my machine, amd64, 8GB, Pentium Silver N5030. I am even trying a VS Code clone in Rust+Tauri as my IDE for Rust programming. It's semi-Electron, but far lighter.
Where I live there is plentiful water. A drought essentially never occurs. I will never have to worry about concerning myself with whether I take a 5 minute or 15 minute shower. You can imagine then, that people that live here generally don't worry about water usage as you might in a severe desert environment where water is a scarce resource.
And that's why so many applications today are giant chonks of resource waste. For a long time now we've had it to spare.
Disregarding the moral debate about resource wasting of course. That's a different discussion. The why is: we have had the resources to burn, so they do. Resource usage is as tight as it has to be very generally speaking.
What a ridiculously negative comment. Obviously ragebait, but I'll bite anyways.
Did you forget that until five minutes ago humans used to read the code? And they needed to understand it? Yes, there was an actual desire for great Ruby-like syntax without the implications of using it, like its performance characteristics and the need for an interpreter.
Yes, it didn't go mainstream. Should we all abandon every project we've ever worked on because they're not "relevant"?
The challenge for Crystal is that we also have TruffleRuby which gets you the elegance and Ruby interop. To me Crystal feels like it's at the same time too different to Ruby to benefit from the similarity and too similar to create its own viable niche.
HN is full of cynical comments like the above. We should be celebrating people trying things and doing things differently... I can almost guarantee you that the person who posted this cynical comment is not working on anything particularly relevant or useful.
My message to the HN community: HN is literally bankrolled by YC. If Crystal doesn't deserve to exist because other languages exist, why exactly should I care about your bullshit uber-for-dogs startup, or whatever not particularly original AI crap you think you're changing the world with these days? Get real. If you want people to be open to your ideas, maybe you ought to make an effort to be open to the ideas of others, and cultivate a climate where discussing different ideas is possible. Don't treat every HN post as an opportunity to opine on how you think the work of other people is flawed.
Crystal never aimed at Ruby interoperability, it's inspired by Ruby's ergonomic syntax.
You should learn this language if you want the nice developer experience, great stdlib, managed memory, native performance. Similar reasons to why you'd learn Go.
Prior to LLMs, Crystal was my language of choice when I needed a distributable binary. It works great for this, and for the kind of packages I was writing - mostly agent-daemons lurking in servers - the networking worked great. The only real alternative was golang, which I've never really liked and has (had?) a more complicated linking story too. The typing worked well too, if used with discipline - if it compiled, I could be pretty confident it would work. I still have systems deployed running Crystal agents, in production, without issue or memory leaks, for years.
LLMs though - I confess they've changed the calculus. Now I no longer have to look at the language, and obey its stupid ideas about error handling, I just use golang for its better library support. But I still have a soft spot for Crystal!
> It just looks like Ruby, but it isn't Ruby and it is a compiled language?
It's close enough that porting things is often trivial (sometimes just slap a few signatures), as long as the code doesn't go crazy with metaprogramming. Yes, it's not the same and stdlib is a bit different. But it's a lot further than "looks like" Ruby.
As a Senior Engineering Manager, I can tell you that, per my directive, we've actively standardized on Rocky Linux. We're moving away from everything else, including RHEL.
I was a long-time RHCX (Red Hat Certified Examiner). From around 2005 to 2015. When IBM bought Red Hat, I saw the writing on the wall, but I was optimistic it might be a Good Thing™. It wasn't a good thing. Red Hat has been pretty stagnant, as the article says. RH is 90% AI slop today. They'll live on as a brand for a long time, but from a technical perspective, they don't have much to offer.
In the early 2000s, I recommended paying for RH because their technical support was amazing. Now, it's mostly 3rd-party contractors who know less than what you can find with a Google search. Unless you are extremely lucky, you never get to talk to actual RH engineers anymore.
I really like the Red Hat ecosystem and system design. However, I feel like they've petered out and won't recover from where they're headed. (I say, as I type this on my personal laptop running Fedora).
TL;DR: RH went from a super-nerd company to coasting on its former success.
Even a text editor today written in javascript using Electron will take 1GB+ without considering the user could open multiple documents which can increase the RAM usage.
reply