[jimmaswell]

My impression is that a Rails app is an unmaintainable dynamically-typed ball of mud that might give you the fast upfront development to get to a market or get funded but will quickly fall apart at scale, e.g. Twitter fail whale. And Ruby is too full of "magic" that quickly makes it too hard to tell what's going on or accidentally make something grossly inefficient if you don't understand the magic, which defeats the point of the convenience. Is this perception outdated, and if so what changed?

[nirvdrum]

If the the Twitter fail whale is your concern, then your perception is outdated. Twitter started moving off Ruby in 2009. Both the CRuby VM and Rails have seen extensive development during that decade and a half.

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.

[ksec]

The CRuby VM, or the CRuby interpreter alone is at least 2-3x faster since Fail Whale time. And JIT doubles that to 4 - 6x. Rails itself also gotten 1.5x to 2x faster.

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.

[caiusdurling]

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

[radlad]

Maybe not the best testimonial. From what I've heard, Mastodon is a bit of a beast to scale. While some of this is probably due to ActivityPub (a la https://lucumr.pocoo.org/2022/11/14/scaling-mastodon/) itself, some of it may be related to Ruby's execution model: https://lukas.zapletalovi.com/posts/2022/why-mastodon-instan...

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.

[m00x]

Rails can become a ball of mud as much as any other framework can.

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.

[amomchilov]

The unrefactorable ball of mud problem is real, which is why both Stripe and Shopify have highly statically typed code bases (via Sorbet).

Btw Stripe uses Ruby, but not Rails.

[byroot]

I'd say sorbet largely adds to the mud, but to each their own.

[m00x]

Some Stripe services are 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.

[weaksauce]

it's faster than python in some tests that i've seen.

[taurknaut]

> Rails can become a ball of mud as much as any other framework can.

...but rails can fit this dysfunction on a single slide ;)

[fredrikholm]

> It's not the fastest language, but it's faster than a lot of dynamic languages.

Such as?

IME Ruby consistently fall behind, often way behind, nearly all popular languages in "benchmark battles".

[Lio]

Python? Ruby with YJIT, JRuby or Truffle Ruby usually beats python code in benchmarks.

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.

[relistan]

In my work I’ve seen that TruffleRuby codebases merging Ruby and Java libraries can easily keep pace with Go in terms of requests per second. Of course, the JVM uses more memory to do it. I mostly write Go code these days but Ruby is not necessarily slow. And it’s delightful to code in.

[fredrikholm]

> Python? Ruby with YJIT, JRuby or Truffle Ruby usually beats python code in benchmarks.

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.

[Lio]

Moving the goal posts? Perhaps I misunderstand what you are asking. Python is the not the worst in class scripting language. For example perl and TCL are both slower than python.

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.

[fredrikholm]

Thank you for a great answer; I did not mean any ill will and apologize if that was how it came across.

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.

[faraaz98]

Twitter fail whale was more skill issue that Rails shortcomings. If you read the book Hatching Twitter, you'll know quickly they weren't great at code

[taurknaut]

This is actually pretty accurate, except ruby is just slower, not randomly fragile at scale.