People advocate against Go partly because they'd rather not have to work on Go codebases in future.
People advocate against Go partly because they'd rather not have to work on Go codebases in future.
HN is not a very understanding place...
To a lesser extent the same is true of Rustaceans - they tend to be well aware of the constraints of their language, and won't try to defend it or pump it outside of some specific use cases. Nor do the Rust designers who are fairly humble.
Nobody should be calling Go users stupid. But they typically don't. At least not here. The language itself, on the other hand ...
Everything is a compiler exception. Nothing makes sense. Nothing.
The absolute worst in Go, in my opinion, is the "range" function/special case. It is return-type polymorphic. That's right, it does different things depending on what you assign it's result to (not even C++ dared to go there). Not parameter polymorphic, return type polymorphic. "Assign" a range to one variable, does X, two variables, does Y, nothing ? does something else yet again, channel ? Again something else and all of these are special cases in the type system (same -but not quite the same, of course- with case, channels and dicts, by the way)
Needless to say, even though you have to assign ranges to things in Go, that's the only way to use it, that assignment does something entirely different from any other assignment in Go's type system.
Go is how to make a language extremely dumb and yet make have a type system that can't be (fully) described shorter than Haskell's.
Most Go programs could have been written in Java, Scala, C# or Kotlin and been shorter, more predictable and probably faster. Certainly more maintainable (ok maybe not for Scala).
for k := range map { }
is the same thing as for k, _ := range map { }
Would requiring the second version instead of the first actually be that much of an improvement?The only true return-type polymorphism is type assertions, which is reasonable in my mind cause I don't think ignoring the "assertion failed" should ever be a logical thing to do.
1) for k := range list {}
2) for k, i := range list {}
In python, the equivalents are: 1) for x in lst:
2) for x, y in enumerate(lst):
So are these "the same" ? No. for index := range list {}
and for index, value := range list {}
Yes, these 2 version do perform very similarly, you are just ignoring the second return value in the first version, i.e.: for index, _ := range list {}I was never good at computer science-y "language theory" type stuff. I believe you when you say that Haskell or Forth are better languages - I just can't use them worth a damn.
Go is a practical language for me - it's not beautiful, or elegant, the type system is only 70% there, can be verbose, etc, etc, but it allows me to put my code in production and have a very high level of confidence that I won't get a phone call at 4 am. I don't have that confidence with Ruby, or Python, or Javascript.
I find that Go is very easy to pick up, and hard to really fuck up. Most people at my company can read my code and I can read theirs, which is mind-boggling to me. Go somehow achieved what I thought was impossible - to read and grok quickly other people's code.
Go sees was developed by "engineer" types - not "language nerds". And, yes, it shows.
FWIW, I also love Rust and C, but will choose Go over Rust any day when my productivity and dead-lines are more important than close-to-C performance.