chao-
2 days ago
Mostly agree with José's tweet linked in the article: the effort required to make anything better is lowered substantially. For example, the primitives for Ruby concurrency to be good have been there for 3-4 years. Many long-established ecosystem libraries and conventions didn't adopt these newer tools, and I don't blame them for that. Many might have required breaking changes. Breaking changes are a tough sell for decade-old, stable libraries. Then for application teams, prior to agentic engineering, it would be a big lift to migrate large projects to a new set of libraries. But that's not the case anymore!
Ruby is never going to be a BEAM language or Rust, but I'm pretty excited for the near-term performance improvements in Ruby; not only the base language (e.g. Spinel), but in the broader ecosystem. When you avoid a handful of footguns, you maintain some basic architectural consistency/organization (and get your agents to do the same), 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.
For someone who is persuaded they should never read the code anyway, then that's not a benefit that they desire, vaya con dios! There's not much conversation to have when working from such different premises.
sanderjd
2 days ago
I'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!
mike_hearn
2 days ago
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.
julik
2 days ago
True, and there is also Crystal which is - in a few aspects - better than Go even, and has way more pleasant aesthetics.
The way the JVM didn't take off doesn't surprise me because Sun and Oracle have bodged it so bad, and because there were legitimate issues using the JVM when your project was small. I can't shake the feeling that to this day, even the coveted JetBrains products still fill like Swing. Indents are ugly, widgets are ugly, window refresh takes 3-4 refresh frames instead of 0, font rendering is just-not-quite-good-enough... and that does stick.
Also, the Java community was not necessarily receptive to progress - mostly because so much stuff depends on it (including very highly paid, senior carreers). They mostly went "The JVM is great for developing your own toy language, go have at it" but it would always be the-actual-Java interop. For example, my adventures with Clojure ended very abruptly because I simply do not know Java well enough to feel comfortable when I get a NullPointerException.
Which I obviously did get on my second line of REPL input.
sanderjd
2 days ago
Yeah I think the strongest argument is definitely "to each their own"! I was more exploring my own personal thoughts about the readability thing. I think I don't care enough or see a big enough win for ruby for me personally. But I think it's very reasonable for other people to feel the opposite, for sure.
On the jvm for performance thing... My big frustration with rails was always more about memory usage than compute performance (web app backends don't tend to do much compute!), and at least back when I was looking into it (a long time ago now!), the jvm implementations didn't help or actually actively hindered the effort to rein in memory usage. Also, and I think somewhat related (it takes time to write all that memory), I felt like long startup times made it so that we had to over-provision servers instead of being able to spin things up more on demand. This also isn't fixed by the jvm.
In general, rust and go feel like a breath of fresh air to me, operationally, because of much tighter memory overhead and fast startup. Maybe I could use the amazing ai tools we have now to solve those problems in ruby (or more likely for me personally at this point, python), but it feels like a very tall order when we already have languages that have taken this side of the various tradeoffs, from the start.
But again, I do recognize that this is totally my own personal analysis and others can very reasonably differ!
hollerith
18 hours ago
Rust (like C) gives the programmer more control over computer cycles and memory than Ruby, Python and JVM languages do, which some might be describing as a "performance advantage".
chao-
2 days ago
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).
sanderjd
2 days ago
Yes I think your conclusion is good. I find myself being a lot less interested in the implementation details than previously, and more interested in the types and structure and especially in the static and dynamic analysis that demonstrates that the implementation does what it is supposed to do.