[wg0]

If you are doing an MVP prototype or the code would be the client's problem once you're done with your consulting, such bulk boilerplate is fine.

I have extensively worked with Python and Ruby in past but my conclusion is that even though they ramp you up in the beginning but as the code base grows, it becomes harder to guess deeper in the codebase to guess what objects you're dealing with. Specifically in case or Ruby/Rails, the IDE's are of not much help as they're guessing/brute forcing the possible suggestions too.

The type hinting in Python is totally optional and I know you can have stricter linting rules and what not but I'd prefer a a little more statistically typed language for which I think go has the minimalism, won't let you over engineer. Other interesting promising candidates are Nim/Crystal.

So I can start my SaaS on such a Rails boilerplate but it'll be more of a liability of keeping up with the upstream codebase and my own but maybe that's my lack of confidence.

[mattbrewsbytes]

> to guess what objects you're dealing with

I don't understand, why are you guessing? Do you mean the parent objects of things you've written? Like ActiveRecord, etc. I would think that mental overhead is the same in any web+CRUD+ORM type of framework.

[hu3]

I guess what your parent poster is saying is that:

without types, all you have is the variable name to guess what it does.

IDEs help but there's only so much they can do.

[wg0]

Yes that's what I meant. All you have is a variable and IDEs can't figure it all if there's no type on it.

Not just that, let's say even if type is known but some of the methods are generated on runtime than IDE has no idea about it.

[mattbrewsbytes]

That’s not unique to Ruby though, I imagine most dynamic languages fall into this bucket.

[wg0]

Exactly, they do including JavaScript.