From Rust to Ruby | Hacker News Reader

From Rust to Ruby

xlii.space

127 pointsxlii102 comments

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…”

> 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 :)

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)

I did however review it over 5 hours. So ¯\_(ツ)_/¯

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

2037 using humans to accelerate your token throughput by a fellow LLM (the 7th method will surprise you)

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.

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.

My experience tells me. You are disagreeing with me, but you don't give negative vibes in your comment. The other comment sounded too negative:

<< I lost all interest >> << why would I bother >> << putting any thought into it >>

It could have been worded neutrally and still convey the same points of disagreement. Interestingly, look at their other comments, they are all contentious.

I was also experimenting psychologically, to see what reactions I would get.

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.

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.

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.

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 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 ;)

I'm not sure any language + framework prioritizes developer happiness as much as Ruby on Rails.

I get a similar feeling from Elixir and Phoenix without the method_missing foot gun.

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.

method(:name).source is your friend

`method(:name).source_location`, but yes. Ruby is very introspect-able and it is fantastic.

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

Spring Boot is very similiar to Rails. That's what was surprising to me, when I was forced to use it at uni. The annotations magic brings all the PTSD of method missing from Ruby

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.

Exactly. Sure, I can go read a book and learn about Rails. If I wanted to be a Rails specialist I probably would, but I don't want to be a Rails specialist. And like you said, other languages can do this too, but I haven't really found it to be too much of an issue. I remember one time where I had to break out whatever the rustc flag is that just produces the code with expanded macros, but that's it.

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.

filter is also just filter in ruby - aliased as select (and find_all) on Enumerable.

facepalms

Weird that searching for it didn't yield any results, though I stand corrected. However it seems that select is the actual "root" of documentation. Filter sends to find_all, find_all sends to filter or select.

The worst part is communicating to the Ruby on Rails community that they have a problem with DX or that Rails is not really the top choice anymore for new startups. It's a cult of DHH. I am still mostly part of the Rails ghetto; it's paying my bills, but after gaining more experience during my computer science master's degree with statically typed languages, I clearly see the pitfalls of Ruby.

People often miss the difference between simple and easy. Yes, Ruby is easy, but it's not simple, and it will make you suffer a lot if you get to a complex app. The debugging sessions in Rails are a nightmare. Meanwhile Ruby community is acting like religion, it's almost impossible to convert people from Ruby to other languages, they don't see the language as tool, but as part of their identity

Maybe I'm just not tapped into the community but I've been a ruby developer going on 6 years now and I find debugging ruby apps no better or worse than any other languages I've worked with over the years. It's fairly easy to instrument ruby much like all the other dynamic languages (python3, js, etc) but with better ergonomics. My main qualm with ruby is their reliance on external type files for type annotations. What a terrible idea. Should have just done inline optional types like python3 or typescript.

I’m sure the LLM that translated the code was ecstatic!

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.

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.

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.

Type safety would fix 99% of the issues I've had upgrading Rails.

things that people in Ruby community don't like to hear for $1000

Yes, typing would obviate the need for the sorts of extensive unit testing I'm talking about here. I feel that. Luckily, the frontier LLMs (especially Claude) have gotten _really_ good at writing Rspec...

That may have been true (I'm skeptical) back in the RoR 2.x -> 4.x times, but nowadays updating it is a breeze.

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.

Rails is the worst. It’s so easy to make a mess and it’s hard to debug.

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.

Ruby? Yes.

Rails? Depends on the project.

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 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 :)

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...

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.

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

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.

The Rust community is as far from a "macho club" as it can possibly be.

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.

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

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.

>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

Claude works in Rails apps extremely well. As the author of this blog points points out, Ruby allows you to get a ton done with minimal coding. Also, Rails uses convention over configuration, making Rails apps even terser.

One hypothesis for the effectiveness of Claude writing Rails apps is its token efficiency.

I ran across this project awhile back that attempts to measure and compare the token efficiency across projects, and Rails does really well:

https://felipemrvieira.github.io/SyntaxTax/dashboard/

> 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.

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.

"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.

I always check hn comments before viewing the article . The comments alone saved me lot of time for not viewing the article

> I have no idea if it works or not because I haven’t yet tried running it.

This should have been disclosed in the first paragraph

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

Mounting Debian from LAN on GRUB as bootloader, which is typical for x64_86 motherboards. Iterating /src/ is transforming language in compiler.

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):

    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?

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.

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!

oh yeah - in this case the result is that the code was smaller and they were happy with that. correctness was not a criteria

They wrote a blog post about code that they have not even tried running. Whether it’s LLM-generated does not matter.

Reply on news.ycombinator.com