3 ms·
Ruby/Rails with static type checking is a mediocre experience. I would say it's good enough when starting out, even great. But once you have many teams working
by karmakaze 2y ago
Ruby/Rails with static type checking is a mediocre experience. I would say it's good enough when starting out, even great. But once you have many teams working on it, you wish for better language strictness, to do safe and widespread refactoring for instance.
ActiveRecord has many limitations when trying to get efficiency from infrastructure (either because you've grown/scaled, or to minimize costs while growing). The main problem is with model instances having actions attached to them, you have to make and jump through hoops to batch the individual callbacks.
Working on a performance improvement project, we discovered that doing ModelClass.new (not doing any I/O and even if that class is empty with no callbacks) is about 400x slower than doing MyClass.new for a plain Ruby class that holds a table's attributes. Processing a thousand of these things in a request with a handful of associated models for each can eat up 100s of ms before doing anything useful.
And even dropping down to using ModelClass.insert_all(array_of_hashes) which bypasses ActiveRecord model instantiation is still slow in the way it generates the SQL before executing it.
You can scale throughput by having many webapp servers (at the cost/constraint of many database connections) but that doesn't help latency per request.
Working at a Rails and MySQL shop is about as close to guaranteed employment as I know as there's always tough problems to solve as a company continues to expand in scope and scale, and always new devs doing their best but still introducing patterns that don't age well.