> I must admit that for a few days I felt very depressed about it all. Not about “AIs writing all the code” - that much is clear to me, and I do not lament the changing landscape of the craft
If you're not under pressure to vibe code for work, and you still like writing the code, I don't understand this sentiment. People coding on their own time won't be left behind. It's your own time to use as you like. And if you want to take a longer time to hand craft a library or your pet project, more power to you.
Sure, if you need help from the AI for something too difficult, time consuming or tedious, that makes sense. But the idea that everyone needs give up hand coding is absurd. This also isn't true for all paid programming work and will continue not to be, despite the marketing hype.
> But the idea that everyone needs give up hand coding is absurd.
Unfortunately (?) this seems to be the ground truth for the majority of people I speak to. What's not clear to me yet, is whether we'll stop reading code. I suspect that reading is going away as well. There's a push at $WORK to expedite 50-files/20,000 line PRs via agentic reviews..
If this continues, then language readability and "pleasure" of hand coding will likely diminish. I'm still not clear where we're going to land with libraries and re-use. Non-technical pressures are forcing functionality to be re-vibe coded instead.
I've always loved Rails for its pragmatic approach; I've delivered many projects with it. I'll be sad when it disappears but it seems inevitable.
I've been thinking about this too, since my livelihood depends heavily on this answer.
As far as I can tell, agentic software development (aka vibe coding) simply doesn't scale for lay people. At $WORK, I'm seeing the 5th version of the same small project being rewritten by execs. The 5th version is marginally better than the previous 4, but it still has major problems. 5th version has no CI and accesses 6 databases directly. These VPs are slowly becoming software engineers. It's hilarious to watch, but seems rather inefficient.
I've been asked this question by non-software people and the best answer I've come up so far is this. You can go to the hardware store and purchase a chainsaw. You can now prune small trees. This does not make you an arborist though. For reference check out YouTube: https://www.youtube.com/results?search_query=arborist+fails+...
> These VPs are slowly becoming software engineers. It's hilarious to watch, but seems rather inefficient.
Tell me you weren't around for the dot com bubble without telling me.
At that point in time if you told any one you could build on the web they spent an hour pitching you their bad idea and then wanted you to build it for nothing. They thought the value was in the idea, not the implementation.
Now, if you have an idea, then go use AI to prototype, to validate, to iterate.
IF that results in a viable product then you need an engineer to go in and do the needed work to operationalize it. To attach testing, monitoring, deployment and more over cost metrics (something we have not really done in the last 30 years) - because a good idea that costs more to run than it makes is not a good idea.
The nuance is here - the "tweak this and we can save $0.50 a user a month" is how you move the needle at scale.
Programing is dead, Software development has a narrow place - engineering for sustainability, reliability and cost are what the field is going to become. Someone has to be responsible, or be on the hook for the 3am on a holiday weekend phone call.
> Now, if you have an idea, then go use AI to prototype, to validate, to iterate.
That's another huge gap. Folks without software background cannot seem to grasp incremental improvement. This is why we're on v5. The solution to product's shortcomings is to start a brand new project.
I'm waiting to see if people start dropping massive trees on their houses, or if we're all arborists now.
When I was becoming a self-taught software engineer it also was hilarious, no doubt about it - and very inefficient. I did enjoy it and did build some stuff, and not all of it was bad.
So, if anything, if the intent is "I can do it all myself and I will fire you now" - I love to see them stumble, if the intent is "I want to get my hands dirty and let's work together" - I will be happy to assist. It's not a pipe dream: it does happen.
Does the journey have value? When you started learning to code to become a software engineer, you probably reasoned that the journey was important.
If you are an exec building an app then the journey is likely to be uninteresting and an impediment to getting to a product. I don't think we'll uncover anything new here that we couldn't reason about before. When execs, or other non-programmers, do get decide to get involved, there is a probability that they will learn something more about software engineering inside their organization. That is the thing that software engineers need to be concerned about because depending on the circumstances, the execs will uncover things which shorten the tenure of SWEs or their management.
The journey always has value, in retrospect (if you manage to get through in one piece). But - to be honest - if I could have prompted my way to the software I built back then instead of grinding through the bits and bobs - I would have done it.
I can appreciate the internal beauty but getting "a thing that does thing and does it well", and seeing others enjoy using it has way more value for me than "what type system could work more elegantly here".
So your company is taking many 10s of code generated by proprietary software whose own creators tell us cannot be fully trusted, and putting it straight into production?
I'm very much against this. I love agentic coding, because I get where I'm going much faster, but I retain at least a high level understanding of architecture and trade offs that have been made. But that's in my personal projects. For work, there's a huge push to deliver much faster. The quality is an afterthought.
> Sure, if you need help from the AI for something too difficult, time consuming or tedious, that makes sense
First, I offloaded the tedious. There was no real joy there. Then I offloaded the merely time consuming - after all I could have more fun on interesting problems.
But suddenly everything is too difficult, and I am not going to get any better at those pieces by glancing over ai prs. Still, this is what I do
I didn't say LLMs couldn't code, I said they don't replace all professional coding, since the software field is large and encompasses many domains, not just the heavily vibe coded ones. There are many HN posts attesting to this. The hype is that nobody needs hand code anymore, which isn't true. Some don't, others do, just depending on the job or task.
> If you're not under pressure to vibe code for work, and you still like writing the code, I don't understand this sentiment.
We don't necessarily like writing the code by hand, but those of us in this situation don't really have a choice and it pays the bills (handsomely, I might add; not complaining at all).
Every line of code has the entire organization behind it due to requirements that cannot budge an inch. There's also lots of rigorous manual testing beyond what is already automated. The automation efforts for this kind of software, sometimes going on decades, has left no stone unturned yet lots of human work (and payroll cost) remains.
This is what a real business looks like once it's settled into its competitive niche, and I'm routinely surprised how many devs on HN are not in this kind of role. Those people who are forced to lean hard on AI are at the highest risk of unemployment, and I have to assume they're either junior or made a lot of questionable career choices.
OP here - no, I am not under pressure to do vibe code for work, I do it willingly (but - IMO - responsibly). And I do not think hand-coding will be sustainable for most tasks simply because it will be very hard to justify in most situations where you work with other people - be it on community basis or commercially. It's hard to say "I have to spend a week doing this by hand" when the next person is expecting you to do this in an afternoon (and rightly so).
I think we should write code by hand from time to time to not lose currency - but it's not the primary nor the default anymore.
Maybe I'm a bad person for this, but I both love coding and designing abstractions, and I enjoy LLM use. It's like having my old college friends to argue with about whenever I want.
Look how I don’t care anymore, and you should not care either
What DHH actually said:
I have AI delirium. AI euphoria. Because this is simply the most exciting thing we have made computers do in the time I have worked with them, played with them, interacted with them. But I think actually to wrestle with the fact that on the one hand, this is tremendously exciting, it is also a little unnerving.
and
There's only one play here, and it's total Fucking optimism. Lean in to the max possible. Because the utopia is almost here.
If people want to have the OG transcript - they can always find it. I was translating the message he (willingly or not) has sent out to that particular audience, in that particular context.
You received a highly distorted negative version of what he was saying. Another example is the claim 37 Signals "banned" hand coding. What he said is they went AI first, and that hand writing was exceptional.
We are going, and have gone, pencils down on the idea that we were gonna write code by hand as a normal course of business creating things. Writing code by hand at 37signals is now an exceptional state.
I think I have received more of what was _not_ said than of what was said. I did watch the entire thing a couple of times just to make sure I haven't missed something. I think this article explains it better https://jardo.dev/what-about-rails
DHH is like a script that runs permanently in a loop, promoting AI now.
Before that it was rails, though the old rails promo made a lot more sense
than the AI promo. But as long as you feed these people money, they do whatever
you want them to say. An even more hilarious example is Sebastian Kurz - dude
got insta-rich after politics. Like +100 million euros in a year. Tell me this
is not corruption to the max ...
The AI companies and security companies buy legislation. Everywhere. And their
financial kickbacks are AMAZING - otherwise you could not so easily change a few
top-influencers into tools to influence other people.
We might be a bit suspicious of the sincerity of a man who spent 20 years evangelizing the beauty and expressiveness of code, and who felt he was a pioneer in that field, to suddenly find himself completely obsolete.
Which stage of grief is "delirium"? After we accept the death of our child, are we euphoric?
I mean, he is kind of spelling it out for you there: "there's only one play here".
The nuance is of course that dhh is both correct and not exactly right at the same time, and doesn't really have any affect on you. Rails is still great for solo/small teams moving fast technically and product wise. He's also right that rust is good for established services (with possibly larger teams) that prioritize performance. Just as it always was, but now the transition from rails -> rust/others is much quicker with ai
That said: I am not obligated to quote a speech that is freely available for everyone to listen to or to read. I don't know which "comments" exactly I have "distorted", but - on the other hand - this is an opinion piece, not a Reuters ticker report.
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, 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.
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!
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.
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.
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!
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".
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).
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.
> Much has been said about the DHH keynote that he gave at RailsWorld.
First, it has to be said that Ruby on Rails is not Ruby, in that the
two communities at best are overlapping, but in reality, they are
separate communities. I never managed to get into rails; I bought two
books and did not complete either one. Despite all the promo, I always
found rails horribly boring. I also did not see the need for it. At that
point ruby itself already handled all my web needs (I wrote quite a lot
of stuff in PHP; my latest project called "web", originally "cyberweb"
when I was still using rubygems.org, came from the things I used and
learned back then in PHP), so I never really fully understood the hype
train. It took me a while to realise that this is how DHH operates -
he is a business man first and foremost, not a programmer. He tries to
build up hype. That's largely how rails got successful in the first place,
in 2006 or so, give or take. So when he now promotes AI and Rust, I have
a deja vu - he is on the promo tour again. (Note: I am not saying there is
zero value in rails. Evidently there is, but I am focusing here on the
promo, and DHH is a business man, not a programmer.)
> To me, it was the voice of a person in an existential crisis, but also a very jaded one.
DHH is annoying, but I don't think he is in any existential crisis. Now I think he lost the plot after his hate-entry against wolves, and casually linking shooting down animals to hunting down immigrants here:
And no, I am not interested in any right-wing nuts trying to sugar-coat this. Before I used ruby I studied countless books about strategies (strategems, in particular chinese one, from Senger in particular), many psychology books too (various influence-centric books, both with a positive connotation and a negative one, e. g. "how to win friends and influence people", as well as the six core aspects of manipulation and so forth) - so I am not interested in white-washing campaigns about DHH anymore. His dislike of wolves showed it too clearly: he switched sides and is now on the Big Tech Bros side. This was already made clear when shopify rampaged through the ruby ecosystem - see how numerous devs were expelled by the ruby core team (Hiroshi Shibata, who acted under command by someone else, we all know that; and the reason for that move, was due to financial influx into the ruby ecosystem, which brings us back to shopify and its evil influence on the ruby ecosystem. byroot will soon say "no, we need more shopify companies!!!" - and while that has some logic in it, no, we really don't need MORE financial addictions and kick backs in the ruby ecosystem. Ruby needs more independent developers, and unfortunately it is now stuck in a death spiral. I don't see how it can escape it, even though ruby, as a language is really well designed - people need to separate the criticism, including criticism of DHH. DHH is a nut; ruby as a language is well-designed)
> “Look how I don’t care anymore, and you should not care either” is not a great message when you are the headline speaker at the conference - let’s call it CareConf - that you have, yourself, lobbied for.
The thing is: DHH's promo tour is logical if you connect the fact that DHH is now an AI promo agent. That's why he has no problem promoting Rust. It just sustains the AI agenda now. DHH is like a tool for AI promo. I pity the man - he is just a shell of his former himself now. He talked about things other than rails. You know all know that rails is dead. DHH did a post-portem here on rails. It's one of the more surprising things to witness. AI is the new rage - rails is dead.
> The message from the supreme leader was clear: we vibe-rewrote HEY in a more performant way, it worked great, we neither need nor care about ...
I used to write a lot of Ruby, so I appreciate the author's enthusiasm for the language and community's future. I think it's a great language in many ways, and deserves more attention. I was never a Rails person and have long felt that the community was overly shackled to Rails, and it could be a very good thing for that to be shaken apart.
On the other hand, I find the comparison to Weimar Germany a little nuts. My association with the period is a little less Fritz Lang and a little more "paramilitaries terrorizing the Ostjuden." It feels strange to use this as the analogy for Ruby's revitalization, in no small part because of DHH's openly reactionary leanings.
(I don't think this comparison is ill-intended, I just think it doesn't produce the author's intended reaction.)
From what I've read, the antisemitism during the Weimar Republic was mostly verbal. The government tried to fight it, but it was still growing. The situation changed very quickly in 32-33 when the NSDAP won the elections, built alliances to claim the power, then ended the Weimar Republic. But its first victims were the Communists, before the Jews.
It's not really as well researched as the Nazi period, but persecution of the Ostjuden began shortly after the end of WWI. It was indeed mixed with persecution of communists (because Eastern Jews were seen as foreign, communist influences), but the Osjuden were not communists as a category and were frequently attacked and interned outside of any discernible communist context[1][2].
one thing that's really stuck out to me from this presentation is the Hey on a Raspberry Pi comment - that really strikes me as more of an indictment on how many people are actually using Hey. I know a single person who does and work for a heavy Rails shop with folks that love DHH. Pretty important to keep in mind with any of his grand proclamations around work/business/etc that 37S has maxed out at 50 or so employees IIRC, and that was pre-mass exodus.
I do hope he focuses less on Rails and lets others take it over more. It does do a lot of things really well, and it's incredibly easy to build stuff quickly on it.
49 comments
[ 13.3 ms ] story [ 139 ms ] threadIf you're not under pressure to vibe code for work, and you still like writing the code, I don't understand this sentiment. People coding on their own time won't be left behind. It's your own time to use as you like. And if you want to take a longer time to hand craft a library or your pet project, more power to you.
Sure, if you need help from the AI for something too difficult, time consuming or tedious, that makes sense. But the idea that everyone needs give up hand coding is absurd. This also isn't true for all paid programming work and will continue not to be, despite the marketing hype.
Unfortunately (?) this seems to be the ground truth for the majority of people I speak to. What's not clear to me yet, is whether we'll stop reading code. I suspect that reading is going away as well. There's a push at $WORK to expedite 50-files/20,000 line PRs via agentic reviews..
If this continues, then language readability and "pleasure" of hand coding will likely diminish. I'm still not clear where we're going to land with libraries and re-use. Non-technical pressures are forcing functionality to be re-vibe coded instead.
I've always loved Rails for its pragmatic approach; I've delivered many projects with it. I'll be sad when it disappears but it seems inevitable.
As far as I can tell, agentic software development (aka vibe coding) simply doesn't scale for lay people. At $WORK, I'm seeing the 5th version of the same small project being rewritten by execs. The 5th version is marginally better than the previous 4, but it still has major problems. 5th version has no CI and accesses 6 databases directly. These VPs are slowly becoming software engineers. It's hilarious to watch, but seems rather inefficient.
I've been asked this question by non-software people and the best answer I've come up so far is this. You can go to the hardware store and purchase a chainsaw. You can now prune small trees. This does not make you an arborist though. For reference check out YouTube: https://www.youtube.com/results?search_query=arborist+fails+...
Thoughts?
Tell me you weren't around for the dot com bubble without telling me.
At that point in time if you told any one you could build on the web they spent an hour pitching you their bad idea and then wanted you to build it for nothing. They thought the value was in the idea, not the implementation.
Now, if you have an idea, then go use AI to prototype, to validate, to iterate.
IF that results in a viable product then you need an engineer to go in and do the needed work to operationalize it. To attach testing, monitoring, deployment and more over cost metrics (something we have not really done in the last 30 years) - because a good idea that costs more to run than it makes is not a good idea.
The nuance is here - the "tweak this and we can save $0.50 a user a month" is how you move the needle at scale.
Programing is dead, Software development has a narrow place - engineering for sustainability, reliability and cost are what the field is going to become. Someone has to be responsible, or be on the hook for the 3am on a holiday weekend phone call.
Cost, latency, security, auditing, monitoring, operating.
LLMs can handle the functional requirements of “give me this output for these inputs” very well.
That's another huge gap. Folks without software background cannot seem to grasp incremental improvement. This is why we're on v5. The solution to product's shortcomings is to start a brand new project.
I'm waiting to see if people start dropping massive trees on their houses, or if we're all arborists now.
So, if anything, if the intent is "I can do it all myself and I will fire you now" - I love to see them stumble, if the intent is "I want to get my hands dirty and let's work together" - I will be happy to assist. It's not a pipe dream: it does happen.
If you are an exec building an app then the journey is likely to be uninteresting and an impediment to getting to a product. I don't think we'll uncover anything new here that we couldn't reason about before. When execs, or other non-programmers, do get decide to get involved, there is a probability that they will learn something more about software engineering inside their organization. That is the thing that software engineers need to be concerned about because depending on the circumstances, the execs will uncover things which shorten the tenure of SWEs or their management.
I can appreciate the internal beauty but getting "a thing that does thing and does it well", and seeing others enjoy using it has way more value for me than "what type system could work more elegantly here".
What could possibly go wrong?
First, I offloaded the tedious. There was no real joy there. Then I offloaded the merely time consuming - after all I could have more fun on interesting problems.
But suddenly everything is too difficult, and I am not going to get any better at those pieces by glancing over ai prs. Still, this is what I do
The strength of the Reality Distorsion Field would make the one of Steve Jobs pale in comparison.
We don't necessarily like writing the code by hand, but those of us in this situation don't really have a choice and it pays the bills (handsomely, I might add; not complaining at all).
Every line of code has the entire organization behind it due to requirements that cannot budge an inch. There's also lots of rigorous manual testing beyond what is already automated. The automation efforts for this kind of software, sometimes going on decades, has left no stone unturned yet lots of human work (and payroll cost) remains.
This is what a real business looks like once it's settled into its competitive niche, and I'm routinely surprised how many devs on HN are not in this kind of role. Those people who are forced to lean hard on AI are at the highest risk of unemployment, and I have to assume they're either junior or made a lot of questionable career choices.
I think we should write code by hand from time to time to not lose currency - but it's not the primary nor the default anymore.
That is the part DHH does not get. Nobody will protect him from the gypsies (his words) if all are unemployed.
Look how I don’t care anymore, and you should not care either
What DHH actually said:
I have AI delirium. AI euphoria. Because this is simply the most exciting thing we have made computers do in the time I have worked with them, played with them, interacted with them. But I think actually to wrestle with the fact that on the one hand, this is tremendously exciting, it is also a little unnerving.
and
There's only one play here, and it's total Fucking optimism. Lean in to the max possible. Because the utopia is almost here.
We are going, and have gone, pencils down on the idea that we were gonna write code by hand as a normal course of business creating things. Writing code by hand at 37signals is now an exceptional state.
DHH is like a script that runs permanently in a loop, promoting AI now.
Before that it was rails, though the old rails promo made a lot more sense than the AI promo. But as long as you feed these people money, they do whatever you want them to say. An even more hilarious example is Sebastian Kurz - dude got insta-rich after politics. Like +100 million euros in a year. Tell me this is not corruption to the max ...
The AI companies and security companies buy legislation. Everywhere. And their financial kickbacks are AMAZING - otherwise you could not so easily change a few top-influencers into tools to influence other people.
We might be a bit suspicious of the sincerity of a man who spent 20 years evangelizing the beauty and expressiveness of code, and who felt he was a pioneer in that field, to suddenly find himself completely obsolete.
Which stage of grief is "delirium"? After we accept the death of our child, are we euphoric?
I mean, he is kind of spelling it out for you there: "there's only one play here".
> I know how that era ended, and no - that is not the part of the analogy I am after.
to the extent where I'd almost say it's curious to draw upon this and not acknowledge the elephant in the room.
The nuance is of course that dhh is both correct and not exactly right at the same time, and doesn't really have any affect on you. Rails is still great for solo/small teams moving fast technically and product wise. He's also right that rust is good for established services (with possibly larger teams) that prioritize performance. Just as it always was, but now the transition from rails -> rust/others is much quicker with ai
That said: I am not obligated to quote a speech that is freely available for everyone to listen to or to read. I don't know which "comments" exactly I have "distorted", but - on the other hand - this is an opinion piece, not a Reuters ticker report.
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, 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.
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!
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.
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.
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!
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).
now, he is fully in musk orbit, so i expect him to be even more polarizing when speaking publicly.
and ultimately, musk gave him a couple millions to sell grok (starting with full integration into his arch install script he calls a distro).
so, if you follow the money, it is pretty clear he is "just doing his (grok salesman) job"
First, it has to be said that Ruby on Rails is not Ruby, in that the two communities at best are overlapping, but in reality, they are separate communities. I never managed to get into rails; I bought two books and did not complete either one. Despite all the promo, I always found rails horribly boring. I also did not see the need for it. At that point ruby itself already handled all my web needs (I wrote quite a lot of stuff in PHP; my latest project called "web", originally "cyberweb" when I was still using rubygems.org, came from the things I used and learned back then in PHP), so I never really fully understood the hype train. It took me a while to realise that this is how DHH operates - he is a business man first and foremost, not a programmer. He tries to build up hype. That's largely how rails got successful in the first place, in 2006 or so, give or take. So when he now promotes AI and Rust, I have a deja vu - he is on the promo tour again. (Note: I am not saying there is zero value in rails. Evidently there is, but I am focusing here on the promo, and DHH is a business man, not a programmer.)
> To me, it was the voice of a person in an existential crisis, but also a very jaded one.
DHH is annoying, but I don't think he is in any existential crisis. Now I think he lost the plot after his hate-entry against wolves, and casually linking shooting down animals to hunting down immigrants here:
https://world.hey.com/dhh/wolves-sheep-and-gypsies-ba44af6a
And no, I am not interested in any right-wing nuts trying to sugar-coat this. Before I used ruby I studied countless books about strategies (strategems, in particular chinese one, from Senger in particular), many psychology books too (various influence-centric books, both with a positive connotation and a negative one, e. g. "how to win friends and influence people", as well as the six core aspects of manipulation and so forth) - so I am not interested in white-washing campaigns about DHH anymore. His dislike of wolves showed it too clearly: he switched sides and is now on the Big Tech Bros side. This was already made clear when shopify rampaged through the ruby ecosystem - see how numerous devs were expelled by the ruby core team (Hiroshi Shibata, who acted under command by someone else, we all know that; and the reason for that move, was due to financial influx into the ruby ecosystem, which brings us back to shopify and its evil influence on the ruby ecosystem. byroot will soon say "no, we need more shopify companies!!!" - and while that has some logic in it, no, we really don't need MORE financial addictions and kick backs in the ruby ecosystem. Ruby needs more independent developers, and unfortunately it is now stuck in a death spiral. I don't see how it can escape it, even though ruby, as a language is really well designed - people need to separate the criticism, including criticism of DHH. DHH is a nut; ruby as a language is well-designed)
> “Look how I don’t care anymore, and you should not care either” is not a great message when you are the headline speaker at the conference - let’s call it CareConf - that you have, yourself, lobbied for.
The thing is: DHH's promo tour is logical if you connect the fact that DHH is now an AI promo agent. That's why he has no problem promoting Rust. It just sustains the AI agenda now. DHH is like a tool for AI promo. I pity the man - he is just a shell of his former himself now. He talked about things other than rails. You know all know that rails is dead. DHH did a post-portem here on rails. It's one of the more surprising things to witness. AI is the new rage - rails is dead.
> The message from the supreme leader was clear: we vibe-rewrote HEY in a more performant way, it worked great, we neither need nor care about ...
On the other hand, I find the comparison to Weimar Germany a little nuts. My association with the period is a little less Fritz Lang and a little more "paramilitaries terrorizing the Ostjuden." It feels strange to use this as the analogy for Ruby's revitalization, in no small part because of DHH's openly reactionary leanings.
(I don't think this comparison is ill-intended, I just think it doesn't produce the author's intended reaction.)
From what I've read, the antisemitism during the Weimar Republic was mostly verbal. The government tried to fight it, but it was still growing. The situation changed very quickly in 32-33 when the NSDAP won the elections, built alliances to claim the power, then ended the Weimar Republic. But its first victims were the Communists, before the Jews.
[1]: https://www.berlin.de/en/attractions-and-sights/3560423-3104...
[2]: https://blogs.law.ox.ac.uk/border-criminologies-blog/blog-po...
I do hope he focuses less on Rails and lets others take it over more. It does do a lot of things really well, and it's incredibly easy to build stuff quickly on it.