[handrous]

> I hate having to waste time figuring out the type of every variable and hold it in my head every single time I read a piece of code.

If a codebase doesn't have static types, it damn well better be set up to be highly grep-able. Including dependencies and frameworks.

This is why Rails pisses me off so much. No static types to help you out, and you can't grep (can barely google, even!) methods and properties that aren't defined anywhere until runtime. Is this from core? Is it from some 3rd party gem? Well fuck me, this file doesn't even tell me which gems it's relying on, so it could be literally anything in the entire goddamn dependency tree.

[rightbyte]

> ... grepable ...

This is so important.

It is also the reason why I like global variables. They are accused of making a spaghetti mess but ... in my experience the opposite is true.

Fancy patterns are way worse to reverse engineer than simple flat long functions accessing globals. Easy to debug too!

[mewpmewp2]

I agree with that. I despise all the DI things where I can't "goto" to the definition of the actual dependency that was injected, but only to the interface. So frustrating. It makes understanding what is going on so difficult for me.

[blacktriangle]

That's some Rails stupidity there, not a dynamic language problem. Autoloading symbols by name is straight up dumb.

As for greppable though...then you may as well be using a static language. The point of a dynamic language is to be dynamic, ie you can do those things at runtime.

[nitrogen]

The point of a dynamic language is to be dynamic, ie you can do those things at runtime.

With Rails you have the option of pry-rails, and you can get a list of descendants of important parent classes like ActiveRecord with this: https://apidock.com/rails/Class/descendants

With the combination of vim, rspec, pry, fzf, and ripgrep, it's possible to become quite comfortable refactoring pure Ruby and Ruby+Rails code. But it does take some time to learn how to navigate the Rails runtime code generation magic. The more magic the code, the more you might have to use a debugger to break on method definition, but Ruby's dynamicism lets you do that.

On the topic of frameworks with a lot of magic, having used both Rails and Spring Boot (with Java and Kotlin), I'll take Rails any day. It was way easier to introspect Rails codegen magic with Pry, than Spring's codegen magic with IntelliJ. With Spring Boot, even with Kotlin, we had the burden of semi-manual typing, but lost a lot of the benefits because a lot of DB interaction and API payload handling was still only runtime checked.