I see what you mean with ruby, it encourages to be clever, and I had some exposure to work on somebody's "clever" code.
I'm not as familiar with js, but feels similar to me as well.
What makes things worse they are both dynamic languages, but there's a middle ground.
It feels like Rust for example (I'm still planning to learn it) looks like have the right amount of functionality. Java or even C. I think what you experienced is the extreme case of it.
This is just the old conflict between ops and dev. A software dev wants a little code to express a lot, while maintaining some central guarantees, and doesn't really care about edge-cases beyond not having to code them explicitly. Needless to say, a few edge cases will turn out not to be what the dev intended, no matter how smart they are. Tests focus on the central guarantees and nothing else.
Ops is the next guy who comes in, who is only ever supposed to keep everything running. Changing things is second priority, if it's anywhere at all on the priority list. (S)he will HATE any edge case they don't know exactly what happens because it can be bad, and it's the source of all their work. They want to manually code every edge case, and have that covered by a test.
C/C++ ("smart" C++ specifically), Haskell, Lisp, ... are for the software devs.
Go, Java, C#, ... are for the software ops folks.
A large bank should probably be using Java. Someone trying to start up a new bank may prefer Haskell.
I don't see this conflict resolve any time soon. Personally I find the large bank situation somewhere between soul-crushing and suicide-inducing. But I've met plenty of people very happy in such situations, and great for them. I may even consult for them, because for 1-2 months or so software ops can be quite interesting. Figuring out how to introduce changes in a software ops org is ... usually a challenge in addition to figuring out how the software system should change.
You always come out well, because there's always large improvements that can be made because nobody's doing that. They're busy triple-checking that the next parent-teacher conference of employee 271 doesn't interfere with the oncall schedule.
And frankly, I could (and probably can still) use a few lessons in "this edge-case fuckup is not acceptable and you missed it !". I've been humbled several times by steering a large problem past all security measures of a software ops organization in the past.
>Ops is the next guy who comes in, who is only ever supposed to keep everything running.
>Go, Java, C#, ... are for the software ops folks.
Can't say anything about Java or C# but one of the reasons we use Go is because the requirements change often and you can adapt your code quickly.
At the same time our code (my main field is systems integration) is required to keep running obviously. New requirements should not change this fact.
So on a spectrum I'd say Go is 7/10 OPS. Subjectively.
Obviously Go probably is not the type of language you should chose for your MVP or prototyping. Unless you are sure you have a full picture in your head already.
What makes things worse they are both dynamic languages, but there's a middle ground.
It feels like Rust for example (I'm still planning to learn it) looks like have the right amount of functionality. Java or even C. I think what you experienced is the extreme case of it.