Yes, Marc Feeley was my PhD advisor. We came up with the original idea together. I also see it as a development of the work I did in my M.Sc. thesis on type-driven versioning of functions. Basic block versioning is lazy, type-driven tail splitting of code.
Off-topic: I wonder why the site insists on using the super long domain name of "therubyonrailspodcast.com" when (presumably) they own "railspodcast.com" since it redirects to the longer url.
Even if it's for legacy reasons, it seems like podcasts of all things would be the easiest to 301 redirect (the longer url to the shorter).
YJIT is optimized primarily for web workloads. We look at rails performance a lot, but also at various other libraries that are used in that context. If you look at the headline benchmarks at https://speed.yjit.org, it will give you an idea of what we're mostly focused on. This is in contrast with academic compiler project, which often focus on microbenchmarks and code that is very different from the code users actually run in practice.
YJIT or TruffleRuby: I'm biased being that I work on YJIT. The nice thing about YJIT is that it's likely to work out of the box, and just be a matter of calling `ruby --yjit` to turn it on. It will probably use a lot less memory than TR, and it's probably more likely to deliver the result you're looking for at this time (speed boost, no hassle).
That being said, for some small or specialized applications, TruffleRuby could deliver much higher peak performance. If you don't restart your server often and you have a lot of memory available, then maybe you don't care about warm-up time or memory usage, and TruffleRuby could be the right tool for you. Feel free to run your own benchmarks and also to blog about the results (though if you do, please share as much details about your setup as possible).
Wow, I didn't realize there's a Ruby on Rails podcast that's been running for 15 years. That's seriously impressive.
Sometimes I wish I was programming during the RoR hay days. It just seems like a damn fine framework and it's got a real cult (in a good way) following.
I started on Rails in 2011, just before the release of 3.1 (when they switched the default JS framework from Prototype to jQuery!). I basically "grew up" as a programmer on Rails. It's cool to look back and see how Rails, and Ruby itself, has matured over time. Each major release is easier to migrate to than the last and covers more use cases out of the box.
I started with Rails in 05, prior to the 1.0 release.
It was a whole new world for me. I had done BASIC, HyperCard, and C up to that point, and the whole idea of a web framework opened up my eyes. JavaScript, with prototype.js, was fascinating.
We didn’t even have database migrations yet, you just wrote your schema as a SQL file.
I moved to Sinatra a few years later, because at the time the “rails way” was really slow for a lot of things. I still use Sinatra to this day. Ruby is by far my favorite language, and sometimes I think it might be a time to get back into rails and see how far things have come.
I don't miss it one bit. Yes, you can build things quickly, "rails g scaffold" was quite a tool.
But the level of discipline required to keep a large Rails codebase from turning into spaghetti is not to be underestimated. Plus, because of Ruby's flexibility, a bunch of functionality is sort of "magic pudding" and happens via extension and meta-method sort of things.
This makes things like Ctrl+Click being the source of truth and being able to generate some sort of ERD-diagram in your IDE of everything that touches another thing difficult to implement.
I also don't miss dynamic types in the slightest.
Nowadays, I would rather look at Laravel with Livewire and Alpine.js if you want something Rails-esque. PHP is godawful though.
I would say Rails is still in its Heyday. I've been writing ruby since 1.8.7 and I'm constantly surprised by the frequency of major releases of rails, and the backward compatibility (Rails 3 -> 5 was hard). I completely agree about the discipline required to keep a large project clean, although I find that true across the board with large codebases.
I didn't program RoR when it was hot, but I am in a RoR shop now. RoR is by far the easiest framework to jump into an existing project and find what is going on that I have seen, if anything its the opposite of hard to not turn into spaghetti. Comparing this to Spring, React, Node, ASP, etc. I would much rather do Ruby.
> Nowadays, I would rather look at Laravel with Livewire and Alpine.js if you want something Rails-esque. PHP is godawful though.
Why wouldn't you look at Phoenix LiveView, which inspired Laravel's Livewire, then? Elixir also gives you some other advantages you likely haven't encountered before if you haven't worked with Erlang or Akka.
I totally agree. The fact that it's not possible to determine the location of a method being called inside a file until it is run perfectly illustrates the problem with a hyper-dynamic language like ruby. It's a dream for people who love metaprogramming to do things magically, but a nightmare for anyone later inheriting that project.
you can use Django (python) with Types and the codebase will scale a bit larger, there are JITs available for Python too.
ctrl+click works great
can write simple Python code and not do anything crazy, works alright. up to around 30k lines I'd probably consider past the "prototype" phase though and would prefer a compiled language.
I actually agree about large RoR codebases, the last few major ones I've seen were absolute dumpster fires and the solutions implemented to fix them, was more or less standard enterprise java patterns. So you ended up doing java anyway.
On the other hand, I'd say Elixir/Phoenix gives you exactly what you want these days and especially with the gradual type system, non-magic database ecto layer etc.
Readit News
It's the basis for YJIT, which has landed big speedups for the C Ruby implementation over the past few years.
Disclosure: I used to work in a team adjacent to Maxime's.
[0] https://arxiv.org/abs/1411.0352
Even if it's for legacy reasons, it seems like podcasts of all things would be the easiest to 301 redirect (the longer url to the shorter).
It might be a bit rough around the edges, since I didn't do any manual editing.
edit: https://railsatscale.com/2023-12-04-ruby-3-3-s-yjit-faster-w...
edit 2: YJIT or truffle these days?
YJIT or TruffleRuby: I'm biased being that I work on YJIT. The nice thing about YJIT is that it's likely to work out of the box, and just be a matter of calling `ruby --yjit` to turn it on. It will probably use a lot less memory than TR, and it's probably more likely to deliver the result you're looking for at this time (speed boost, no hassle).
That being said, for some small or specialized applications, TruffleRuby could deliver much higher peak performance. If you don't restart your server often and you have a lot of memory available, then maybe you don't care about warm-up time or memory usage, and TruffleRuby could be the right tool for you. Feel free to run your own benchmarks and also to blog about the results (though if you do, please share as much details about your setup as possible).
Sometimes I wish I was programming during the RoR hay days. It just seems like a damn fine framework and it's got a real cult (in a good way) following.
It was a whole new world for me. I had done BASIC, HyperCard, and C up to that point, and the whole idea of a web framework opened up my eyes. JavaScript, with prototype.js, was fascinating.
We didn’t even have database migrations yet, you just wrote your schema as a SQL file.
I moved to Sinatra a few years later, because at the time the “rails way” was really slow for a lot of things. I still use Sinatra to this day. Ruby is by far my favorite language, and sometimes I think it might be a time to get back into rails and see how far things have come.
I don't miss it one bit. Yes, you can build things quickly, "rails g scaffold" was quite a tool.
But the level of discipline required to keep a large Rails codebase from turning into spaghetti is not to be underestimated. Plus, because of Ruby's flexibility, a bunch of functionality is sort of "magic pudding" and happens via extension and meta-method sort of things.
This makes things like Ctrl+Click being the source of truth and being able to generate some sort of ERD-diagram in your IDE of everything that touches another thing difficult to implement.
I also don't miss dynamic types in the slightest.
Nowadays, I would rather look at Laravel with Livewire and Alpine.js if you want something Rails-esque. PHP is godawful though.
Why wouldn't you look at Phoenix LiveView, which inspired Laravel's Livewire, then? Elixir also gives you some other advantages you likely haven't encountered before if you haven't worked with Erlang or Akka.
I have a rant about it: https://bower.sh/on-autoloading
And don't get me started on the footgun that is ActiveRecord callbacks: https://guides.rubyonrails.org/active_record_callbacks.html
ctrl+click works great
can write simple Python code and not do anything crazy, works alright. up to around 30k lines I'd probably consider past the "prototype" phase though and would prefer a compiled language.
On the other hand, I'd say Elixir/Phoenix gives you exactly what you want these days and especially with the gradual type system, non-magic database ecto layer etc.
Who cares if you can save 10 minutes coding a page if it takes you an hour to figure out what's happening on with that code.