An Honest Review of Go (2025) • Hacker News Board

Re: An Honest Review of Go (2025)

#91

Post by gen2brain » Thu, Jan 08, 2026, 5:55 PM UTC

estebank wrote: post #54

gen2brain wrote: post #47

Error 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.)

This is an older thinkpad I am using, 4 cores, 16G of ram. LLVM is now dependency you cannot get rid of. That is painfull, but in the morning, after several hours it is usually done. Rust is LLVM plus I am not sure what, really painfull. And Gentoo also forces many different arches and flags for some reason, use flags are masked, you cannot easily disable them.

Re: An Honest Review of Go (2025)

#92

Post by jdefr89 » Thu, Jan 08, 2026, 5:57 PM UTC

weitendorf wrote: post #36

I think I know why Go ended up without good enum support. (Disclaimer, formerly worked at Google and used proto/grpc/go there and now in my own startup in github.com/accretional/collector which tries to address this problem with a type registry and fully reflective API. Not privy to the full history, just reasoning.) Proto is designed so that messages can be deserialized into older/previous proto definitions by clien…

No its because 99% of the time people use enums to give names to magic constants... That is it. Go went for simplicity and const+iota achieves it just fine. People act like enums make or break software itself or something.

Re: An Honest Review of Go (2025)

#93

Post by jdefr89 » Thu, Jan 08, 2026, 5:58 PM UTC

rednafi wrote: post #51

Another tired error-handling take. It ain't pretty but it works.

It is pretty and it can do pretty much exactly what Rust enums do if they learned basic idiomatic Go.. Rust is a cult at this point honestly.

Re: An Honest Review of Go (2025)

#94

Post by osigurdson » Thu, Jan 08, 2026, 5:58 PM UTC

The way I do this is decide which language I like (just by gut feel) and then come up with reasons why it is good / better than others. I think almost everyone does the same thing, really.

Re: An Honest Review of Go (2025)

#95

Post by [deleted] » Thu, Jan 08, 2026, 6:01 PM UTC

divan wrote: post #26

> 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…

[deleted]

Re: An Honest Review of Go (2025)

#96

Post by blibble » Thu, Jan 08, 2026, 6:01 PM UTC

divan wrote: post #26

> 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…

the problem with the err != nil spam is that manual unwinding destroys useful information: the stack

that and the fact you can accidently silently ignore it without it being a compiler error

Re: An Honest Review of Go (2025)

#97

Post by weitendorf » Thu, Jan 08, 2026, 6:02 PM UTC

AnimalMuppet wrote: post #83

weitendorf wrote: post #36

I think I know why Go ended up without good enum support. (Disclaimer, formerly worked at Google and used proto/grpc/go there and now in my own startup in github.com/accretional/collector which tries to address this problem with a type registry and fully reflective API. Not privy to the full history, just reasoning.) Proto is designed so that messages can be deserialized into older/previous proto definitions by clien…

I'm not sure I understand your argument. You're saying that you can't really use enums for field numbers. And let's say that you're absolutely correct about that. It still seems to me that you're addressing a completely separate issue from having a specific field that is an enum - not an enum of a field number, but an enum of something else, like encryption algorithm or SHA type or something. Am I missing your point?

I’m pointing out that proto’s enums are wrappers around proto field numbers, which are numerical ids for proto message fields that enable forward/backward compatibility across proto message version changes. These field numbers are necessarily sparse but don’t even need to be assigned sequentially, and in fact, because of the leaked implementation details from the internal field number range you have to assume they are non-sequential. So field numbers are sparse, which makes them non-enumerable even though they’re represented with numeric tags.

Hence, proto enums are essentially non-enumerable wrappers around numeric values. And this is (almost certainly) why Golang’s enums are structured the same way, as transparent wrappers around values that are not necessarily sequential or enumerable.

Re: An Honest Review of Go (2025)

#98

Post by weitendorf » Thu, Jan 08, 2026, 6:07 PM UTC

jdefr89 wrote: post #92

weitendorf wrote: post #36

I think I know why Go ended up without good enum support. (Disclaimer, formerly worked at Google and used proto/grpc/go there and now in my own startup in github.com/accretional/collector which tries to address this problem with a type registry and fully reflective API. Not privy to the full history, just reasoning.) Proto is designed so that messages can be deserialized into older/previous proto definitions by clien…

No its because 99% of the time people use enums to give names to magic constants... That is it. Go went for simplicity and const+iota achieves it just fine. People act like enums make or break software itself or something.

That seems unlikely to me to be the actual explanation. It could very well be what you prefer or how you would do it, but I can definitely assure you that the Go/other infrastructure teams think about these problems and hear plenty of complaints about lack of union type support.

Re: An Honest Review of Go (2025)

#99

Post by jerf » Thu, Jan 08, 2026, 6:09 PM UTC

dkarl wrote: post #48

9rx wrote: post #40

Earlier 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…

Sum types can be put into 1:1 correspondence with the integers, barring the inclusion of a non-enumerable type in a language's specification that can be used in sum types. However I would observe that this is generally a parlor trick and it's fairly uncommon to simply iterate through a sum type. As is so often the case, the exceptions will leap to mind and some people are already rushing to contradict me in the replies... but they are coming to mind precisely because they are the exceptions. Yes, you can sensibly iterate on "type Color = Red | Green | Blue", I've written code to do the equivalent in various languages many times and most complicated enumerations (in the old sense) I do come equipped with some array that has all the legal values so people can iterate over them (if they are not contiguous for some reason), so I know it can be done and can be useful. But the instant you have a general number type, or goodness help you, a generalized String type, as part of your sum type, you aren't going to be iterating on all possible values. And the way in which you can put the sum types into a 1:1 correspondence won't match your intuition either, since you'll need to diagonalize on the type, otherwise any unbounded array/string will get you "stuck" on the mapping and you'll never get past it.

So while you can theoretically argue it makes sense to call them an "enum" I don't like it precisely because "enumerating" the "enum" types (being sum types here), in general, is not a sensible operation. It is sensible in specific, but that's not really all that special. We don't generally name types by what a small percentage of the instances can do or are, we name them by what all instances can do or are. A degenerate sum type "type Value = Value" is still a sum, albeit a degenerate one of "1", but nobody ever enumerates all values of "type Email = Email { username :: String, domain :: String }". (Or whatever more precise type you'd like to use there. Just the first example that came to mind.) There are also cases where you actively don't want users enumerating your sum type, e.g., some sort of token that indicates secure access to some resource that you shouldn't be able to get, even in principle, by simple enumerating across your enum.

If it's called an "enum" I want to be able to "enum"erate it.

Re: An Honest Review of Go (2025)

#100

Post by steveklabnik » Thu, Jan 08, 2026, 6:10 PM UTC

jdefr89 wrote: post #90

eximius wrote: post #4

Lack 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.

What is with people and their need for enums? Functionally using go const with iota gives you the same damn thing and people use enums that way 99% of the time. I find Rusts reliance on enums annoying as hell. At this point I consider Rust a bandwagon language. The syntax is abysmal and we have had memory safe languages far before Rust. That I wont get into because as a Vulnerability Researcher I find the Rust push s…

> What is with people and their need for enums?

I mean, you have atomic and compound data types. Atomic ones represent single values, like "a string" or "an integer", and compound ones represent multiple atomic types combined in some way, like a struct or an enum. Enums are useful for the same reason structs are useful, they do the same core thing, just model it in a different way. It's the difference between "and" and "or", which are both useful tools.