4 ms·
Go is insanely verbose compared to both C# and Java due to its low expressivity, especially around its error “handling”.
by kaba0 3y ago
Go is insanely verbose compared to both C# and Java due to its low expressivity, especially around its error “handling”.
- imiric 3y agoI think you're confusing Go's simplicity and explicitness with verbosity. Yes, it won't help you write the least amount of code, but this forces you to write readable code and avoid cleverness, which is almost always a good thing. Its error handling is an exhausted topic, but avoiding exceptions and being forced to decide how to handle errors where they happen is also a good thing IMO. On the other hand, I would absolutely use verbose to describe both C# and Java. They are huge languages, with many features, a complex syntax, and conventions and patterns that lead to writing a lot of hard to understand code. I'd use Go over both of them any day, especially when it comes to writing cross-platform GUI or console apps that can be quickly compiled and easily distributed. Other options to consider might be Nim or Zig, but these are not as mature as Go.
- kaba0 3y ago> I think you're confusing Go's simplicity and explicitness with verbosity I think those are quite innately related, yes. But I believe you also mix verbosity up in your very next sentence, for what it’s worth — readable, maintainable code is not as close a concept. In fact, certain type of verbosity helps readability, e.g. I argue that Go’s identifier capitalization harms readability, and marking it at a single place by public/private is much better, at a tiny price of more verbosity. “Clever” code is another topic, there is definitely overly clever code, which is a net negative, but in this particular comparison, is a hand-written, 3-times nested for loop with any number of side effecting statements more clear to read than the “smart” stream/linq expression? I would argue the latter is much more readable and maintainable. For another, even better example there is that math proof, which can be done an order of magnitude faster by choosing a clever notation, but I can’t look up its name yet. Re error handling, no, go doesn’t force you to handle the errors. It forces you to do some stupid meaningless if err ritual, that won’t result in correct handling of the error case, and will in fact often swallow errors. Java’s checked exception does force you to correctly handle it, though, but even runtime exceptions at least bubble up, making the default action (doing nothing) correct.