6 ms·

genuinely curious what your take is here, I have been in security engineering for 5-6 years, then most recently a startup that's using rails. It honestly does n

genuinely curious what your take is here, I have been in security engineering for 5-6 years, then most recently a startup that's using rails. It honestly does not seem that bad even though we're using an ember frontend. What is your thought process here? Is it the notion that you can ship as fast as possible, and that creates a shitty environment given that you're a hamster on a wheel getting measured by output since "you should be able to ship fast?"

throwanem 1y ago
If you mean about Rails specifically, it's that the total lack of discipline in both language and framework makes it impossible to build a product maintainable by more than one person, so every "successful" project has one or a few covert empire builders running it, usually with more political than technical success. That's not a kind of project that pays enough to be worth the trouble, even before we talk about opportunity cost, and the framework itself is a dead end that peaked in 2011 and has had about as many "renaissances" since then as there've been years of the Linux desktop. If I want to go live under that kind of rock, I'll do it with Salesforce, where the pay is better and no one thinks they're cool for poking at a keyboard all day.
- gleenn 1y ago
  Strongly disagree. I've seen bad code or maintenance in all the languages. Sure, some ecosystems seem to attract worse practices, but the absolute best software engineering principles I ever learned in my multi-decade career were at a Rails shop. Everything was extremely well maintained, tested, CI/CD were great even before that was a thing. Not to start flame wars about refactoring or what it means to maintain code more, but that place was absolutely full of people who cared and kept those projects at the highest of caliber grade. You can find good, bad, and ugly in every ecosystem but I personally don't think Rails was ever even remotely bad. You can have an amazingly well-maintained setup and still be super productive. It's really about the people and the company spending the time, money, and energy to care. (Edit: typo)
  - throwanem 1y ago
    Which shop? When? Who with? It matters, far more in this ecosystem than others. If today there seems to be a history of pervasive testing culture in the Rails ecosystem, I can only assume there must exist some quiet mutual agreement to keep some history swept under what must be quite a large rug. Oh, I remember the same enormous amount of lip service about testing that you do! And I also remember what it was like to try to integrate a dependency into a Rails project in 2012, because that was a fair bit of what swore me off the platform. Rails was famously the home of dogshit engineering practice in its day, every bit as much as PHP, excepting only among the coterie of too-good-for-finance Boston hipsters who invented the thing, and benefited from all the same traditional software engineering training and practice they built a culture (and, coincidentally, a reputedly quite lucrative consulting practice) around decrying. Just saying "I saw good Rails back in the day" thus really isn't dispositive. They were young, so was I, we all make some bad decisions at that age, it's fine, I don't care. But none of us is young any more, and as an aging hipster once said, there's nothing more contemptible than an aging hipster.
- MrDarcy 1y ago
  First, props for your candor. It’s refreshing. I do wonder if Rails is so bad compared to other frameworks that it deserves such a distinct treatment. Over the decades I’ve worked with at least half a dozen popular frameworks that fit this description, is the same for you or is Rails truly unique in this regard?
  - throwanem 1y ago
    Rails is uniquely compromised by its history and by its language of implementation. Ruby is good for many things. Writing maintainable software in the absence of conventions enforced by shotgun is none of them. And Ruby's American fanbase gets off way too much on holding the shotgun.
    - BobbyTables2 1y ago
      Worse than Python (without Typing)?
      - brian-armstrong 1y ago
        100% yes. Python mostly encourages simple, stupid code. Code that you can still read while 2 beers in. Rails, on the other hand, encourages being as clever as possible at all times. Forget about local side effects when any part of the codebase can just reach in and patch another part of the codebase.
        throwanem 1y ago
        Exactly so. I'm not actually averse to a programming environment where the only ground truth is the running image. I love that kind of environment! In my editor, where worst case I dump some state when I restart, and I can just not play such dangerous games when on call or there otherwise exists a risk of winning such stupid prizes. Production has rules. Or it had better. That said, if you want me to go back to dynamic typing, there's a fee. The grass really is a lot greener over here.
        whstl 1y ago
- randmeerkat 1y ago
  This must be a god level troll post.
  - throwanem 1y ago
    I was asked for an opinion and I gave one. Don't make too much of it. Rails devotees can't stand hearing a bad word about their baby, they always make a fuss.
    - lelandbatey 1y ago
      I've seen poorly-built code on rails circa 2014, and I've seen Rails done pretty well circa-2025. I'd say rails is pretty neutral. Saying it's PHP bad seems a bit much, but hey. The worst code I've ever seen by a country mile though was a huge Python 2 code base written on an old version of Tornado circa 2012, a library that basically hacked the Python language to get code to run asynchronously, but you had to contort yourself into knots to get it. You couldn't just call other async functions/methods, you had to `yield func()` when calling them. To return from a function, you couldn't use `return` you had to throw an exception of type Tornado.Return. Absolutely insane way to write code. Then all the business logic written on top of this bizarre framework was terrible. Half of the code broke the rules I just mentioned but still half-worked sometimes, but would perform terribly or have mysterious problems. One of my greatest accomplishments was getting it all to Python3 then onto more sane async-style code.
      - throwanem 1y ago
        I didn't say Rails was PHP bad, but if you'd asked I would say it is worse. Both have awful ergonomics that make mistakes easy, but at least with PHP it's hard to be foolish in a way that's very clever. Ruby meanwhile will happily hand you more than enough rope to David Carradine yourself before you really even notice, and the DHH/Katz crowd took full advantage.
        randmeerkat 1y ago
        And yet he double downs on the troll… Style points for the David Carradine reference though.
- pianoben 1y ago
  One of the largest codebases I've ever worked on, generating billions in revenue every year to this day, is in Rails. Over a thousand hands have touched it, and none of the original people are still around to hold an empire. I'm with you on the general lack of discipline enforced by Rails; this codebase isn't fun to maintain, precisely for that reason. All the same, I don't think your critique is fair or even that accurate. But that's from my POV working at bigger companies. Maybe it looks different as a freelancer for smaller shops.
  - throwanem 1y ago
    By the sound of it, your POV working at one big company. The codebases I've worked on that did similar ARR numbers with similar depths of commit history were in Javascript and TypeScript, so "your argument is invalid," right? Why not? It's just what you said and my credentials are better. What's the most in revenue one second of your life was ever worth? For me that's about $35k. But no, you go ahead, try to big league me with numbers some more. If you think my critique is unjust or inaccurate, then attack it, not my standing to speak on the subject. Especially not when I'm the more forthcoming of the two of us when it comes to professional history, anyway; mine is findable from my HN profile, while you prefer true pseudonymy. To argue from authority as you've tried is quite risible with none of that even in evidence, don't you think?
    - pianoben 1y ago
      I don't mean to say one of us has better bona-fides, only that there is an existence proof to the contrary of your post. You claim that rails' lack of discipline promotes unmaintainable code shepherded by empire-builders; I claim that this is not always so. I gave the numbers I did to emphasize that rails (and rails shops) can succeed even at that scale. Not sure what I said that came off as an attack on you or your standing. Not my intent.
      - throwanem 1y ago
        You should work on that. Technical discussion would I think better resume from https://news.ycombinator.com/item?id=44254539 https://news.ycombinator.com/item?id=44254539 But I haven't said no Rails project ever meets its definition of success. I assumed the scare quotes in my earlier comment would suffice to indicate my argument intended to contradict that definition.
- bigtunacan 1y ago
  Hard disagree. I work on one of the largest Rails codebases out there. Millions of lines of code running in a monolith. I have learned more in this shop about scaling, observability, mature system designs, zero downtime upgrades, deploys, etc… I been in this field for almost 30 years and have worked with whatever tech the job required. Still I learned more at a Rails shop with more than 200 engineers all working in the same monolith shipping to production multiple times every day.
  - throwanem 1y ago
    I'm well aware there is a large Rails shop with famously strong engineering practices, which I believe deserve much credit that accrues for some reason instead to the framework.
    - bigtunacan 1y ago
      Yes, yes, yes, everyone knows about Shopify and no that’s not the multi billion dollar monolith shop I’m referring to, but we definitely have taken some inspiration from their excellent practices. We also brought in a lot of best in breed from Microsoft and Amazon. Bottom line is it’s about the talent and the discipline. At the end of the day it’s not bad languages that are the problem it’s bad engineers.
      - deleted 1y ago
        [deleted]
      - deleted 1y ago
        [deleted]
      - throwanem 1y ago
        Well, good enough engineers can get the most out of even the worst tools, that's true. I'm glad not to be among the ones you describe.
- jfinnery 1y ago
  Can confirm, I'd charge a laaaarge premium to ever work on an existing Rails codebase again. Did it several times over a period of 15 years and they were always a wreck and unreasonably painful to work with. Every single time. I'd start a green field one, no problem, provided I get veto on gem choices ("Let's use some twee fucking template language that's a ton worse-performing than the default and doesn't let you programmatically control nesting levels / end tags because it's terribly designed" yeah how about we don't do that because it's going to make my life a living hell) without charging a premium. But no more onboarding to rails codebases without enough money to make it worth my hating every second of work for the (assuredly short) duration. ... and I like Ruby!
__s 1y ago
I've worked with Ruby. It was a delight. But it has to be maintained, dynamic typing loses upfront safety & allows for a mess where you have to analyse the whole program to have any idea what some function is expected to take in & put out I'm glad static typing came back
- throwanem 1y ago
  Ruby is a fine toy and an awful tool, the other Perl that Python killed. Rails should have incurred some kind of criminal indictment. I wish I hadn't mentioned either, because now no one will talk about anything else.
- sidewndr46 1y ago
  Analyze the whole program? I steadfastly refused to ever attempt do that. "method(:foo).source_location" from the Rails console and I've got the only answer that matters. Most functions were monkey patched at least once anyways, so you'd never know by searching for the implementation where it was.
  - zbentley 1y ago
    But like…this is very telling, no? If major conventions in a language involve runtime debugging/printing actions to just find out where a method is defined (and your approach here is the norm in every Ruby codebase I’ve worked on; this isn’t an attack on you in the slightest) that doesn’t say anything good about the Ruby ecosystem. Hell, just finding out what methods can be called from a given code location is something that most Rubyists I’ve met answer either with a runtime debugger or hard-fought and non-transferable memory about a particular piece of code. Like, I don’t need perfectly accurate programmatically-available answers to those questions in my IDE (though that would be nice). I’m fine reading code and working it out if things are added via reflection/metaprogramming. But if the domain of code to read to determine those things is “who knows/could be anything in the codebase or dependencies”, this is a poor quality tool and/or community. If you read that and think I’m complaining about one specific instance, codebase, or Ruby community habit, I promise I’m not. It’s not about the 2014 obsession with “DSL”s (that aren’t really DSLs); it’s not about method_missing, open classes, pervasive monkey patching, and so on. It’s about all those things, and more, and the overwhelming enthusiasm (with no small side of smugness) with which the Ruby ecosystem doubles down on them constantly. Is it the language itself? The community? I don’t know, but I know there are plenty of equivalently capable alternatives to both, and that’s enough for me to avoid the hell out of Ruby and Rubyists for a long time to come. Is Ruby the worst? No, that honor goes to a multimillion line Perl monolith worked on by far too many not-as-clever-as-they-thought-they-were people over far too long. But all the Ruby I’ve worked on is close enough to that experience to make me question the choice of tool.
glenngillen 1y ago
As evidenced by the other replies by OP, it’s a hyperbolic and bad take. There’s plenty of companies doing just fine with Rails codebases. Many of which are a decade or more old now and have done just fine with the inter generational transfer that happens due to natural employee attrition and haven’t been held hostage by one or two all-knowing engineers.
- throwanem 1y ago
  I said "empire builders," not "engineers." Nor did I say "held hostage." My perspective on this is that of a working engineer who made a deliberate choice, now nearly 15 years ago, to avoid ending up stuck in the same decreasing-radius career spiral I saw Rails leading me toward - so I went and did some other things, then spent a decade building modern TypeScript instead, mostly on Kubernetes, without losing the ability to knock out a quick one-off script or architect a system top to bottom as I need. It's worked out splendidly for me! I suppose I might have done as well if I decided differently, but I admit I don't see how.
alexjplant 1y ago
Ruby is only just now getting static typing and Rails has a lot of "magic" as part of its value prop. If you're trying to launch something of low to medium complexity quickly and stay on the happy path of the tools in the ecosystem then it works great. The lack of rigor from dynamic typing and latitude afforded by Ruby's expressive syntax can quickly become a footgun though. My pet theory is that LLM coding is going to give the upper hand to more verbose languages like Golang or Typescript because more of the execution flow will end up explicitly in the LLM's context. Convention over configuration-type frameworks ruled when one-person code bulldozers shipped MVPs but Continue is upending this paradigm.
- throwanem 1y ago
  I wouldn't really call it a pet theory at this point; HN's front page daily further shows that LLMs suck at magic and excel at boring code, seeming quite immune to boredom. But I would argue what makes the difference for LLMs is not verbosity but locality, whether syntactic or analytical ie whether the type is just written here or you have an LSP server to query for it, the distinction is, being able to point to an arbitrary symbol and get lots of rich context about it. It's a game changer for human devs also, and not really one I would expect a serious Rails habitué to necessarily evaluate in a way that's reliable. What did someone call that once, the "Blub Paradox?" Silly name, but that's this industry for you.

throwanem 1y ago

If you mean about Rails specifically, it's that the total lack of discipline in both language and framework makes it impossible to build a product maintainable by more than one person, so every "successful" project has one or a few covert empire builders running it, usually with more political than technical success. That's not a kind of project that pays enough to be worth the trouble, even before we talk about opportunity cost, and the framework itself is a dead end that peaked in 2011 and has had about as many "renaissances" since then as there've been years of the Linux desktop. If I want to go live under that kind of rock, I'll do it with Salesforce, where the pay is better and no one thinks they're cool for poking at a keyboard all day.

gleenn 1y ago
Strongly disagree. I've seen bad code or maintenance in all the languages. Sure, some ecosystems seem to attract worse practices, but the absolute best software engineering principles I ever learned in my multi-decade career were at a Rails shop. Everything was extremely well maintained, tested, CI/CD were great even before that was a thing. Not to start flame wars about refactoring or what it means to maintain code more, but that place was absolutely full of people who cared and kept those projects at the highest of caliber grade. You can find good, bad, and ugly in every ecosystem but I personally don't think Rails was ever even remotely bad. You can have an amazingly well-maintained setup and still be super productive. It's really about the people and the company spending the time, money, and energy to care. (Edit: typo)
- throwanem 1y ago
  Which shop? When? Who with? It matters, far more in this ecosystem than others. If today there seems to be a history of pervasive testing culture in the Rails ecosystem, I can only assume there must exist some quiet mutual agreement to keep some history swept under what must be quite a large rug. Oh, I remember the same enormous amount of lip service about testing that you do! And I also remember what it was like to try to integrate a dependency into a Rails project in 2012, because that was a fair bit of what swore me off the platform. Rails was famously the home of dogshit engineering practice in its day, every bit as much as PHP, excepting only among the coterie of too-good-for-finance Boston hipsters who invented the thing, and benefited from all the same traditional software engineering training and practice they built a culture (and, coincidentally, a reputedly quite lucrative consulting practice) around decrying. Just saying "I saw good Rails back in the day" thus really isn't dispositive. They were young, so was I, we all make some bad decisions at that age, it's fine, I don't care. But none of us is young any more, and as an aging hipster once said, there's nothing more contemptible than an aging hipster.
MrDarcy 1y ago
First, props for your candor. It’s refreshing. I do wonder if Rails is so bad compared to other frameworks that it deserves such a distinct treatment. Over the decades I’ve worked with at least half a dozen popular frameworks that fit this description, is the same for you or is Rails truly unique in this regard?
- throwanem 1y ago
  Rails is uniquely compromised by its history and by its language of implementation. Ruby is good for many things. Writing maintainable software in the absence of conventions enforced by shotgun is none of them. And Ruby's American fanbase gets off way too much on holding the shotgun.
  - BobbyTables2 1y ago
    Worse than Python (without Typing)?
    - brian-armstrong 1y ago
      100% yes. Python mostly encourages simple, stupid code. Code that you can still read while 2 beers in. Rails, on the other hand, encourages being as clever as possible at all times. Forget about local side effects when any part of the codebase can just reach in and patch another part of the codebase.
      - throwanem 1y ago
        Exactly so. I'm not actually averse to a programming environment where the only ground truth is the running image. I love that kind of environment! In my editor, where worst case I dump some state when I restart, and I can just not play such dangerous games when on call or there otherwise exists a risk of winning such stupid prizes. Production has rules. Or it had better. That said, if you want me to go back to dynamic typing, there's a fee. The grass really is a lot greener over here.
      - whstl 1y ago
randmeerkat 1y ago
This must be a god level troll post.
- throwanem 1y ago
  I was asked for an opinion and I gave one. Don't make too much of it. Rails devotees can't stand hearing a bad word about their baby, they always make a fuss.
  - lelandbatey 1y ago
    I've seen poorly-built code on rails circa 2014, and I've seen Rails done pretty well circa-2025. I'd say rails is pretty neutral. Saying it's PHP bad seems a bit much, but hey. The worst code I've ever seen by a country mile though was a huge Python 2 code base written on an old version of Tornado circa 2012, a library that basically hacked the Python language to get code to run asynchronously, but you had to contort yourself into knots to get it. You couldn't just call other async functions/methods, you had to `yield func()` when calling them. To return from a function, you couldn't use `return` you had to throw an exception of type Tornado.Return. Absolutely insane way to write code. Then all the business logic written on top of this bizarre framework was terrible. Half of the code broke the rules I just mentioned but still half-worked sometimes, but would perform terribly or have mysterious problems. One of my greatest accomplishments was getting it all to Python3 then onto more sane async-style code.
    - throwanem 1y ago
      I didn't say Rails was PHP bad, but if you'd asked I would say it is worse. Both have awful ergonomics that make mistakes easy, but at least with PHP it's hard to be foolish in a way that's very clever. Ruby meanwhile will happily hand you more than enough rope to David Carradine yourself before you really even notice, and the DHH/Katz crowd took full advantage.
      - randmeerkat 1y ago
        And yet he double downs on the troll… Style points for the David Carradine reference though.
pianoben 1y ago
One of the largest codebases I've ever worked on, generating billions in revenue every year to this day, is in Rails. Over a thousand hands have touched it, and none of the original people are still around to hold an empire. I'm with you on the general lack of discipline enforced by Rails; this codebase isn't fun to maintain, precisely for that reason. All the same, I don't think your critique is fair or even that accurate. But that's from my POV working at bigger companies. Maybe it looks different as a freelancer for smaller shops.
- throwanem 1y ago
  By the sound of it, your POV working at one big company. The codebases I've worked on that did similar ARR numbers with similar depths of commit history were in Javascript and TypeScript, so "your argument is invalid," right? Why not? It's just what you said and my credentials are better. What's the most in revenue one second of your life was ever worth? For me that's about $35k. But no, you go ahead, try to big league me with numbers some more. If you think my critique is unjust or inaccurate, then attack it, not my standing to speak on the subject. Especially not when I'm the more forthcoming of the two of us when it comes to professional history, anyway; mine is findable from my HN profile, while you prefer true pseudonymy. To argue from authority as you've tried is quite risible with none of that even in evidence, don't you think?
  - pianoben 1y ago
    I don't mean to say one of us has better bona-fides, only that there is an existence proof to the contrary of your post. You claim that rails' lack of discipline promotes unmaintainable code shepherded by empire-builders; I claim that this is not always so. I gave the numbers I did to emphasize that rails (and rails shops) can succeed even at that scale. Not sure what I said that came off as an attack on you or your standing. Not my intent.
    - throwanem 1y ago
      You should work on that. Technical discussion would I think better resume from https://news.ycombinator.com/item?id=44254539 https://news.ycombinator.com/item?id=44254539 But I haven't said no Rails project ever meets its definition of success. I assumed the scare quotes in my earlier comment would suffice to indicate my argument intended to contradict that definition.
bigtunacan 1y ago
Hard disagree. I work on one of the largest Rails codebases out there. Millions of lines of code running in a monolith. I have learned more in this shop about scaling, observability, mature system designs, zero downtime upgrades, deploys, etc… I been in this field for almost 30 years and have worked with whatever tech the job required. Still I learned more at a Rails shop with more than 200 engineers all working in the same monolith shipping to production multiple times every day.
- throwanem 1y ago
  I'm well aware there is a large Rails shop with famously strong engineering practices, which I believe deserve much credit that accrues for some reason instead to the framework.
  - bigtunacan 1y ago
    Yes, yes, yes, everyone knows about Shopify and no that’s not the multi billion dollar monolith shop I’m referring to, but we definitely have taken some inspiration from their excellent practices. We also brought in a lot of best in breed from Microsoft and Amazon. Bottom line is it’s about the talent and the discipline. At the end of the day it’s not bad languages that are the problem it’s bad engineers.
    - deleted 1y ago
      [deleted]
    - deleted 1y ago
      [deleted]
    - throwanem 1y ago
      Well, good enough engineers can get the most out of even the worst tools, that's true. I'm glad not to be among the ones you describe.
jfinnery 1y ago
Can confirm, I'd charge a laaaarge premium to ever work on an existing Rails codebase again. Did it several times over a period of 15 years and they were always a wreck and unreasonably painful to work with. Every single time. I'd start a green field one, no problem, provided I get veto on gem choices ("Let's use some twee fucking template language that's a ton worse-performing than the default and doesn't let you programmatically control nesting levels / end tags because it's terribly designed" yeah how about we don't do that because it's going to make my life a living hell) without charging a premium. But no more onboarding to rails codebases without enough money to make it worth my hating every second of work for the (assuredly short) duration. ... and I like Ruby!

__s 1y ago

I've worked with Ruby. It was a delight. But it has to be maintained, dynamic typing loses upfront safety & allows for a mess where you have to analyse the whole program to have any idea what some function is expected to take in & put out I'm glad static typing came back

throwanem 1y ago
Ruby is a fine toy and an awful tool, the other Perl that Python killed. Rails should have incurred some kind of criminal indictment. I wish I hadn't mentioned either, because now no one will talk about anything else.
sidewndr46 1y ago
Analyze the whole program? I steadfastly refused to ever attempt do that. "method(:foo).source_location" from the Rails console and I've got the only answer that matters. Most functions were monkey patched at least once anyways, so you'd never know by searching for the implementation where it was.
- zbentley 1y ago
  But like…this is very telling, no? If major conventions in a language involve runtime debugging/printing actions to just find out where a method is defined (and your approach here is the norm in every Ruby codebase I’ve worked on; this isn’t an attack on you in the slightest) that doesn’t say anything good about the Ruby ecosystem. Hell, just finding out what methods can be called from a given code location is something that most Rubyists I’ve met answer either with a runtime debugger or hard-fought and non-transferable memory about a particular piece of code. Like, I don’t need perfectly accurate programmatically-available answers to those questions in my IDE (though that would be nice). I’m fine reading code and working it out if things are added via reflection/metaprogramming. But if the domain of code to read to determine those things is “who knows/could be anything in the codebase or dependencies”, this is a poor quality tool and/or community. If you read that and think I’m complaining about one specific instance, codebase, or Ruby community habit, I promise I’m not. It’s not about the 2014 obsession with “DSL”s (that aren’t really DSLs); it’s not about method_missing, open classes, pervasive monkey patching, and so on. It’s about all those things, and more, and the overwhelming enthusiasm (with no small side of smugness) with which the Ruby ecosystem doubles down on them constantly. Is it the language itself? The community? I don’t know, but I know there are plenty of equivalently capable alternatives to both, and that’s enough for me to avoid the hell out of Ruby and Rubyists for a long time to come. Is Ruby the worst? No, that honor goes to a multimillion line Perl monolith worked on by far too many not-as-clever-as-they-thought-they-were people over far too long. But all the Ruby I’ve worked on is close enough to that experience to make me question the choice of tool.

glenngillen 1y ago

As evidenced by the other replies by OP, it’s a hyperbolic and bad take. There’s plenty of companies doing just fine with Rails codebases. Many of which are a decade or more old now and have done just fine with the inter generational transfer that happens due to natural employee attrition and haven’t been held hostage by one or two all-knowing engineers.

throwanem 1y ago
I said "empire builders," not "engineers." Nor did I say "held hostage." My perspective on this is that of a working engineer who made a deliberate choice, now nearly 15 years ago, to avoid ending up stuck in the same decreasing-radius career spiral I saw Rails leading me toward - so I went and did some other things, then spent a decade building modern TypeScript instead, mostly on Kubernetes, without losing the ability to knock out a quick one-off script or architect a system top to bottom as I need. It's worked out splendidly for me! I suppose I might have done as well if I decided differently, but I admit I don't see how.

alexjplant 1y ago

Ruby is only just now getting static typing and Rails has a lot of "magic" as part of its value prop. If you're trying to launch something of low to medium complexity quickly and stay on the happy path of the tools in the ecosystem then it works great. The lack of rigor from dynamic typing and latitude afforded by Ruby's expressive syntax can quickly become a footgun though. My pet theory is that LLM coding is going to give the upper hand to more verbose languages like Golang or Typescript because more of the execution flow will end up explicitly in the LLM's context. Convention over configuration-type frameworks ruled when one-person code bulldozers shipped MVPs but Continue is upending this paradigm.

throwanem 1y ago
I wouldn't really call it a pet theory at this point; HN's front page daily further shows that LLMs suck at magic and excel at boring code, seeming quite immune to boredom. But I would argue what makes the difference for LLMs is not verbosity but locality, whether syntactic or analytical ie whether the type is just written here or you have an LSP server to query for it, the distinction is, being able to point to an arbitrary symbol and get lots of rich context about it. It's a game changer for human devs also, and not really one I would expect a serious Rails habitué to necessarily evaluate in a way that's reliable. What did someone call that once, the "Blub Paradox?" Silly name, but that's this industry for you.