3 ms·
Agreed. The fundamental design flaw with Rails: https://bower.sh/on-autoloading https://bower.sh/on-autoloading
by qudat 2y ago
Agreed. The fundamental design flaw with Rails:
https://bower.sh/on-autoloading https://bower.sh/on-autoloading
- ch4s3 2y agoAutoloading 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.
- qudat 2y agoKnowing where things are defined is table stakes. A language that supports making it nearly impossible to find a function definition is objectively bad.
- ch4s3 2y agoMy 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.
- seattle_spring 2y agoIt'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.
- ch4s3 2y agoYou 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.