alt Hacker NewsI'm fairly torn about this, honestly. When I was reading the list of "why not"s in the tweet, I just found myself wondering the converse. Why put time into solving those problems - accepting that it won't require nearly as much time as it would have previously - when there are existing tools that already solve those same problems?
You do provide an answer to this question in your comment, in this sentence:
> Ruby continues to have a good balance between expressiveness, and the ease of reasoning about the code, relative to the amount of annotations and boilerplate you need to throw in to get there.
But is "it is easier to read" really enough of a benefit? Even accepting that it is true, it strikes me as a pretty fundamentally aesthetic judgment, and I'm just not sure that matters enough. And is it even true? I feel like after doing this job for a couple decades, I don't find there to be huge differences in legibility between the common high level languages. This is especially true now that I'm reading far more than I'm writing, and relying on static analyses to determine correctness, far more than on my own interpretation of the code.
When I first got into rails, what was awesome about it was how much boilerplate it could either generate or abstract away for me. But my sense is that boilerplate has just become way less of a problem over time... So I'm left unsure what the killer feature of rails is anymore.
But this argument applies to pretty much any framework for anything, and I still think frameworks remain very useful. But maybe they just aren't very ... interesting? But then if everyone comes to that conclusion, then it's even harder than it already was to have a community of people contributing to the frameworks and caring about their quality.
I don't have a conclusion here, just this stream of thoughts about it!
Replies
As you said in another post there is some "to each their own" in it, but I don't disagree with what you wrote. If I started a new major project, it's a coin flip whether I would choose Ruby today (Rails is a separate sub-conversation). However, what I would choose instead doesn't feel obvious either. I know "it depends" is a cliche, but it is so for a reason.
I half-agree with this sentiment and want to stream-of-thoughts back at you in response:
>I don't find there to be huge differences in legibility between the common high level languages. This is especially true now that I'm reading far more than I'm writing, and relying on static analyses to determine correctness, far more than on my own interpretation of the code.
At best I have 70% confidence in what I'm about to say. Without AI agents, I feel like a language and ecosystem's expressivity could shine more when a project had heavy and finicky business logic. It matters less when you can ask your bot to interpret the invariants and feature behaviors at a broad scale. Again, I'm not 100% confident in that claim.
Even prior to AI agents, in such a project, first and foremost you needed to understand why the piece of functionality you're looking at does what it does within the business domain. The code was already secondary, but I think what agents have changed (for me) is that by lowering the cost of maintaining types, tests, and documentation, the code (and thus its expressiveness) might be becoming tertiary? Even when I was the one who wrote some documentation, half of the time I would go straight to the code to get an answer, rather than read my past explanations. Perhaps a sign that I am a bad doc writer? But that's where I felt the combined language-ecosystem expressiveness mattered most (along with keeping to architectural standards): I need to look back at something to understand it.
To try and end with a conclusion for my own thinking aloud: I feel like further emphasizing those three aspects (types, tests, documentation) flattens the demands on "legibility". Bouncing between tests (and even types) in Language X vs Language Y is far less differentiated than bouncing between Language X's ORMs vs Language Y's ORMs (or dataframe libs, or http servers, et cetera).
Well, for people who love Ruby and prefer reading it to Rust (which is, let's face it, not a hard preference to have) then that seems a good enough reason to want to continue using it.
The performance issues here seem kind of a distraction. There is TruffleRuby and JRuby, which has been able to run Rails for a long time. If you want something faster than plain old Rails+MRI you don't need to rewrite everything in Rust to get it. You can get something nearly as good, while sticking with the Ruby you learned and understand well. And the code will be more token efficient and easier to review, as it'll be higher level.
It's always surprised me that language communities around Ruby and Python were never more concerned about their vulnerability on the performance front. So much great work has been done on alternative JVM based implementations, they were mostly ignored, and now well known advocates of those languages are openly arguing to rewrite everything in Rust just to get better performance - despite the large downsides of doing so. That was a huge missed opportunity and strategic misstep, IMO.