The worst problem with almost all popular programming languages are null and shitty error handling, such that, when you call foo() where foo is String foo(){ blabla } you can get a String, null OR an exception/hidden error response, but most compilers happily let you treat it as if it only ever returns a String. (What!!!?)<p>I hope some day null is no longer a thing, and that Functional Programming types like Option, Either, Try etc in the native libraries is the new default. (BTW, there's really nothing "Functional Programming" about them, they're just objects like any other in "Object Oriented" languages)
This article is a poor choice for submission. He did a companion article that is the exact opposite, and a follow-up article a year later. The follow-up would be a much better choice. It gives links to both prior articles and his thoughts after a year of reflection - <a href="https://debugged.it/blog/20000-lines-under-the-go-cean/" rel="nofollow">https://debugged.it/blog/20000-lines-under-the-go-cean/</a> .
I’ve never written a line of Go, though I’ve read a fair bit. I was expecting to object to the criticism of its error handling but I ultimately agree. If you can return and ignore an error, that’s another way of saying throw/raise. If error isn’t typed it’s no different from “anything can throw anything anywhere in the stack”. I had thought, not paying much attention to Go in particular, it must deal with this with something like an Either type. Even some language facilities to automatically unwrap Either and rewrap for callers if unhandled would be a great answer to the checked exceptions debate. But what I take away from this is errors in Go are just as amorphous as in JS but harder to find. That’s quite a feat!
> ...functions don't declare what kind of errors they return.<p>We've gone down this route with Java and my conclusion is that declaring the kind of errors a function returns is, for most users, just a pain.<p><a href="https://www.artima.com/articles/the-trouble-with-checked-exceptions" rel="nofollow">https://www.artima.com/articles/the-trouble-with-checked-exc...</a><p>My experience with Go is that decent libraries only have a small number of error return types, and then forward or wrap errors from libraries that they use. You can use errors.Is(), errors.As(), errors.Unwrap() to figure things out as necessary.
This post should not have been flagged. It is a completely valid criticism of Go. Author's tone could have been better but I'd rather hear straightforward opinions and not polished speech to offend those that cannot defend Go. Personally, I am a huge fan of Go but these are some valid points.<p>Anyone supporting such flagging behavior is completely against the spirit of what made this place great. Please reconsider your actions and what flagging does on HN.
> However, the larger problem is that functions don’t declare what kinds of errors they return.<p>They don’t need to. Static analysis (guru) can answer the question “what kinds of error can this error be?” There’s no need to go source diving as the author suggests.
I am an amateur dev (for 25 years), using mostly Python. I was blackmailed by a friend to try Go.<p>Boilerplate, no exceptions, slices, ... all felt terrible.<p>And then I started to appreciate the typing and the fact that I had to give some thought about where to actually handle errors.<p>I know kinda like Go, except for the weird way maps are handled, and the lack of types in errors (compared to Python where it is fantastic).<p>There are certainly pros and cons (I am not a good enough developer to have advanced thoughts on that) but the cross compilation makes a lot of things easier when deploying self-contained executables.
Make sure you read the OP's follow-up before cargo-culting on the "Golang bad" ship: <a href="https://debugged.it/blog/20000-lines-under-the-go-cean" rel="nofollow">https://debugged.it/blog/20000-lines-under-the-go-cean</a><p>(I actually quite like Go, despite it being more difficult to write tests for than other languages, and error messages usually being very cryptic.)
I don't love that Go doesn't have exceptions. But it was a choice made thoughtfully:<p><a href="https://golang.org/doc/faq#exceptions" rel="nofollow">https://golang.org/doc/faq#exceptions</a>
<a href="https://go.dev/blog/errors-are-values" rel="nofollow">https://go.dev/blog/errors-are-values</a>
The language is rough but the performance, tools, and deployment is top notch. That dichotomy was quite surprising to me.<p>If someone could write a "coffeescript" for it, perhaps a python+pascal love-child, while keeping the fantastic lower-level parts of go, I'd be all over it.
The last two companies I have been at switches from other languages to Go. At this point I don't see what people like about Go. This article touches on problems, but it is only the tip of the iceberg.
<p><pre><code> Have you debugged.it ?
</code></pre>
Debugging seems to be the author's coding philosophy which says it all.<p><pre><code> While I had over a decade of experience in other languages, such as Python, PHP, Java, etc.
I found it extremely difficult to wrap my head around Go.
</code></pre>
This could be because the author's introduction to programming and most of their experience has been with some very problematic languages.<p>Maybe it's not Go that is a terrible language but just that the author is not a systems programmer who has worked with large code bases ?