3 ms·

The entire premise of golang was that it was a "simple" language with only a few keywords and a standard that's only a few pages long. While these metrics look

The entire premise of golang was that it was a "simple" language with only a few keywords and a standard that's only a few pages long. While these metrics look good on paper, they are secondary (or even less) when it comes to real world complexity and gotchas in the language. IMO, Java, even with a longer standard, is a safer and more sane language and ecosystem to use.

mseepgood 6y ago
Almost nothing in this article is a "gotcha". It simply describes the features Go has, such as a formatter, bitwise operators, or things that Go does differently/better compared to other languages, such as strings can't be nil, break is the default in switch cases, etc. > IMO, Java, even with a longer standard, is a safer and more sane language and ecosystem to use. There's an entire book titled "Java Puzzlers".
- knorker 6y ago
  Slices are definitely full of "gotcha". As is the fact that interfaces have two types of nil, type and untyped. And the extremely leaky implementation detail of maps and slices is definitely a gotcha. Usage wise both slice and map can be nil, but map has to be make()d, for no obvious reason. The fact that the author was confused about "strings can't be nil" shows their Java experience, I think. Coming from C++ programmer I would go "well of course it can't be nil". (But slices and maps can? Wat?) Slices have another gotcha, described, where yes there are arrays, but you basically never use them. They're just a ghost that pops its head in and is the explanation for why your code that treated slices like lists/arrays failed. You're (almost) only supposed to use this leaky abstraction that'll bite you if you think your "list of items" is "a list". I say this as someone who's coded a lot of Go, and reviewed much much more: Go, like other things Rob Pike makes, only make sense and are consistent and intuitive inside his brain. They don't make objective sense. The poster child for this is "Go doesn't have exceptions". It has "unwind the stack, call cleanup code along the way, until a handler is met. If there's no handler it'll terminate the application". In Rob Pike's brain the very definition of "exception" is something completely different from "exception". Even the defense "we don't call them exceptions because they should not be used e.g. for failing to open a file!" is complete nonsense to anyone who's ever heard of C++. Yeah. File not found is not an exception in C++, what's your point? That and "well OF COURSE the go compiler for ARM is called 5g and x86 is called 6g!!!".

mseepgood 6y ago

Almost nothing in this article is a "gotcha". It simply describes the features Go has, such as a formatter, bitwise operators, or things that Go does differently/better compared to other languages, such as strings can't be nil, break is the default in switch cases, etc. > IMO, Java, even with a longer standard, is a safer and more sane language and ecosystem to use. There's an entire book titled "Java Puzzlers".

knorker 6y ago
Slices are definitely full of "gotcha". As is the fact that interfaces have two types of nil, type and untyped. And the extremely leaky implementation detail of maps and slices is definitely a gotcha. Usage wise both slice and map can be nil, but map has to be make()d, for no obvious reason. The fact that the author was confused about "strings can't be nil" shows their Java experience, I think. Coming from C++ programmer I would go "well of course it can't be nil". (But slices and maps can? Wat?) Slices have another gotcha, described, where yes there are arrays, but you basically never use them. They're just a ghost that pops its head in and is the explanation for why your code that treated slices like lists/arrays failed. You're (almost) only supposed to use this leaky abstraction that'll bite you if you think your "list of items" is "a list". I say this as someone who's coded a lot of Go, and reviewed much much more: Go, like other things Rob Pike makes, only make sense and are consistent and intuitive inside his brain. They don't make objective sense. The poster child for this is "Go doesn't have exceptions". It has "unwind the stack, call cleanup code along the way, until a handler is met. If there's no handler it'll terminate the application". In Rob Pike's brain the very definition of "exception" is something completely different from "exception". Even the defense "we don't call them exceptions because they should not be used e.g. for failing to open a file!" is complete nonsense to anyone who's ever heard of C++. Yeah. File not found is not an exception in C++, what's your point? That and "well OF COURSE the go compiler for ARM is called 5g and x86 is called 6g!!!".