Another tired error-handling take. It ain't pretty but it works.
An Honest Review of Go (2025)
51–60 of 184 posts
Re: An Honest Review of Go (2025)
#52I'd encourage the author to spend more time learning Go. They've come to incorrect conclusions -- especially regarding errors. Read more of the stdlib to see how powerful they can be, e.g. net.OpError: https://cs.opensource.google/go/go/+/refs/tags/go1.25.5:src/... > The user now has an interface value error that the only thing > they can do is access the string representation of ... The only > resort the consumer of…
I use Go as my preferred language and I think the author is mostly right.
There’s no way for me to know or even check what are the possible errors this function can return? Sure, sometimes a comment in the library might be illuminating, but sometimes not.
I agree that errors as values that I can handle at the call site rarely feel useful.
Some of the Is, As ergonomics have improved, but damn if coding agents don’t love to just fmt.error any code it writes. Thus hiding the useful information about the error in a string.
Re: An Honest Review of Go (2025)
#53Earlier quoted context omitted.
"Enum" is literally defined as a numbering mechanism. While integers are the most natural type used to store numbers, you could represent those numbers as strings if you really wanted. The key takeaway is that a enum is a value , not a type. The type the link was struggling to speak of seems to be a tagged union. Often tagged union implementations use enums to generate the tag value, which seems to be the source of c…
It feels obvious that that's where the term originated, but I've never seen it used as a definition. In a mathematical context, something is enumerable if it can be put into 1:1 correspondence with the integers, but it doesn't need to be defined by a canonical correspondence. This suggests that being a finite (in a programming context where the set of ints is finite) set of discrete values is the defining feature, no…
> In most applications of int enums, the particular integers can be chosen at random
I’m not sure the definition of "enum" enforces how things are identified. Random choice would be as good as any other, theoretically. In practice, as it relates to programming, random choice is harder to implement due to collision possibilities. Much simpler is to simply increment an integer, which is how every language I've ever used does it; even Rust, whose implementation is very similar to Go's implementation.
But it remains that the key takeaway is that the enum is a value. The whole reason for using an enum is for the sake of runtime comparison. It wouldn't even make sense to be a type as it is often used. It is bizarre that it keeps getting called one.
Re: An Honest Review of Go (2025)
#54Error handling in Go is actually very nice. You do not have unhandled errors, not possible unless you really want to not handle the error. Now I even use it similar in Python, amazing how many errors I did not handle at all. But what got me into using Go is that there is no libc dependency, just system calls, static binary, that is just amazing. I can compile Go compiler in like few minutes. Rust I cannot even compil…
> Rust I cannot even compile after 24h
Could I ask what hardware this is on? Even when building LLVM from scratch too as part of building the toolchain (which hasn't been the default for a while now, but could see Gentoo doing so), it never took that long on any hardware I own. (Granted, I never tried on the EEE PC I've got on some drawer, and its 2G of RAM would likely kill the whole thing before it got started.)
Re: An Honest Review of Go (2025)
#55> difficulty of writing if err != nil Literally the simplest way to deal with errors (cognitively and character wise). Since AI autocomplete entered the scene, typing this repetitive (for a reason) pattern became not a problem at all (I'm not even talking about post Claude Code era) > The only resort the consumer of this library has is to parse the string value of this error for useful information. Well, no. See for…
> typing this repetitive (for a reason) pattern became not a problem at all
Code is read 10x more than it is written. The noise this pattern introduces inhibits reading and rapid comprehension.
Things are getting marginally better now that go has errors.Is and errors.As, and also now that go is starting to get some functional iterators. But go is one of the least quickly-understandable of the modern languages currently in use.
Re: An Honest Review of Go (2025)
#56Lack of enums are the main point for me. The error story is not ideal but less bad than that most of the time, as you can downcast to access extra error data. Still, harder than it needs to be. Overall, I've grown to like using the language even despite its warts.
It doesn’t have the enum keyword, but there is an idiomatic way to make enums in the language. They just end up being typed constants.
When people say they want sum types, they generally mean they want both sum types and exhaustive pattern matching. Either of these features on isolation are nice to have, but both together are incredibly powerful to the point where having just one is almost not worth it.
Re: An Honest Review of Go (2025)
#57[deleted]
Re: An Honest Review of Go (2025)
#58> difficulty of writing if err != nil Literally the simplest way to deal with errors (cognitively and character wise). Since AI autocomplete entered the scene, typing this repetitive (for a reason) pattern became not a problem at all (I'm not even talking about post Claude Code era) > The only resort the consumer of this library has is to parse the string value of this error for useful information. Well, no. See for…
To be fair, the author says it's the "_supposed_ difficulty of writing err != nil" and says that the verbosity isn't an issue here. But he also earlier says that he "[hates] having to write pub all the time in Rust" to denote public visibilities. So typing seven extra characters in one place = tolerable, but four extra characters elsewhere = detestable
Re: An Honest Review of Go (2025)
#59I'd encourage the author to spend more time learning Go. They've come to incorrect conclusions -- especially regarding errors. Read more of the stdlib to see how powerful they can be, e.g. net.OpError: https://cs.opensource.google/go/go/+/refs/tags/go1.25.5:src/... > The user now has an interface value error that the only thing > they can do is access the string representation of ... The only > resort the consumer of…
They are an improvement over most languages, but the are _not_ better than sum types for the reasons listed above. Way less flexible and forces a lot more verbosity when compared to more functional languages.
Hes definitely wrong on how the error types can help account for that but it would be best in class if we could properly chain them AND use all the greatness from interfaces.
Re: An Honest Review of Go (2025)
#60I commend Go for popularizing the channel-based concurrency, since I do think that that is a very elegant way of structuring stuff (especially compared to mutexes), but I have to admit that I don’t have a lot of fun writing Go. I agree with a lot of the sentiment of this post; the weirdness with “tuples”, the weirdness of the error types, and etc. It’s not a “bad” language, just one that I don’t enjoy using. Historic…
IMO, this is because Go succeeded at its intended to goal: to create a language that people with very little Computer Science (but some C/C++ programming) experience can be productive in. It eschews basically all abstractions that take more than 30s to explain to someone, which leaves a lot of really useful ones on the cutting room floor.
That’s fair. I came into Go relatively late and from a more Functional Programming background, so the language ends up being kind of annoying to me but that is probably not the case for others.