There isn’t really a much more productive web dev setup than Rails + your favorite LLM tool. Will take time to earn Gen Z back to Rails though and away from Python/TS or Go/Rust.
It's not the fastest language, but it's faster than a lot of dynamic languages. Other than the lack of native types, you can manage pretty large rails apps easily. Chime, Stripe, and Shopify all use RoR and they all have very complex, high-scale financial systems.
The strength of your tool is limited to the person who uses the tool.
Btw Stripe uses Ruby, but not Rails.
Having types helps, but it's not a necessity. When I was at Chime we faired very well with just rails and no types.
Such as?
IME Ruby consistently fall behind, often way behind, nearly all popular languages in "benchmark battles".
I haven’t seen a direct comparisons but I wouldn’t be surprised if Truffle Ruby was already faster than either elixir, erlang or php for single threaded CPU bound tasks too.
Of course that’s still way behind other languages but it’s still surprisingly good.
Isn't that moving the goal post a lot?
We wen't from 'faster than a lot of others' to 'competing for worst in class'.
I'm not trying to be facetious, I'm curious as I often read "X is really fast" where X is a functional/OOP language that nearly always ends up being some combination of slow and with huge memory overhead. Even then, most Schemes (or Lisps in general) are faster.
Being faster single threaded against runtimes that are built specifically for multithreaded, distributed workloads is also perhaps not a fair comparison, esp. when both runtimes are heavily used to write webservers. And again, Erlang (et al) come out faster even in those benchmarks.
Is TruffleRuby production (eg. Rails) ready? If so, is it that much faster?
I remember when the infamous "Truffle beats all Ruby implementations"-article came out that a lot of Rubyists were shooting it down, however this was several years ago by now.
Originally you just asked, "such as" [which dynamic language ruby is faster than?] Implying ruby is slower than every other dynamic language, which is not the case.
JRuby is faster than MRI Ruby for some Rails workloads and very much production ready.
Truffle Ruby is said to be about 97% compatible with MRI on the rubyspec but IMHO isn't production ready for Rails yet. It does work well enough for many stand alone non-rails tasks though and could potentially be used for running Sidekiq jobs.
The reason to mention the alternative ruby runtimes is to show that there's nothing about the language that means it can't improve in performance (within limits).
Whilst it's true that ruby is slower than Common Lisp or Scheme, ruby is still improving and the gap is going to greatly reduce, which is good news for those of us that enjoy using it.
Perl, Tcl, Smalltalk etc are basically non-existant from where I'm from, so they didn't occur to me.
Perhaps I'm projecting a lot here. I have worked a lot in high performance systems and am often triggered by claims of performance, eg. 'X is faster than C' when this is 99.9% of the times false by two orders of magnitude. This didn't happen here.
Thank you for taking the time to answer.
Oh not at all, no I didn't think that. I'm enjoying the conversation.
It's interesting that you mention Smalltalk as I believe that some of the JIT ideas we're seeing in YJIT are borrowed from there.
As for all the "faster than C" talk here is very specific to ruby (or JIT'd) runtimes and overheads only in that context.
I think it gets mentioned because it seems so counter intuitive at first. It's not to imply C isn't orders of magnitude faster in general.
Along with the new out of the box features of Rails 8, the work on Ruby infrastructure is making it an exciting technology to work with again (IMHO).
Two very dynamic systems, designed for being a complete graphical workstation, Perl, Tcl, Python, Ruby were as originially implemented, not even close of the original Smalltalk JIT paper from Peter Deutsch's paper"Efficient Implementation of the Smalltalk-80 System." in 1984!
...but rails can fit this dysfunction on a single slide ;)
I never worked at Twitter, but based on the timeline it seems very likely they were running on the old Ruby 1.8.x line, which was a pure AST interpreter. The VM is now a bytecode interpreter that has been optimized over the intervening years. The GC is considerably more robust. There's a very fast JIT compiler included. Many libraries have been optimized and bugs squashed.
If your concern is Rails, please note that also has seen ongoing development and is more performant, more robust, and I'd say better architected. I'm not even sure it was thread-safe when Twitter was running on it.
You don't have to like Ruby or Rails, but you're really working off old data. I'm sure there's a breaking point in there somewhere, but I very much doubt most apps will hit in before going bust.
And then you have CPU that is 20 - 30x faster compared to 2009. SSD that is 100x - 1000x faster, Database that is much more battle tested and far easier to scale.
Sometimes I wonder, may be we could remake twitter with Rails again to see how well it goes.
Mastodon is written in Ruby on Rails (:
My issue with Ruby (and Rails) has always been the "ball of mud" problem that I feel originates from its extensive use of syntactical sugar and automagic.
But C?
Rails maybe was popular in the US at some point but it was always niche in the rest of the world.
All my new projects will be Rails. (What about projects that don’t lend themselves to Rails? I don’t take on such projects ;)
Well, because it isn't.
Crystal is an ergonomic language, too, looking a lot like Ruby even beyond a cursory glance. What Ruby has, like any longstanding language, is a large number of packages to help development along, so languages like Crystal have to do a lot of catching up. Looking at the large number of abandoned gems though, I'm not sure it's that big a difference, the most important ones could be targeted.
I'm not sure that has any relevance when compared with Python or JS or Go though, they seem to have thriving ecosystems too - is Rails really that much better than the alternatives? I wouldn't know but I highly doubt it.
I really think so. I've _looked_. I've tried all sorts of other web frameworks. And, admittedly, I am most familiar with Rails, so I'm maybe a bit biased. But it's hard to find anything that comes particularly close to the productivity of using Rails. The tooling's great, the ecosystem is great, it's organized well, the documentation is good. It's just... really a pleasant experience to use.
Elixir's Phoenix comes pretty close, as does PHP's Laravel, imo. Special shout out for Rust's Loco, too, which is relatively new, but looking potentially promising.
I recommend giving Rails an open-minded tire kicking. I think you'll be surprised by how quickly you can get going.
You even seem to admit as much while being most familiar with Rails. Do you know anyone who'd love to switch over? Or would you choose it ahead of a competitor if you were green? There'd have to be a large competitive advantage.
Unfortunately I think language differences mean it’s going to be a long time before anyone catches up. Ruby just makes for some really interesting wizardry that as far as I can tell isn’t possible (or perhaps not as ergonomic?) in Typescript.
Furthermore there seems to be a cultural difference. I haven’t met many JS devs who came to the Ruby side and were like, “Aw shit this is better.” (I’m one such dev, but I hated Ruby and Rails for a really long time before I changed my opinion and embraced it.)
But at this point in my career I value stable boring technology way more than my personal taste du-jour so I code in Ruby and really love Rails.
No, it never intended to be a replacement to Ruby. They share similarities in syntax, the same way Elixirs syntax reminds you of Ruby.
If you want faster Ruby, check out MRuby (not always an drop-in replacement though).