Go is a terrible language (2020)(debugged.it)
debugged.it
Go is a terrible language (2020)
https://debugged.it/blog/go-is-terrible/
66 comments
Not top 5 languages, but Scala & Rust fit the bill.
Kotlin as well. The result type is "String?".
Even JavaScript does, with strictest TypeScript settings (not on Exceptions though). When I returned to a Java project recently, the lack of null safety was seriously off-putting. It does indeed feel like the "billion-dollar mistake" of programming.
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 - https://debugged.it/blog/20000-lines-under-the-go-cean/ .
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!
I write both Go and JavaScript.
> If error isn’t typed it’s no different from “anything can throw anything anywhere in the stack”.
Errors aren't untyped. It's an interface type. Not everything returns errors anyway, they definitely can't be returned from anywhere in the stack.
Errors in Go are definitely nowhere near as amorphous as those in JS. In JS, you can take an Error object and stick additional properties on it, and then throw that. In fact, Node does that, and by extension, thousands of JS libraries generate exceptions like that.
With Go, you use errors.As(), or errors.Is(), or a little bit of dynamic casting. The type of error which a function returns may not be part of its type signature, but decent libraries usually have only one or two error types they return. Yes, I hit F12 to see the library's source to see what errors it returns... but that's just because the IDE experience with Go is so fast and nice to use.
> If error isn’t typed it’s no different from “anything can throw anything anywhere in the stack”.
Errors aren't untyped. It's an interface type. Not everything returns errors anyway, they definitely can't be returned from anywhere in the stack.
Errors in Go are definitely nowhere near as amorphous as those in JS. In JS, you can take an Error object and stick additional properties on it, and then throw that. In fact, Node does that, and by extension, thousands of JS libraries generate exceptions like that.
With Go, you use errors.As(), or errors.Is(), or a little bit of dynamic casting. The type of error which a function returns may not be part of its type signature, but decent libraries usually have only one or two error types they return. Yes, I hit F12 to see the library's source to see what errors it returns... but that's just because the IDE experience with Go is so fast and nice to use.
The article talks about returning strings as errors, which I read as equivalent to (JS):
And by not typed, I specifically meant in the function signature. If tooling helps with that, that’s awesome.
throw 'wat'
And by not typed, I specifically meant in the function signature. If tooling helps with that, that’s awesome.
I would suggest giving Go a chance, or at least take articles like these with a grain of salt.
Sure, Go allows you to create an error with nothing but a string message inside. The equivalent JS is something like
> Which doesn’t seem like a very useful interface to me. Everything can be stringly typed. But again I’m looking at this from the outside.
What’s happening here is that your function is returning an error, but in such a way that you can’t identify that specific error from its value. If you’re a library author, you use this in two scenarios:
1. You can’t imagine a way that this specific error could be handled by the caller. (It doesn’t need a special type, because nobody will be checking for it.)
2. You expect all errors from your function to be handled the same way. (It doesn't need a special type, because you already know what to do with it.)
The way you handle errors in Go is actually quite rich, seems like it just doesn’t jive with the author’s personal preferences. Or possibly the author is using terrible libraries. Or possibly the author really hates boilerplate code (the author's complaining about “tons” of boilerplate code, but it doesn’t look like much boilerplate code to me).
If anything, my experience handling Go errors is that you might end up with rather complex error objects, with errors nested inside of other errors, multiple levels deep. You can extract a ton of information from these objects—like if there’s an I/O error, you’ll know what operation failed and the path of the file, and then inside you’ll find the wrapped I/O error without that information.
Sure, Go allows you to create an error with nothing but a string message inside. The equivalent JS is something like
throw Error('wat');
> Which doesn’t seem like a very useful interface to me. Everything can be stringly typed. But again I’m looking at this from the outside.
What’s happening here is that your function is returning an error, but in such a way that you can’t identify that specific error from its value. If you’re a library author, you use this in two scenarios:
1. You can’t imagine a way that this specific error could be handled by the caller. (It doesn’t need a special type, because nobody will be checking for it.)
2. You expect all errors from your function to be handled the same way. (It doesn't need a special type, because you already know what to do with it.)
The way you handle errors in Go is actually quite rich, seems like it just doesn’t jive with the author’s personal preferences. Or possibly the author is using terrible libraries. Or possibly the author really hates boilerplate code (the author's complaining about “tons” of boilerplate code, but it doesn’t look like much boilerplate code to me).
If anything, my experience handling Go errors is that you might end up with rather complex error objects, with errors nested inside of other errors, multiple levels deep. You can extract a ton of information from these objects—like if there’s an I/O error, you’ll know what operation failed and the path of the file, and then inside you’ll find the wrapped I/O error without that information.
[deleted]
It's just an improvement on error handling in C without introducing heavyweight exceptions.
They did introduce panic, they just discourage anyone outside the language design team from taking advantage of it. I find "better than C" to be a pretty disappointing target.
> They did introduce panic, they just discourage anyone outside the language design team from taking advantage of it.
The guidance I remember when I was trying out go and researching idiomatic Go style was not “don’t use panic in your code” but “don’t expose panics [other than the ‘always and everytime fatal’ kind] across the public API surface of your code”.
Basically, if someone other than the code owner would want to react to it, it should be converted to an error return before hitting the code consuming your library.
The guidance I remember when I was trying out go and researching idiomatic Go style was not “don’t use panic in your code” but “don’t expose panics [other than the ‘always and everytime fatal’ kind] across the public API surface of your code”.
Basically, if someone other than the code owner would want to react to it, it should be converted to an error return before hitting the code consuming your library.
This is my understanding too, and when I’ve seen panic I always see it treated as fatal/terminating.
> ...functions don't declare what kind of errors they return.
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.
https://www.artima.com/articles/the-trouble-with-checked-exc...
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.
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.
https://www.artima.com/articles/the-trouble-with-checked-exc...
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.
It's a pain because it forces users to consider and code against error paths.
Just like putting on a seat belt is a pain.
Both are pains that are worth having because they help you create robust software.
The ways in which a function can fail should absolutely be part of its signature, and if these are recoverable, the compiler should refuse to build until you either handle these errors or pass them on to the caller.
Just like putting on a seat belt is a pain.
Both are pains that are worth having because they help you create robust software.
The ways in which a function can fail should absolutely be part of its signature, and if these are recoverable, the compiler should refuse to build until you either handle these errors or pass them on to the caller.
> The ways in which a function can fail should absolutely be part of its signature
The problem with that is that a downstream library gets welded to the specific errors it can throw and can't evolve.
So, what everybody will do is generate the most generic "Error" possible so that the signature never needs to change. That is NOT an improvement.
The problem with that is that a downstream library gets welded to the specific errors it can throw and can't evolve.
So, what everybody will do is generate the most generic "Error" possible so that the signature never needs to change. That is NOT an improvement.
I think there's a nice middle ground. For instance, in Swift a function can indicate that it throws, which is better than nothing.
func canThrowErrors() throws -> String
func cannotThrowErrors() -> StringThis 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.
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.
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.
follow-up post : https://debugged.it/blog/20000-lines-under-the-go-cean/
[deleted]
Thanks for sharing this. It's very hard to lend credence to this series after reading this follow-up. Quoting from the link:
"There are certainly many reasons to hate Go, from the unusual syntax to the half-arsed way they decided to implement the programming model. On the other hand you can go all fanboy over how cool Go is because it makes it so simple to write microservices. (No, it doesn’t. It really, really doesn’t if you want to do it properly.)
If you jumped on either of these bandwagons, I would recommend getting off as soon as possible. Neither of these approaches are very professional and are telling signs of inexperience in software development."
There is an upsetting level of hypocrisy in patronizing your readers for consuming the clickbait-titled articles _you authored_.
"There are certainly many reasons to hate Go, from the unusual syntax to the half-arsed way they decided to implement the programming model. On the other hand you can go all fanboy over how cool Go is because it makes it so simple to write microservices. (No, it doesn’t. It really, really doesn’t if you want to do it properly.)
If you jumped on either of these bandwagons, I would recommend getting off as soon as possible. Neither of these approaches are very professional and are telling signs of inexperience in software development."
There is an upsetting level of hypocrisy in patronizing your readers for consuming the clickbait-titled articles _you authored_.
Most applications I tend to see don’t even use concurrency because they are so small and simple that they don’t need it.
Having once replaced a sixteen core go program with a single-process perl script that completed the same task 4x faster, I think remembering that a lot of the time we (as a profession) manage to overengineer things is worthwhile.
> However, the larger problem is that functions don’t declare what kinds of errors they return.
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.
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.
IMO this is a common failure in discussions about programming languages today. You really must consider the capabilities of "external" language tools (linters, static analysis, etc).
Not having all that in the core language can be a reasonable design choice.
Not having all that in the core language can be a reasonable design choice.
It does depend somewhat on the quality and unanimity of those tools. Back when I did python there really wasn’t a consensus, well developed set of static analysis tools in order to answer these questions. This made programming python harder than it should’ve been, and the process of building those consensus tools was unnecessarily messy, and probably cost python more devs than need be
Not having it in the core language can be a reasonable choice, but you still need to do community work to ensure that those needs are met somehow
Not having it in the core language can be a reasonable choice, but you still need to do community work to ensure that those needs are met somehow
So the general complaints of the article is that go isn’t Java?
Seems a little more thoughtful and extensive than that, e.g. the Nullability section. AFAIK that’s not properly solved in Java either.
Also I’m guessing the section on immutability isn’t referencing something special in Java, dunno.
Also I’m guessing the section on immutability isn’t referencing something special in Java, dunno.
More like Kotlin, as nil problem exists in Java, but not in Kotlin.
@dang will HN ever support code blocks in comments? pls.
You can get fixed formatting by newline + indenting 2 spaces, similar to non-GitHub markdown
https://news.ycombinator.com/formatdoc
# Like this
y = mx + b
https://news.ycombinator.com/formatdoc
Indent 4 spaces, you’ll get monospace. Not syntax highlighted but I doubt you’ll ever see that here.
Nitpicking: 2 spaces for HN, and 4 spaces for GitHub.
Fair nitpick! I always use 4 where I know indentation works, just to be safe.
I am an amateur dev (for 25 years), using mostly Python. I was blackmailed by a friend to try Go.
Boilerplate, no exceptions, slices, ... all felt terrible.
And then I started to appreciate the typing and the fact that I had to give some thought about where to actually handle errors.
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).
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.
Boilerplate, no exceptions, slices, ... all felt terrible.
And then I started to appreciate the typing and the fact that I had to give some thought about where to actually handle errors.
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).
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: https://debugged.it/blog/20000-lines-under-the-go-cean
(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 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:
https://golang.org/doc/faq#exceptions https://go.dev/blog/errors-are-values
https://golang.org/doc/faq#exceptions https://go.dev/blog/errors-are-values
There is one more reason. When you write something that works in a loop, e.g. web server, exceptions are a huge potential issue. I was working on a C++ project with a very complex state machine. One day our service started using all 128 CPU cores just for stack unwinding. It was an ordinary exception in 3thrd party library raised on every request in the loop. We have tried to make a lot of optimisations in different unwind libraries. But it was far away from the performance of a simple Optional-like errors container as a return value. Exceptions are really Zero-cost if they occur only once when application should be terminated.
The language is rough but the performance, tools, and deployment is top notch. That dichotomy was quite surprising to me.
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.
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.
The thing with Go is that I find the syntax very ugly to look at however it is so convenient to install, run, deploy, make performant applications.
I'm not a Go fan but the language to me looks very readable and clean. However in my opinion syntax is usually not that important, you can and will get used to anything
The thing that gets me is how time is handled, enums, no sets, no way to make variables final, the "make" syntax, could probably go on
why do you find it ugly?
An example :
Edit 2 : Fixed the formatting issue.
for _, a := range albums {
if a.ID == id {
c.IndentedJSON(http.StatusOK, a)
return
}
}
for a in albums:
if a.ID == id:
// the rest of the code
albums = append(albums, newAlbum)
albums.append(newAlbum)
Edit 2 : Fixed the formatting issue.
Yeah, I find the “xs = append(xs, x)”, or for concat, “xs = append(xs, ys...)” supremely ugly. Or, its time module: you can write 3 * time.Second, which is reasonable enough, but when you have a variable instead of constant literal, you need to write time.Duration(x) * time.Second — entire expression represents the time interval of 3 seconds, but the “time.Duration(x)” component of it makes no sense at all in isolation - it’s just horrible API design. Also, its time zone API is atrocious too: it doesn’t distinguish absolute timestamps from local (wall clock) time on the type level.
Saddest part is that it’s actually pretty good language at getting things done, you just have to hold your nose and pretend it was invented in early 1980s, before the industry figured out good, clean solutions to many problems, and converged on them. Otherwise, to think that someone thought nil (that is, not empty) arrays, or returning value/error as pair instead of tagged result union, or lack of generics, is a good idea on 2000s, is just unconscionable.
Saddest part is that it’s actually pretty good language at getting things done, you just have to hold your nose and pretend it was invented in early 1980s, before the industry figured out good, clean solutions to many problems, and converged on them. Otherwise, to think that someone thought nil (that is, not empty) arrays, or returning value/error as pair instead of tagged result union, or lack of generics, is a good idea on 2000s, is just unconscionable.
https://news.ycombinator.com/newsfaq.html:
Text after a blank line that is indented by two or more spaces is reproduced verbatim. (This is intended for code.)
What kind of formatting can you use in comments?
http://news.ycombinator.com/formatdoc
Text after a blank line that is indented by two or more spaces is reproduced verbatim. (This is intended for code.)
Superficial. You prefer no braces, no underscores, and no colon. Typing is cheap. I don't mind 'em. Your second example has more implied than syntactical gripes.
albums = append(albums, newAlbum)
Correct, they were asked their opinion about why they think it's ugly, they gave it
True. I seemed to have missed that and came off a tad rude doing so. Part of my opinion is now in the mix. :-)
> implies immutability.
Except that implication is incorrect -- slices are mutable.
Except that implication is incorrect -- slices are mutable.
One for me is the "if err" everywhere lol, but i like how it has great ecosystem like nodejs
I have mixed feelings about the error handling.
It is kind of boilerplatey, but I find myself stopping to consider how best to manage an error vs languages with exceptions.
It is kind of boilerplatey, but I find myself stopping to consider how best to manage an error vs languages with exceptions.
Try Result + combinators + ? operator.
https://learning-rust.github.io/docs/e6.combinators.html
https://learning-rust.github.io/docs/e5.error_and_none_propa...
https://learning-rust.github.io/docs/e6.combinators.html
https://learning-rust.github.io/docs/e5.error_and_none_propa...
I find the ecosystem lacking. The Go community seems to have settled on "Use the standard library" which is pretty unsatisfying unless you're engaged in a specific range of web-related tasks.
Edit: I left out "engaged in" previously.
Edit: I left out "engaged in" previously.
Is there possibility that go adds algebraic datatype and pattern matching? error handling will be nicer that way generally.
Go is an ugly language. Practical but ugly.
No way, Go is beautiful based on this 1 metric: It always looked the same regardless who wrote it.
It makes PR review job so much easier, and to me, that's beautiful.
It makes PR review job so much easier, and to me, that's beautiful.
You're wasting your experts' time if they cannot write (or reread) clearer, more concise code than your beginners.
> It always looked the same regardless who wrote it.
This is Go's biggest anti-feature to me. I can't stand that all code in Go is so similar.
This is Go's biggest anti-feature to me. I can't stand that all code in Go is so similar.
Ease of reading is a practical feature not a beautiful one. If you think practicality is beautiful well great.
Have you debugged.it ?
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.
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 ?
No, it doesn't get any better when the codebase is bigger. The way to figure out WTF went wrong in a large code base written in Go is:
1. Take the line number where the error was logged, likely somewhere very close to e.g. the main event handling loop, and completely disconnected from the place where the error was initially thrown. There is no stack trace.
2. Try to figure out which parts of the error string are constant (i.e. searchable), and pray for the developer to have been familiar with the issue so that the string is globally unique (corollary: When writing Go, make sure your error strings are unique, introduce some form of variation if you're throwing similar errors, even if it's just punctuation or synonyms, to make sure the throw site is identifiable).
3. Try to guess what the flow between those two sites could have been.
The lack of proper stack traces (or even the line number where the error was thrown) on errors is one of the most insane effects of this error handling approach. (The other is hard to read code because the actual logic is hidden in 3x as much error handling boilerplate).
1. Take the line number where the error was logged, likely somewhere very close to e.g. the main event handling loop, and completely disconnected from the place where the error was initially thrown. There is no stack trace.
2. Try to figure out which parts of the error string are constant (i.e. searchable), and pray for the developer to have been familiar with the issue so that the string is globally unique (corollary: When writing Go, make sure your error strings are unique, introduce some form of variation if you're throwing similar errors, even if it's just punctuation or synonyms, to make sure the throw site is identifiable).
3. Try to guess what the flow between those two sites could have been.
The lack of proper stack traces (or even the line number where the error was thrown) on errors is one of the most insane effects of this error handling approach. (The other is hard to read code because the actual logic is hidden in 3x as much error handling boilerplate).
I’m not sure if I buy that. Did you read the article? The author is expressing explicitly what’s wrong in many areas and why they’re useful. I don’t like rebuttals like this because it then becomes a self-fulfilling prophecy of Go-lovers avoiding criticism from outside because “They won’t get it due to their background”. Great, now we’ve just created an echo-chamber. It’s good to get outside perspective and debate. I’m sure many Go experts would like to understand where they could improve - without losing Go’s core minimalism.
Author’s tone could be better but they’re just being straightforward that they don’t like Go and specifically why. Totally ok in my view.
Author’s tone could be better but they’re just being straightforward that they don’t like Go and specifically why. Totally ok in my view.
I think this criticism is very unfair, if there is one thing java is (in)famous for, its large codebases. Kafka is written in it. I myself don't use it, but you need to substantiate your argument.
Is there any reason you believe python and java are 'very problematic"? Isnt every language promlematic in its own way? Are they more problematic than C, which breeds foodguns, or what are we comparing to?
Is there any reason you believe python and java are 'very problematic"? Isnt every language promlematic in its own way? Are they more problematic than C, which breeds foodguns, or what are we comparing to?
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)