This defies belief. “I wanted to scratch a technical itch. My local AI completed the job in 30 minutes. I never pressed Start to see if it works, but I did write a blog post about it…”
Yup, since the rise of AI, I still didn't find any product built by it that's even remotely useful to me... People build prototypes a lot, but these are usually buggy and not worth putting money into.
At first I thought this would be an interesting article, but as soon as they mentioned using an LLM to do the conversion I lost all interest. It's like saying "I wanted this done so I got my underling to do it, here is my story...". Like why would I bother to read it then, as it was clearly not you doing the conversion or putting any thought into it.
The point isn't about writing it but seeing difference and making probably suboptimal choice.
I mentioned in other comment that I reviewed it extensively. It's not a big project so outside of a few spicy bits it's mostly a web app.
I'd say that saying "not putting thought into it" is unfair. I didn't push the button and YOLO.
I did research about the tradeoffs and consequences. Snippets of Rust code vs Rails are the real thing and testability of Rust app is something I spent 2 months on.
The biggest problem is the author didn't even bother to verify it. I've seen big multi-model ralph wiggum or whatevers do a conversion. Run for 6 hours. Upon manual inspection to understand how it handled some tricky calculations / logic I find stubs and hard coded truthy returns. So even if you ran a smoke test suite against it -- you'd think it successful...
Post ain't about project written in LLM (and Rust one have 6 months in good ol' craft code) but about contrast between two variants.
While personally I'm skeptical about LLM usage (and vibe coding in general) I'm not going to pretend it doesn't exist just on principle. I wouldn't risk rewrite 6 months worth of code to Rails but it's a perfectly good case for LLM conversion.
As long as upper management is measuring AI tools at work not much power is left.
The whole idea with UML jockeys is that we no longer need brick layers, that is the whole point of software factory concepts, and stuff like Rational Unified Process.
The only difference is using markdown this time around.
That's an assumption. How do you infer that from written text? I can not infer that.
To me it is super-strange that one uses AI to come to the conclusion that language x is better than language y. In the past people spent some time using both languages for a while, before reaching any conclusion. With AI it seems insta-gratification or insta-evaluation now. I am beginning to see why Google ruined its search engine for real humans - those who control AI rule the world now. People aren't even noticing this how dependent they are becoming on AI in general.
sorry for the bluntness, but you should have probably thought twice before hitting the send to Hacker News button, i didn't find this in any way interesting and i am definitively not a LLM hater
I love Go and Rust, they're wonderful languages with their own ups and downs. Sadly I never was able to build a SaaS app with either. Something about a square peg and a round hole... I could be very wrong, but there's a lot of gadgets that come with a SaaS tool, and I'm not inventing them.
RoR is.. "good enough". I can opt-in types whenever, I can build things quick, the tooling is alright, etc.
My first real job was PHP, and there were just too many gotchas there. Ruby seems to steer a bit more towards ecommerce, which intruiged me. And its good enough for Shopify, so...
I built a set of gems (propel_rails) that takes the already terse Ruby on Rails code to the next extreme. It generates a set of top level classes like an API controller and some concerns that then create a full restful resource (model, controller, serializer, unit and e2e tests) with 0 boilerplate code. The controller ends up being only a list of all permitted attributes the api will accept because the restful actions are automatically generated. It’s a bit hard to fully describe but the meta programming power of Ruby really does make amazing things easy.
It sets up automatic filters, sorting, multi tenancy, authorization, and uses “accepts nested attributes for” to make it more graphic like that simply crud
I don't think I've ever been unhappier than working on a Rails project. See a bug on the site - something is rendering incorrectly. grep to find the view. Great, there's a method that is being called to render the buggy section. Grep for the method name - 0 hits. Amazing, it's something that is synthesized somewhere and I have no idea where. Guess I'll stop what I'm doing and read docs for an hour. If you do nothing but use Rails all day, sure, but the whole convention over configuration thing is such a huge anti pattern to me.
I won't be as harsh because I have years of experience in Rails and didn't develop harsh feelings against it but moving from Rust/Go/Zig/TypeScript (which I used lately) to Ruby ain't smooth ride.
Discoverability is much worse, LSPs aren't super helpful. Using Dash (documentation app) helps a ton. Still some names are confusing after switch (took a minute to recall that 'filter' is actually 'select' in Ruby).
I won't say that dev experience is bad but it's definitely different.
The fact that you have to read a book and break out a debugger to do the equivalent of "find all" in any other languages should tell you something right?
My experience is exactly the same as Milch's. I've tried to fix stuff in Gitlab but given up when I couldn't even find where it things are defined.
That can happen in other languages, e.g. Rust or C where macros are used. But it's pretty much the exception there whereas in Rails it seems to be done by default.
I’ve had similar experiences with Spring Boot Java applications. Methods in stack traces that don’t exist in source code but are magicked into existence by annotations.
It’s short term happiness at best, and at the expense of every other possible architectural characteristic (maintainability, performance, reliability, scalability, you name it).
Updating Rails is one of the most painful processes ever. There is no real way to be sure it works. You just have to have 50,000 unit tests, cypress tests, and then hope and pray.
On any sufficiently large and old app, something will always break in a way that isn't caught by your tests or manual testing, and only shows up after it goes out live.
I have taken applications from 2-to-3, 3-to-4, and so on, through 8.X.
If anything it has gotten better/easier over time. The most challenging upgrades were 2.X to 3.X (for reasons I can't recall), and then 6.X to 7.X (for an application that had issues adopting zeitwerk). In both of those situations, there was a lot of rote legwork, but once tests were passing, the application was working reliably. The other upgrades (3-to-4, 4-to-5, 5-to-6, 7-to-8) weren't happy-fun-rainbows-and-unicorns, but they weren't catastrophically complicated? Not even in fairly large codebases.
For each of these, a strong test suite was the best tool, which it sounds like you already know?
In my experience, the other impactful factors were:
(1) Reading the CHANGELOGs and knowing enough about Rails to know what they meant for the application.
(2) Using test fixtures (or fixtures with only some factories) for a quicker feedback loop for engineers.
(3) Having a true QA function in the company that isn't just engineers testing their own code.
Honest question: what’s an example of a fully-featured web framework that makes upgrading a “large & old” application painless? In my experience, upgrading an underlying framework that a piece of complex software depends upon without breaking everything pretty much always requires time & good test coverage.
Why do many people mention the need of tests for types in dynamically typed languages?
In Rails my tests are mostly to ensure that a request to a controller returns the expected response and the expected changes in the database. Unit tests are often on validations and the errors they return for invalid data. Then there are functional tests that drive a headless browser.
I have been pretty happy with Java and .NET frameworks, regardless of the lack of appeal in SV influenced circles.
Happiness doesn't always translate into performance, e.g. famous Twitter logo until they moved into JVM and Scala.
While Ruby on Rails took the fame, we already had similar experiences with AOLServer and Vignette, using Tcl.
We had our own variant at a Portuguese startup, and eventually the founders created OutSystems, one of the first graphical RAD tools for Websites and distributed systems development in low code/no code, targeting JVM or CLR infrastructure.
Now having said all of this, it is great to finally see CRuby getting a JIT in the box.
For me it surely is Python with Pytorch, if we talk about frameworks in general.
For web, I can't really offer any useful positive input, I was never satisfied with any framework for Python or Node. I see people praise RoR and Phoenix quite a lot tho!
Trigger alert - While it is good to signal your 900+ IQ to the peasants around you,many many smart and talented developers don't like rust so much so that they'll prefer writing their own programming language and their own compiler over writing single line of Rust.
Jai and Odin come to mind with Jonathan Blow and Ginger Bill.
Many many more folks that are capable of (and have) written widely used beautiful libraries and frameworks that are evidence of their creativity and depth but we don't want to waste space here.
Rust however has a lovely Macho club a good brotherhood.
I'm sometimes amazed by project sizes, a 30k line codebase is small? I'm aware that the ceiling is high but 30k lines of code can encode so much information and behavioural nuance.
Maybe this is just my backend/network focus with Golang though. Scaling beyond 10-15k lines of code always was quite intimidating as it is usually where I lose the ability to just keep a model of the codebase fully in my head.
Speed has usually mattered less to me than memory usage. Most Ruby applications are speed limited by the database rather than Ruby. But when you have a bunch of background workers, every one chewing 2+ gb of memory stacks up.
I wrote one production Rust service and more impressive than the speed was that the thing ran on 30MB memory.
Why would someone who thinks Ruby is slower than Rust (which apparently includes you) be surprised it’s faster than Python? Why does one thing have to do with the other?
I do wonder if it'll ever be possible to get Rust tests to feel as nice to write as, say, test suites in Python or Ruby. I might just be missing a lot of helpers, but a part of me really wants to use a test metalanguage that (for example) RC's everything, gives me implicit casts from strings to what ever type I need, and a bunch of other stuff.
I've always found Rust object buildup to be pretty annoying.
My use cases are fairly minimal though, and the adjacent ecosystem is not as well developed. You likely won't be able to get an out of the box integrated gems for shopping cart, blogging platform, newsletter, analytics etc. as you might for rails. If you are building something new from basic blocks, a lot of the foundational blocks seem to be good state. But again, my experience is very limited.
>But before I did so I researched first. I asked a few instances to analyse the project in terms of gains of complexity, stability, testability, etc., and while (obviously) stability would drop (no types in Ruby) it’s not that awful (Sorbet has types in Ruby!).
Is it not a rage-bait argument to say that not having types implies less stability?
Of what, though? A weird subjective pulled-out-of-the-ass rating system, with also pulled-out-of-the-ass weights? I think that's where GGP's confusion comes from.
It's really not that verbose. I rewrote a Python project in Rust. It was about 10% more lines of code. If they're seeing a bit difference it's definitely an outlier or they're doing something horribly wrong.
> So I had to take a look around to remind myself what Ruby and Ruby on Rails are doing nowadays. They’re doing quite well.
Ah really?
Well ... let's look at TIOBE. Now I am aware that TIOBE sucks, it makes little sense, but even with that in mind, the claim that ruby is doing that well is simply factually WRONG, at the least right now:
Now, I think ruby is a great language, I use it daily as the primary glue language to do literally everything. I call it the ultimate wrapper over C, which ruby ultimately is. But the claim "ruby is doing great" is just simply INCORRECT. And we haven't even gotten to RubyCentral mass-purging developers or adding random new corporate-driven rules to rubygems.org and what not. I never understood why I would be under 100k download restrictions when on github I have full control over my own (!!!) code. I call that an illegal hijacking attempt by RubyCentral (this was about a year before they mass-purged developers anyway, so I could nod my head wisely when that happened lateron, even though I had no advance knowledge, but it did not surprise me once the shopify corporate overlord pulled rank; and DHH sitting on the sidelines making joyful comments at the chaotic situation here on his blog. At that time I noticed that DHH indeed became a problem too).
> There are some typing initiatives (Sorbet), and the language itself is terse as ever.
No sane rubyist uses that typing crap, sorry. And matz isn't the biggest fan of slapping down mandatory types onto everything either. People whose brain is addicted to types, want them; I understand that problem. There is no way you can reason with them because they really WANT types. It's like someone starving for food; that person wants food. There is no way around that. Same with types for these people. And they want to change a language to that too. This is the annoying part. Many years ago I was surprised to hear haskell folks not wanting everyone. After that type addiction, I realise the haskell point of view: some people want to ruin languages. (You may debate whether types ruin ruby or not, but the main point here is that some people want to change a language into something that fits their brain more easily. Now I understand the haskell point of view, despite still thinking this is a snobbish elitist view of exclusion. But language integrity is also indeed important, so I understand that point of view these days.)
> while (obviously) stability would drop (no types in Ruby)
Absolute rubbish nonsense. Absolute. Totally incorrect claim made, from A to Z. But again, you can not reason with these type addiction people. Can't they go to PHP or some other language?
Let's reword it more neutrally then. Which claims and proof support the claim that stability drops because of "no types in Ruby"? Because I never ever had that happen in any code I wrote in ruby in the last +20 years. Yes, you need to be able to query what is possible; often you may have to do .is_a? or .respond_to?. Yes, this is not the same as "advance" type checks. I am not saying types are useless either. What I am saying is that the claim of "you lose stability without types" is ABSOLUTELY RUBBISH NONSENSE. But the brain of type-addicted folks is already set towards "types everywhere". This is the problem. They are trapped in their world of assumptions.
> So in the end it seems I have (licks finger and turns to the wind) 1.47x better outcomes if the app were a Ruby on Rails app instead.
Now he is pulling numbers out of ...
> I have a local LLM running on my (bought it for gaming pre-AI craze) 4090 Ti1 - I’m a free man with unlimited tokens2. So I thought: BRING IT ON!
Ah - and AI already deadlocked his brain on top of that. So not even writing any ruby code but just using AI. And using Rails either. Well, you can write web-applications without rails too. And that works extremely well. That also was the first thing I did when I switched from PHP to ruby back then. And I still don't need or use rails either.
> Since it is a relatively small project the conversion took ~30 minutes. I have no idea if it works or not because I haven’t yet tried running it. But there is one thing I checked, and stared at in horror
So he used AI and still has absolutely no idea about anything. These people don't see a problem with that. Oldschool people didn't go that way.
> That’s right folks! 77% decrease in line count; 4.49 lines of Rust code for each line of Ruby.
Well, using python would also have led to a significant decrease, so that is not surprising. C and C++ and Java also require a lot more information. Types in particular require more syntax and words in general, so really - nothing surprising here. That ruby is succinct and still elegant (except for this type crap) is one reason why people often stick to ruby.
> but I must say it’s looking clean and idiomatic for my dated eye.
But he is using AI here. How does he know that it is clean and idiomatic? The ruby code I write is (to me) very simple and straightforward, typical OOP but simple and practical at all times (whenever possible). AI does not generate such code. And a ton of ruby code on the world wide web, written by humans, looks as if someone beat you silly with a club on the head, before you started to write anything. Even well-used projects such as rack - anyone looked at the source code? Or of sinatra? It looks as if someone was drunk when writing the code. I am biased myself though; for instance, I find Jeremy Evans typically writes elegant ruby code. zverok writes fascinating projects, but his writing style is totally alien to me - your mileage may vary. The point is that there is not really a unified "idiomatic" ruby code. Look at this for instance:
The code was as follows (the link no longer worked, I bookmarked it some
years ago and now I can not find the new code but I assure everyone that
this was that way, because I stored it locally):
t1&.kill&.join
The safe navigation syntax has use cases, I am not denying that either. You
can shorten some code significantly. But I find this syntax utterly horrible
and decided that my code base will be protected against safe navigation horror.
Of course this is a subjective opinion. But ruby syntax is not automatically
great merely because it is ruby. You need to think what you want and even
more importantly what you don't want. And why.
> I can add types using Agents, so probably type safety can be alleviated
Yikes. And the worst part is: type-addicted people can not modify their brain.
I've never seen a type-loving person abandon this love for types.
> Ruby/Rails is pretty much batteries+kitchen sink included, which beats 3GiB of compiled deps.
Ok. Not disputing that. But that more says a lot about Rust than Ruby really.
Because the main question should be why you need so much code in Rust for that.
> Testing will be SO MUCH EASIER
Not disputing that either.
This is probably one of the strangest blog statements I have ever read. I think
ruby is a great programming language, but this AI-powered transition is just ...
strange. Basically he is not really using ruby. But praises ruby. While having
AI generate the code. Am I the only one to find this extremely awkward?
If you replaced "AI" with "a developer" in this article, it might make more sense why it's being dunked on. It would be an article about someone telling someone to do something, and then when the work was done they were happy with the result. It's just a bit of a nothing all round
This defies belief. “I wanted to scratch a technical itch. My local AI completed the job in 30 minutes. I never pressed Start to see if it works, but I did write a blog post about it…”
2016 check out my new JavaScript Library!
2026 check out the work I didn't write!
2036 how I've written 200 lines in this ancient Latin called C
It's the first article on the frontpage now, which means that it doesn't matter the project doesn't work because the readers didn't read.
(Unless bot-pushed of course)
> This defies belief.
Akshually it's pretty normal for 2026.
Yup, since the rise of AI, I still didn't find any product built by it that's even remotely useful to me... People build prototypes a lot, but these are usually buggy and not worth putting money into.
* it wrote a blog post
I assure you Sir/Madam no LLMs were harmed in this post. Grammar would've been much better :)
I did however review it over 5 hours. So ¯\_(ツ)_/¯
At first I thought this would be an interesting article, but as soon as they mentioned using an LLM to do the conversion I lost all interest. It's like saying "I wanted this done so I got my underling to do it, here is my story...". Like why would I bother to read it then, as it was clearly not you doing the conversion or putting any thought into it.
The point isn't about writing it but seeing difference and making probably suboptimal choice.
I mentioned in other comment that I reviewed it extensively. It's not a big project so outside of a few spicy bits it's mostly a web app.
I'd say that saying "not putting thought into it" is unfair. I didn't push the button and YOLO.
I did research about the tradeoffs and consequences. Snippets of Rust code vs Rails are the real thing and testability of Rust app is something I spent 2 months on.
As LLM enthusiast would say: context matters ;)
The biggest problem is the author didn't even bother to verify it. I've seen big multi-model ralph wiggum or whatevers do a conversion. Run for 6 hours. Upon manual inspection to understand how it handled some tricky calculations / logic I find stubs and hard coded truthy returns. So even if you ran a smoke test suite against it -- you'd think it successful...
The biggest problem is that this is software development going forward.
Programming languages don't really matter outside craft programming.
As LLM improve, it will eventually be a matter to specify in which kind of language the specification should be generated.
The UML and RUP crowd has had their vengeance.
That does not explain why people think their project that is 99% written by LLM is worth sharing.
Post ain't about project written in LLM (and Rust one have 6 months in good ol' craft code) but about contrast between two variants.
While personally I'm skeptical about LLM usage (and vibe coding in general) I'm not going to pretend it doesn't exist just on principle. I wouldn't risk rewrite 6 months worth of code to Rails but it's a perfectly good case for LLM conversion.
It doesn't have to be, we have the power to change it by just not using LLMs to generate code-like text sequences.
But if anyone is having their revenge it is the "idea guys", not the UML jockeys.
As long as upper management is measuring AI tools at work not much power is left.
The whole idea with UML jockeys is that we no longer need brick layers, that is the whole point of software factory concepts, and stuff like Rational Unified Process.
The only difference is using markdown this time around.
you sound jealous :)
That's an assumption. How do you infer that from written text? I can not infer that.
To me it is super-strange that one uses AI to come to the conclusion that language x is better than language y. In the past people spent some time using both languages for a while, before reaching any conclusion. With AI it seems insta-gratification or insta-evaluation now. I am beginning to see why Google ruined its search engine for real humans - those who control AI rule the world now. People aren't even noticing this how dependent they are becoming on AI in general.
sorry for the bluntness, but you should have probably thought twice before hitting the send to Hacker News button, i didn't find this in any way interesting and i am definitively not a LLM hater
Hey I'm in the same boat!
I love Go and Rust, they're wonderful languages with their own ups and downs. Sadly I never was able to build a SaaS app with either. Something about a square peg and a round hole... I could be very wrong, but there's a lot of gadgets that come with a SaaS tool, and I'm not inventing them.
RoR is.. "good enough". I can opt-in types whenever, I can build things quick, the tooling is alright, etc.
My first real job was PHP, and there were just too many gotchas there. Ruby seems to steer a bit more towards ecommerce, which intruiged me. And its good enough for Shopify, so...
I built a set of gems (propel_rails) that takes the already terse Ruby on Rails code to the next extreme. It generates a set of top level classes like an API controller and some concerns that then create a full restful resource (model, controller, serializer, unit and e2e tests) with 0 boilerplate code. The controller ends up being only a list of all permitted attributes the api will accept because the restful actions are automatically generated. It’s a bit hard to fully describe but the meta programming power of Ruby really does make amazing things easy.
This sounds like CRUD, distilled.
I suppose it works in terms of your domain model?
It sets up automatic filters, sorting, multi tenancy, authorization, and uses “accepts nested attributes for” to make it more graphic like that simply crud
I can find it on rubygems but the link there to GitHub returns a 404.
Ah. It’s currently private. I haven’t open sourced it yet :)
I'm not sure any language + framework prioritizes developer happiness as much as Ruby on Rails.
I don't think I've ever been unhappier than working on a Rails project. See a bug on the site - something is rendering incorrectly. grep to find the view. Great, there's a method that is being called to render the buggy section. Grep for the method name - 0 hits. Amazing, it's something that is synthesized somewhere and I have no idea where. Guess I'll stop what I'm doing and read docs for an hour. If you do nothing but use Rails all day, sure, but the whole convention over configuration thing is such a huge anti pattern to me.
I won't be as harsh because I have years of experience in Rails and didn't develop harsh feelings against it but moving from Rust/Go/Zig/TypeScript (which I used lately) to Ruby ain't smooth ride.
Discoverability is much worse, LSPs aren't super helpful. Using Dash (documentation app) helps a ton. Still some names are confusing after switch (took a minute to recall that 'filter' is actually 'select' in Ruby).
I won't say that dev experience is bad but it's definitely different.
I would advice reading the "efficient rails" book, which explains a lot about how to debug RoR apps.
The fact that you have to read a book and break out a debugger to do the equivalent of "find all" in any other languages should tell you something right?
My experience is exactly the same as Milch's. I've tried to fix stuff in Gitlab but given up when I couldn't even find where it things are defined.
That can happen in other languages, e.g. Rust or C where macros are used. But it's pretty much the exception there whereas in Rails it seems to be done by default.
I’ve had similar experiences with Spring Boot Java applications. Methods in stack traces that don’t exist in source code but are magicked into existence by annotations.
Hell with lombok it’s not even uncommon to have entire classes with no defined functions at all. shudder
method(:name).source is your friend
`method(:name).source_location`, but yes. Ruby is very introspect-able and it is fantastic.
It’s short term happiness at best, and at the expense of every other possible architectural characteristic (maintainability, performance, reliability, scalability, you name it).
Updating Rails is one of the most painful processes ever. There is no real way to be sure it works. You just have to have 50,000 unit tests, cypress tests, and then hope and pray.
On any sufficiently large and old app, something will always break in a way that isn't caught by your tests or manual testing, and only shows up after it goes out live.
This has not been my experience.
I have taken applications from 2-to-3, 3-to-4, and so on, through 8.X.
If anything it has gotten better/easier over time. The most challenging upgrades were 2.X to 3.X (for reasons I can't recall), and then 6.X to 7.X (for an application that had issues adopting zeitwerk). In both of those situations, there was a lot of rote legwork, but once tests were passing, the application was working reliably. The other upgrades (3-to-4, 4-to-5, 5-to-6, 7-to-8) weren't happy-fun-rainbows-and-unicorns, but they weren't catastrophically complicated? Not even in fairly large codebases.
For each of these, a strong test suite was the best tool, which it sounds like you already know?
In my experience, the other impactful factors were:
(1) Reading the CHANGELOGs and knowing enough about Rails to know what they meant for the application.
(2) Using test fixtures (or fixtures with only some factories) for a quicker feedback loop for engineers.
(3) Having a true QA function in the company that isn't just engineers testing their own code.
> 2.X to 3.X (for reasons I can't recall)
Many big structural changes, IIRC bundler integration, plugins became engines, etc...
It was the big Rails+MERB merge.
Ah yes! I remember Merb now that you say it :)
I have my criticisms of Rails, but that definitely set it on a better path.
Honest question: what’s an example of a fully-featured web framework that makes upgrading a “large & old” application painless? In my experience, upgrading an underlying framework that a piece of complex software depends upon without breaking everything pretty much always requires time & good test coverage.
Type safety would fix 99% of the issues I've had upgrading Rails.
Most Java and .NET ones, not everything breaks, statically compiled, so not as many unit tests required as in dynamic languages.
While it is deprecated, you can do a File=>New Project for Web Forms in 2026.
Why do many people mention the need of tests for types in dynamically typed languages?
In Rails my tests are mostly to ensure that a request to a controller returns the expected response and the expected changes in the database. Unit tests are often on validations and the errors they return for invalid data. Then there are functional tests that drive a headless browser.
Because they are a requirement to avoid runtime errors that usually are compilation errors in other languages.
Not fun in production.
Dynamic languages with optional typing like BASIC or Common Lisp is another matter.
That may have been true (I'm skeptical) back in the RoR 2.x -> 4.x times, but nowadays updating it is a breeze.
I have been pretty happy with Java and .NET frameworks, regardless of the lack of appeal in SV influenced circles.
Happiness doesn't always translate into performance, e.g. famous Twitter logo until they moved into JVM and Scala.
While Ruby on Rails took the fame, we already had similar experiences with AOLServer and Vignette, using Tcl.
We had our own variant at a Portuguese startup, and eventually the founders created OutSystems, one of the first graphical RAD tools for Websites and distributed systems development in low code/no code, targeting JVM or CLR infrastructure.
Now having said all of this, it is great to finally see CRuby getting a JIT in the box.
I get a similar feeling from Elixir and Phoenix without the method_missing foot gun.
Rails is the worst. It’s so easy to make a mess and it’s hard to debug.
For me it surely is Python with Pytorch, if we talk about frameworks in general.
For web, I can't really offer any useful positive input, I was never satisfied with any framework for Python or Node. I see people praise RoR and Phoenix quite a lot tho!
I’m sure the LLM that translated the code was ecstatic!
Ruby? Yes.
Rails? Depends on the project.
Trigger alert - While it is good to signal your 900+ IQ to the peasants around you,many many smart and talented developers don't like rust so much so that they'll prefer writing their own programming language and their own compiler over writing single line of Rust.
Jai and Odin come to mind with Jonathan Blow and Ginger Bill.
Many many more folks that are capable of (and have) written widely used beautiful libraries and frameworks that are evidence of their creativity and depth but we don't want to waste space here.
Rust however has a lovely Macho club a good brotherhood.
If you can switch from Rust to Ruby, and it would make sense, choosing Rust in the beginning was a mistake.
Thats a great summary of the piece and a reason why I decided to share.
I'm sometimes amazed by project sizes, a 30k line codebase is small? I'm aware that the ceiling is high but 30k lines of code can encode so much information and behavioural nuance.
Maybe this is just my backend/network focus with Golang though. Scaling beyond 10-15k lines of code always was quite intimidating as it is usually where I lose the ability to just keep a model of the codebase fully in my head.
Heavily depends on what you're building. A SaaS app with multiple front ends will easily hit 30k.
People think Ruby is slower than Rust, they'll be surprised to know Ruby is actually now faster than python but slower than Go or Rust.
Speed has usually mattered less to me than memory usage. Most Ruby applications are speed limited by the database rather than Ruby. But when you have a bunch of background workers, every one chewing 2+ gb of memory stacks up.
I wrote one production Rust service and more impressive than the speed was that the thing ran on 30MB memory.
I use Go for the same reason, but it seems php can use even less memory.
Why would someone who thinks Ruby is slower than Rust (which apparently includes you) be surprised it’s faster than Python? Why does one thing have to do with the other?
I think they are jesting: https://news.ycombinator.com/item?id=48245262#48246312
I do wonder if it'll ever be possible to get Rust tests to feel as nice to write as, say, test suites in Python or Ruby. I might just be missing a lot of helpers, but a part of me really wants to use a test metalanguage that (for example) RC's everything, gives me implicit casts from strings to what ever type I need, and a bunch of other stuff.
I've always found Rust object buildup to be pretty annoying.
dbg! Is your friend
Curious if there are folks (perhaps from ruby community) using crystal for medium/large projects. How has your experience been?
I recently tried it out in a hobby project and was pleasantly surprised at how smooth the overall DX was, and how little memory it consumed.
Is there such thing as rails for crystal?
Marten and Lucky come close.
My use cases are fairly minimal though, and the adjacent ecosystem is not as well developed. You likely won't be able to get an out of the box integrated gems for shopping cart, blogging platform, newsletter, analytics etc. as you might for rails. If you are building something new from basic blocks, a lot of the foundational blocks seem to be good state. But again, my experience is very limited.
>But before I did so I researched first. I asked a few instances to analyse the project in terms of gains of complexity, stability, testability, etc., and while (obviously) stability would drop (no types in Ruby) it’s not that awful (Sorbet has types in Ruby!).
Is it not a rage-bait argument to say that not having types implies less stability?
No? Maybe the industry can now talk maturely about tradeoffs like that rather than pretending they don't exist.
To count lines of rust code:
fd . -e rs -uu | xargs cat | wc -l
Why not just:
find . -name '*.rs' | xargs wc -l
Or tokei
From whatever to Go ... hype!
From Go to Rust ... hype!
From Rust to Ruby ... the new hype!?
With an LLM. So next week he can write about JavaScript and the next.
> So in the end it seems I have (licks finger and turns to the wind) 1.47x better outcomes if the app were a Ruby on Rails app instead.
Am I reading this right... did this number just come out of thin air?
Is this just generated based on the vibes of the AI?
Also, to just add them up and compare them like that is just compounding nonsense on nonsense.
Tell me you haven’t actually taken engineering class by not telling me you haven’t taken an engineering class
Hint: weighted sum
Of what, though? A weird subjective pulled-out-of-the-ass rating system, with also pulled-out-of-the-ass weights? I think that's where GGP's confusion comes from.
Mounting Debian from LAN on GRUB as bootloader, which is typical for x64_86 motherboards. Iterating /src/ is transforming language in compiler.
"I have no idea if it works or not because I haven’t yet tried running it. But it's 5x shorter!"
The fact that it doesn't end with what happens when they run `rails server` makes me think they did it and didn't like the results.
Not a xkcd, but quite relevant:
https://web.archive.org/web/20091015091833/http://www.hackle...
> Rust is verbose
It's really not that verbose. I rewrote a Python project in Rust. It was about 10% more lines of code. If they're seeing a bit difference it's definitely an outlier or they're doing something horribly wrong.
Next try Elixir.
> So I had to take a look around to remind myself what Ruby and Ruby on Rails are doing nowadays. They’re doing quite well.
Ah really?
Well ... let's look at TIOBE. Now I am aware that TIOBE sucks, it makes little sense, but even with that in mind, the claim that ruby is doing that well is simply factually WRONG, at the least right now:
https://www.tiobe.com/tiobe-index/
Ruby is ranked 23.
Rust is ranked 15.
Again, TIOBE has tons of issues, people pointed that out, but I am pointing here more at a trend. If you look at the graph:
https://www.tiobe.com/tiobe-index/ruby/
It is more obvious.
Now, I think ruby is a great language, I use it daily as the primary glue language to do literally everything. I call it the ultimate wrapper over C, which ruby ultimately is. But the claim "ruby is doing great" is just simply INCORRECT. And we haven't even gotten to RubyCentral mass-purging developers or adding random new corporate-driven rules to rubygems.org and what not. I never understood why I would be under 100k download restrictions when on github I have full control over my own (!!!) code. I call that an illegal hijacking attempt by RubyCentral (this was about a year before they mass-purged developers anyway, so I could nod my head wisely when that happened lateron, even though I had no advance knowledge, but it did not surprise me once the shopify corporate overlord pulled rank; and DHH sitting on the sidelines making joyful comments at the chaotic situation here on his blog. At that time I noticed that DHH indeed became a problem too).
> There are some typing initiatives (Sorbet), and the language itself is terse as ever.
No sane rubyist uses that typing crap, sorry. And matz isn't the biggest fan of slapping down mandatory types onto everything either. People whose brain is addicted to types, want them; I understand that problem. There is no way you can reason with them because they really WANT types. It's like someone starving for food; that person wants food. There is no way around that. Same with types for these people. And they want to change a language to that too. This is the annoying part. Many years ago I was surprised to hear haskell folks not wanting everyone. After that type addiction, I realise the haskell point of view: some people want to ruin languages. (You may debate whether types ruin ruby or not, but the main point here is that some people want to change a language into something that fits their brain more easily. Now I understand the haskell point of view, despite still thinking this is a snobbish elitist view of exclusion. But language integrity is also indeed important, so I understand that point of view these days.)
> while (obviously) stability would drop (no types in Ruby)
Absolute rubbish nonsense. Absolute. Totally incorrect claim made, from A to Z. But again, you can not reason with these type addiction people. Can't they go to PHP or some other language?
Let's reword it more neutrally then. Which claims and proof support the claim that stability drops because of "no types in Ruby"? Because I never ever had that happen in any code I wrote in ruby in the last +20 years. Yes, you need to be able to query what is possible; often you may have to do .is_a? or .respond_to?. Yes, this is not the same as "advance" type checks. I am not saying types are useless either. What I am saying is that the claim of "you lose stability without types" is ABSOLUTELY RUBBISH NONSENSE. But the brain of type-addicted folks is already set towards "types everywhere". This is the problem. They are trapped in their world of assumptions.
> So in the end it seems I have (licks finger and turns to the wind) 1.47x better outcomes if the app were a Ruby on Rails app instead.
Now he is pulling numbers out of ...
> I have a local LLM running on my (bought it for gaming pre-AI craze) 4090 Ti1 - I’m a free man with unlimited tokens2. So I thought: BRING IT ON!
Ah - and AI already deadlocked his brain on top of that. So not even writing any ruby code but just using AI. And using Rails either. Well, you can write web-applications without rails too. And that works extremely well. That also was the first thing I did when I switched from PHP to ruby back then. And I still don't need or use rails either.
> Since it is a relatively small project the conversion took ~30 minutes. I have no idea if it works or not because I haven’t yet tried running it. But there is one thing I checked, and stared at in horror
So he used AI and still has absolutely no idea about anything. These people don't see a problem with that. Oldschool people didn't go that way.
> That’s right folks! 77% decrease in line count; 4.49 lines of Rust code for each line of Ruby.
Well, using python would also have led to a significant decrease, so that is not surprising. C and C++ and Java also require a lot more information. Types in particular require more syntax and words in general, so really - nothing surprising here. That ruby is succinct and still elegant (except for this type crap) is one reason why people often stick to ruby.
> but I must say it’s looking clean and idiomatic for my dated eye.
But he is using AI here. How does he know that it is clean and idiomatic? The ruby code I write is (to me) very simple and straightforward, typical OOP but simple and practical at all times (whenever possible). AI does not generate such code. And a ton of ruby code on the world wide web, written by humans, looks as if someone beat you silly with a club on the head, before you started to write anything. Even well-used projects such as rack - anyone looked at the source code? Or of sinatra? It looks as if someone was drunk when writing the code. I am biased myself though; for instance, I find Jeremy Evans typically writes elegant ruby code. zverok writes fascinating projects, but his writing style is totally alien to me - your mileage may vary. The point is that there is not really a unified "idiomatic" ruby code. Look at this for instance:
https://github.com/ruby/ruby/blob/trunk/test/ruby/test_threa...
The code was as follows (the link no longer worked, I bookmarked it some years ago and now I can not find the new code but I assure everyone that this was that way, because I stored it locally):
The safe navigation syntax has use cases, I am not denying that either. You can shorten some code significantly. But I find this syntax utterly horrible and decided that my code base will be protected against safe navigation horror.Of course this is a subjective opinion. But ruby syntax is not automatically great merely because it is ruby. You need to think what you want and even more importantly what you don't want. And why.
> I can add types using Agents, so probably type safety can be alleviated
Yikes. And the worst part is: type-addicted people can not modify their brain. I've never seen a type-loving person abandon this love for types.
> Ruby/Rails is pretty much batteries+kitchen sink included, which beats 3GiB of compiled deps.
Ok. Not disputing that. But that more says a lot about Rust than Ruby really. Because the main question should be why you need so much code in Rust for that.
> Testing will be SO MUCH EASIER
Not disputing that either.
This is probably one of the strangest blog statements I have ever read. I think ruby is a great programming language, but this AI-powered transition is just ... strange. Basically he is not really using ruby. But praises ruby. While having AI generate the code. Am I the only one to find this extremely awkward?
Idk why people are shitting on you. So many LLM haters on here. It’s changed the game completely and some people just don’t want to accept it.
I think this is cool. Verbosity of languages is important when it comes to coding with AI. I’ve found Go to be a happy medium.
They wrote a blog post about code that they have not even tried running. Whether it’s LLM-generated does not matter.
If you replaced "AI" with "a developer" in this article, it might make more sense why it's being dunked on. It would be an article about someone telling someone to do something, and then when the work was done they were happy with the result. It's just a bit of a nothing all round
> and then when the work was done they were happy with the result
It's worse than that -- they don't even know the result! They never tried to run it!