The fact you don't need import statements to use code across a Rails app feels like a blessing at the start, but as the codebase grows, it can become

The fact you don't need import statements to use code across a Rails app feels like a blessing at the start, but as the codebase grows, it can become a nightmare trying to figure out where something is defined or how something has been altered Are you willing to share examples? I was a Rails developer for a long time and it certainly has its pitfalls. But I don't feel that this was one of them and I certainly don't think that explicit imports would solve this problem for you. Do you have a bunch of global variables (or external data stores like Redis caches etc) being modified by only-God-knows-what? I don't know how explicit imports would solve that. I'm not sure how "import Foo" versus "Foo=42" is going to help you, unless perhaps if you've given your global thing an identifier that is impossible to grep for. You can also have the behavior you want in Rails, anyway! You have full control over autoloads! Put your code in a non-autoloaded folder. Boom, now you have to explicitly `require` it before using it. The lack of typing leads to way more maintenance - I have Rails apps that are years old and I still get regular error notifications (method doesn't exist on nil is a particularly common one) Static typing isn't your answer. Unexpected nils/nulls/whatever are a runtime error, and are almost always caused by some external resource (typically, the results of a database query or maybe an external API call) being unexpectedly nil, coupled with a sloppy lack of proper exception handling. I don't care how iron-clad your language's type system is, it won't magically help you handle unexpected external runtime data or make up for a lack of exception handling and/or testing.