Many of the criticisms listed are fair (even though quite nitpicky at times), but there are a few that I don't want to let stand unrebutted: > Because strings

Many of the criticisms listed are fair (even though quite nitpicky at times), but there are a few that I don't want to let stand unrebutted: > Because strings are just slices of bytes, there is no simple way to index or slice a string if it contains non-ASCII characters. Indexing into a UTF-8-encoded string is expensive -- O(n) instead of O(1) -- so it's good that it also looks expensive. > Despite the above, Go has two competing types for representing text, string and []byte. As has any other serious language. Byte arrays and strings are just not the same thing. My only real gripe with Go's treatment of strings is that converting from []byte to string is a simple cannot-fail cast. That should be an operation that checks for valid encoding, and returns an error otherwise, like Rust's str::from_utf8. > Deleting the nth element from a slice sure doesn't look like deletion: [code snippet] This is a fair criticism, but IMO way overblown. I cannot remember the last time I had to delete individual elements from slices. Most of the time I'm doing map() or filter(), or rather, the equivalent spelled-out for loops since Go does not have generics. > If you import a library or declare a variable, but do not use it, your program will not compile even if everything else is valid. And that's great. I don't want old libraries bloating my program needlessly. It's sometimes a bit annoying to have to write _ = foo into unfinished functions because otherwise it will not compile due to "error: foo is never used", but I like my compilers strict. Also to this point: You can set up your editor to run your code through goimports automatically, which will completely do all the adding, removing and ordering of imports for you, as well as format your code according to the standard style. More languages need this. > If multiple channels are available to receive from or send to, the select statement picks a case at random, meaning that to prioritize one channel over another you have to write: [lengthy code snippet] Having to prioritize channels manually is a bit of a code smell in my opinion. I would need a real-world example to judge, but it smells like the real problem is how you slice up your work into goroutines. > Two implementations of random numbers, math/rand and crypto/rand. Again, this is completely standard for any serious language. For mathematical simulations, you don't care about cryptographic properties of your RNG and want the extra speed that a simpler RNG like a Mersenne twister gives you. > The errors package is twenty lines long, because Go's error type is simply an interface to a function returning a string. You forgot the criticism here. > Go's native package system does not support X All of these are wrong. Go has added a proper native package system in 1.11. > The contributors don't listen to the community. One of the two examples shows that the contributors do listen. > Almost nothing in this list can be fixed, because of the Go 1 compatibility promise. Until Go 2.0, that is, but that may never happen. That's the problem with crystal balls.