> Finally, the fact that you need the console to even understand the meaning of a code fragment is a perfect example of language failure.

Isn't that the case for every language with polymorphism? Even C, once you add function pointers to the mix.

I've certainly heard polymorphism and OOP criticized on these grounds, but unless you're a hardcore kernel or embedded developer, that ship sailed about 25 years ago. Everybody uses debuggers and log statements these days. Expecting to be able to look at a code sample in isolation and know what it does is unrealistic for any large-scale system.

> Expecting to be able to look at a code sample in isolation and know what it does is unrealistic for any large-scale system.

My number one favorite thing about Go: you can look at a code sample in isolation in a large-scale system and know what it does.

Why? Every identifier is either lexically scoped or lives in a module. There are about 6 control structures and they all do what they look like they do. Operators are all defined over a small set of well-defined primitives, they can't be overridden. Closures, callbacks, and non-linear control flow are rare and obvious. There is no way for code to be skipped by exceptional control flow apart from the single escape hatch called panic().

It's really like no other language I've ever coded in. You can work in large codebases that are as clear as your average Go code, if you have strong guidance about what kinds of code complexity are acceptable and you are ever-vigilant about avoiding language pitfalls, but nothing is quite as freeing as knowing for a fact you will be able to parse someone else's code because there wasn't any way for them to write something you can't understand.

You still have interfaces. When you invoke a method on an interface, you don't know exactly which code will be called. It could do anything from crash to format your hard drive. In theory, the semantics of the interface should be well-specified and any implementation that doesn't conform to them is a bug, and Go culture holds pretty strictly to this, but there's nothing in the compiler that imposes solid restrictions on what the implementation of an interface can do.

If you're disciplined, you can write solid, easy-to-understand code in any language, Javascript included. I've worked on million+ line Javascript codebases and been productive (as a developer new to the codebase) within 3 days. But this imposes trade-offs in verbosity and flexibility that are often not worth it for most (non-Google-scale) JS codebases.

> Expecting to be able to look at a code sample in isolation and know what it does is unrealistic for any large-scale system.

I don't know why you'd think that. In a typed language, you simply look at the types and you know exactly the intended meaning of a code fragment ie. what inputs are needed, what outputs are produced, etc. That's not remotely the case for JavaScript due to its implicit conversions.

No? Also, there's more than one kind of polymorphism.