4 ms·
Having worked on several large golang code bases, its verbosity is tedious to deal with. It doesn't lend well to IDEs (e.g. it's so easy for a struct to acciden
by gher-shyu3i 6y ago
Having worked on several large golang code bases, its verbosity is tedious to deal with. It doesn't lend well to IDEs (e.g. it's so easy for a struct to accidentally implement interfaces it doesn't mean to because of structural typing). Error handling is always a mess, it doesn't have enums, and so many issues to list here that Java doesn't have.
The golang authors' weird obsession with not having any methods on strings for example, makes it horrendous to work with them (e.g. can't chain someString.trim().toUpper().endsWith("...")).
Don't get me started on the supposed fast compile times. Parsing is fast (but so almost any other language that is not C++ or Scala), but linking is horrendously slow. Modifying and re-running individual unit tests takes seconds at a time due to relinking. In Java, it's in a blink of an eye because there is no linking.
- BobbyJo 6y agoHaving to use functions on built in types like strings.HasSuffix(strings.ToUpper(...)) isn't that bad to me. If I'm chaining a bunch of function calls on a single string, I'll want to separate them on different lines for readability anyway. It'll be creating and destroying a few implicit copies either way, so I have never really felt any pain from that. Java has no linking, but you have to go through the JVM. Golang produces native binaries. Not really a fair comparison. That being said, my brain is normally a way larger bottle neck than linking time for unit tests. I'll cede the gripes with enums and error handling (although I hated the way Java exceptions always ended up way too overloaded way more), but I find the typing a really good balance between strong and weak. It's strong enough that you have to be doing something really weird to mess up, but weak enough to be flexible.