Hacker News Reader

Comment by ch4s3 | Hacker News Reader

The author should be careful of what they’re wishing for with respect to ActiveRecord callbacks. They’re sort of what people might call a sharp knife. You can get a lot done quickly but easily end up with something that’s dangerous to operate later.

View on HN

> You can get a lot done quickly but easily end up with something that’s dangerous to operate later.

That's my experience with all of Rails.

Flipside, you can get a lot done with rails very quickly, so your odds of success are much higher.

I think Rails is great if you don't go wild with things like callbacks, 10s of levels of partial nesting, and mystery behavior included in controllers. If you keep your gem use sane too, you'll be fine.

Agreed. The fundamental design flaw with Rails:

https://bower.sh/on-autoloading

Autoloading is fine as long as you don't go nuts with gems or write classes that will stomp on other implementations of a namespace if autoloaded. The UX as the article concedes is great most of the time. The problem usually arises when someone pulls in a gem that does a ton of class opening and can poison the rest of the application with unexpected behavior. Yes, making you vulnerable to this is a downside of autoloading, but its within your control when adding new code.

Knowing where things are defined is table stakes. A language that supports making it nearly impossible to find a function definition is objectively bad.

My point is that it’s only hard to know that if you create that problem yourself in rails, with some exceptions in ActiveSupport. The system just allows you to make that mistake, but experienced practitioners generally will not do that.

It's impossible to stop all 100+ engineers on a large team from using footguns like that. It's why I find Rails to be an awful solution for large or mature companies: sure if everyone is a "Rails ninja" who perfectly knows the consequences of every bit of code they write, a Rails app can be beautiful and perfect. That's simply not realistic as an org grows beyond a certain size.

You could make that case for a lot of popular tech stacks, and in many circumstances 100+ engineers working in a single code base is going to be a pain regardless of thee stack.

Reply on news.ycombinator.com