Hacker News Reader

Comment by hsm3 | Hacker News Reader

Aren't most of those shenanigans done early in the VM's lifespan (as Rails boots, actions are called the first time,...), after which the world would be stable, and JIT-related caches wouldn't have to be lost?

View on HN

Generally yes, and I won’t get into the weeds about how inlined methods can have their inlinedness invalided if you look too hard at or breathe on them- but this isn’t a deterministic process. The first time you touch an ActiveRecord::Model, the database is queried and your classes ARE redefined. It’s not even close to the same ballpark of loading a new class on the JVM, and the stabilizing assumption you’re hoping exists often doesn’t. Death by 1,000 cuts

New Rails dev here: I believe the entire ActiveRecord model is constant monkey patching.

Long time Rails dev here. I believe not. The Rails core devs have long known that monkey patching is not thread safe, and blows Ruby method caches, so they already reserve monkey patching for initialization time.

Do you have something specific in mind? From my understanding of ActiveRecord, most of the method generation should happen the first time the class is defined.

Closer to the first time it's used. Schema gets queried and methods get added the moment you do the first query on the model normally.

This is not true in production, where eager loading is always on.

I feel that the definition of "monkey patching" doesn't (or shouldn't) cover what Rails does in AR. Monkey patch suggests a change of behaviour over what was initially intended, however dynamic method generation in AR is very-much part of the intended API.

That said, there are plenty of Rails apps that do monkey patch Rails internals, for better or worse.

Reply on news.ycombinator.com