Optimizing Ruby Path Methods

Re:Optimizing Ruby Path Methods by stackghost on Saturday April 18, 2026 @09:20PM (#47821028)

I use Rails for many of my side projects. Because of the emphasis on convention over configuration, Rails codebases tend to be succinct with minimal boilerplate, which keeps context windows small. That in turn makes it great for agent-assisted work.

For web stuff, with server-side rendering and partials it means minimal requirement to touch the hot mess that is JavaScript, and you can build PWAs that feel native pretty easily with Hotwire.

Ruby is slow as fuck though, so there's a tradeoff there.

[ Parent | on HN ]

Re:Optimizing Ruby Path Methods by matltc on Sunday April 19, 2026 @03:14AM (#47822396)

Not really slow since YJIT, I think 3.1?

[ Parent | on HN ]

Re:Optimizing Ruby Path Methods by Lio on Sunday April 19, 2026 @03:32AM (#47822462)

YJIT is amazing but for me, JRuby and TruffleRuby were the real game changers.

For anything "slow" I can put it in Sidekiq and just run the worker code with TruffleRuby.

I have high hopes for ZJIT but I think TruffleRuby is the project that proves that Ruby the language doesn't have to be slow and the project is still getting better.

If ZJIT, JRuby or TruffleRuby can get within 5-10% of speed of Go without having to rewrite code I would be very happy. I don't think TruffleRuby is far off that now.

[ Parent | on HN ]

Re:Optimizing Ruby Path Methods by matltc on Sunday April 19, 2026 @03:48AM (#47822529)

Ah yeah I'm only vaguely familiar with Go. Didn't realize the speed differential was this drastic.

[ Parent | on HN ]

Re:Optimizing Ruby Path Methods by stackghost on Sunday April 19, 2026 @03:30AM (#47822455)

Even with yjit it's still more than twice as slow as even Go, to say nothing of C# AOT, which depending on the benchmarks is like 4x as fast.

[ Parent | on HN ]