Re:Why We’re Sticking with Ruby on Rails at Gitlab
by ydnaclementine on Monday June 13, 2022 @01:39PM
(#31728765)
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
Re:Why We’re Sticking with Ruby on Rails at Gitlab
by grimjack00 on Monday June 13, 2022 @05:41PM
(#31732146)
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.
Re:Why We’re Sticking with Ruby on Rails at Gitlab
by ravenstine on Monday June 13, 2022 @02:29PM
(#31729476)
If speed was all that mattered then almost no one would be using Python.
Re:Why We’re Sticking with Ruby on Rails at Gitlab
by munificent on Monday June 13, 2022 @04:47PM
(#31731569)
That's why my last sentence starts with "if".
Re:Why We’re Sticking with Ruby on Rails at Gitlab
by dijit on Wednesday June 15, 2022 @04:58PM
(#31759391)
Speed of development, so still speed- just across a different axis.
Re:Why We’re Sticking with Ruby on Rails at Gitlab
by native_samples on Monday June 13, 2022 @04:33PM
(#31731412)
These days TruffleRuby can run Ruby at incredible speeds. It unfortunately can't run really huge apps at the scale of GitLab though.
Re:Why We’re Sticking with Ruby on Rails at Gitlab
by wiseowise on Monday June 13, 2022 @05:52PM
(#31732248)
> It unfortunately can't run really huge apps at the scale of GitLab though.
Why?
Re:Why We’re Sticking with Ruby on Rails at Gitlab
by kaba0 on Monday June 13, 2022 @06:29PM
(#31732573)
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.
Re:Why We’re Sticking with Ruby on Rails at Gitlab
by native_samples on Tuesday June 14, 2022 @05:34AM
(#31736554)
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.