The reasons why Golang is a bad language, according to my friend | Hacker News Reader

The reasons why Golang is a bad language, according to my friend

gist.github.com

6 pointsavestura3 comments

It has been fashionable since 1992 to complain about OO programming and around that time hate for exceptions started to grow. Half of it was that exceptions had a broken implementation in C++, half of it was a reflexive rejection of anything having to do with Java. (Is it a lost opportunity that they didn’t fill Java up with really bad ideas to get them rejected by the community.)

In the 1980s I remember looking at good C code and thinking, gee, correct error handling bloats code by 2x or 3x and it is not the ceremony and superfluous agreement of Java which the compiler helps you maintain but instead it is devilishly complex and any mistake in it is likely to go untested. (e.g. and if you did actually write automated tests again you’d probably have to 2x or 3x the code again to get in mocks.)

I had an engineering manager who thought error handling in Scala was great with monads and also boasted that his team did rigorous code reviews but when I got my hands in the code I found it was like bad C code from the 1980s, the facilities to do error handling were there but people weren’t using them. Errors just got ignored, so our data analytics system would just give wrong answers.

Exceptions, in the other hand, do something sane automatically and don’t make your code unmaintainable by building an elaborate error handling machine that is closely interspersed with your code. It is such a terrible step backwards to give up on exceptions.

Nice writeup, the IT industry is fashion driven for at least 2 decades now, and in the echo chamber of the internet bullshit like 'exceptions == bad' are repeated w/o any real world experience.

Checked exceptions in Java are an excellent example: They make total sense, once a more complicated program gets developed. Not that I love them, but I don't know of a better way to solve the problem of exceptions/errors when one cannot simply restart a process w/o problems. Checked exceptions are brilliant for showing the developer, where error handling needs to go. (IOException in my business domain? Doesn't look right, how can I solve it?)

The other thing which really annoys the hell out of me in the criticism of Golang is, that most people don't understand that Golang is part of a bigger system/approach to software development and complexity. Again, Golang makes much more sense for real world software which has to be maintained over a decade, than comparing a feature to another languages feature. Real world software is not written in a language, but on a platform consisting of standard libraries, documentation, a community and idioms. The Go community succeeded here in an impressive way, especially compared to other communities which are more concerned about ideology/politics/holier than thou RUST.

Funnily enough, exceptions is the one thing which I really miss in Golang, but I am afraid they will never be added.

There is more to the design space here than "exceptions vs 2x bloat." For example, Rust shares Go's "errors as values, no exceptions" philosophy, but has significant syntax sugar to reduce the bloat at the site where the error is handled. I'm sure there are also other spots in the design space to consider.

(I do not think that this means Go (from the title) or C (from your example) is a bad language. All I mean to say is that the design space has multiple different possible designs, not just two.)

Reply on news.ycombinator.com