> Ruby isn't the fastest language, but it's now competitive enough that the same critics might as well throw Python under the bus while they're at it.
You say that like it's a point in support of Ruby, but, yes, absolutely, Python should be thrown under that same bus. Both languages are dramatically slower than other languages that are available. My little hobby programming language with a bytecode VM I wrote myself in a single C file is faster than Ruby and Python. It would be hard to design a language that isn't easy to make faster than Ruby and Python.
They both pay an incredible runtime performance cost for their deep support for dynamic runtime metaprogramming and mutability. If you don't want those features, I don't think it makes sense to use those languages.
I would argue the eventual "bogged down" feel of a Rails application isn't ruby itself. It's rather the abuse the database takes because ActiveRecord allows you to lazy load records so easily by abstracting SQL calls, so you're hitting the database many times per request and not realizing it until you get bitten. There is an option to disable lazy loading at a project level, but I've run into gems that assume it's enabled.
For comparison, elixir's Ecto doesn't allow lazy loading
In addition, for things that can't be done easily with ActiveRecord, you can write your own SQL, but then you really need to know SQL to get the performance right.
Where I work, our main product is a Rails monolith, over 10 years old at this point. The few serious performance issues we currently have are due to complicated SQL queries written back when the DB was much smaller.
I guess part Hyrum’s law in that big projects depend on implementation details to a degree, related but many C extensions (though Graal can run these as well, but perhaps not all of them), and last I read about it, the JIT compiler is not yet that good at optimizing very big applications — it takes a really long time for some functions to become hot enough.
I think it's just that the very largest codebases are the most likely to end up depending on obscure bugs in Ruby or the surrounding ecosystem itself, or maybe features that basically nothing ever uses except that one file buried deep in that one gem that three real programs use. Ruby apparently has a lot of stuff like that.
You say that like it's a point in support of Ruby, but, yes, absolutely, Python should be thrown under that same bus. Both languages are dramatically slower than other languages that are available. My little hobby programming language with a bytecode VM I wrote myself in a single C file is faster than Ruby and Python. It would be hard to design a language that isn't easy to make faster than Ruby and Python.
They both pay an incredible runtime performance cost for their deep support for dynamic runtime metaprogramming and mutability. If you don't want those features, I don't think it makes sense to use those languages.