Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Honest Review of Go (2025)

benraz.dev

Post reply on HN
Print view View original

141–150 of 184 posts

Re: An Honest Review of Go (2025)

#141

Post by estebank »

MobiusHorizons wrote: post #138
estebank wrote: post #56

Earlier quoted context omitted.

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.

Is this what people mean by Enums? I must not have used languages where Enums have those powers. I have often been very confused by statements people make about Enums so that would make some sense. How do sum types address the problem that the underlying type (int or string or whatever) is totally capable of describing values other than those your code was compiled with? I'm mostly thinking of version skew with somet…

Yes, this is generally what people mean when they talk about enums in modern languages.

The in memory and ABI representation of enums/sum types is language dependent.

In Rust, an enum is equivalent to a C union where there's a discriminant value which is an integer of sufficient size to cover all variants (u8 is sufficient for 255 different variants), followed by as many bytes as the largest variant (a tagged union). Mucking around with the underlying bytes to change the discriminant and cause type confusion is UB. All the same strategies you'd take in C for versioning and ensure binary backwards compatibility would apply. When exposing these you would likely want a higher level abstraction/self-describing wire format, if you don't have control over both sides of the ABI boundary.

Other higher level languages do this for you already. I believe Swift is one of those, where it has a COM-like ABI layer that the compiler makes injects transparently to correctly interact with a dynamic library, handling versioning for you.

I am of the opinion that we need a new attempt at a multi-platform, language-agnostic, self-describing ABI, "COM for the modern world". I think some people have talked about using WASM for this.

Keep in mind that the concept (pattern matching, sum types) is not tied to how they are represented (Scala has both, but they are represented different to what I described earlier; IIRC it uses inheritance to represent the variants).

Re: An Honest Review of Go (2025)

#142

Post by benrazdev »

jacknews wrote: post #6
auggierose wrote: post #2

Safari doesn't show the t's. Why?? Chrome does.

exactly wtf is up with this website, firefox doesn't show t's, random f's, d's - it's a complete mess.

My best guess is that the font I am using (WOFF2 variable font) might be tripping up the browser.

Re: An Honest Review of Go (2025)

#143

Post by travisgriggs »

sethammons wrote: post #75
travisgriggs wrote: post #64

Another languages that just “gets” concurrent right (imo) is erlang/elixir. I’ve done elixir for the last 3 years off and on. Can someone with experience in both Go and Elixir compare the two? I’m sure I can have GPT whip up a comparison and see the syntax diffeeences, but I’m curious what the real experience “in the trench” is like.

I've used both professionally. I think elixir has some amazing ideas. I love pattern matching. However! Just like all other interpreted languages, in elixir, I have to go to the call sites of the function that I am editing to understand what it is that is actually available and to understand what I can edit. I don't know what has been passed into my function. The lack of types is not fixed by having a type spec and d…

I was curious in particular about the concurrency story between the two, but thanks for the higher level feedback.

Re: An Honest Review of Go (2025)

#144

Post by bccdee »

9rx wrote: post #130
bccdee wrote: post #25

Earlier quoted context omitted.

You're right, but I still think they have a point. What I miss from `error.Is/As` is exhaustive matching. I'd love a way to statically guarantee I haven't missed an important error type. It really comes back to the absence of sum types.

> I'd love a way to statically guarantee I haven't missed an important error type. It wouldn't be hard — rather easy, even — to write a static analyzer for that if you constrained your expectations to cases where sum types could practically be used. No reason to not do it right now! But sum types don't really solve for a lot of cases. Even in Go you can add additional constraints to errors to get something approachin…

> There is good reason why even the languages that support defined error sets have trended back to using open-ended constructs.

Rust does it that way & has never trended in any other direction. The generally-accepted wisdom is "thiserror¹ for libraries, anyhow² for applications"—i.e., any error that's liable to be handled by a machine should be an enum of exhaustively-matchable error kinds, whereas anything that's just being propagated to the user should be stringified & decorated with context as it bubbles up.

Certainly, unified error types which wrap and erase more specific errors are sometimes desirable, but equally they often are not. Languages which support exhaustive matching support both, permitting us to choose based on context.

[1]: https://docs.rs/thiserror/latest/thiserror/

[2]: https://docs.rs/anyhow/latest/anyhow/

Re: An Honest Review of Go (2025)

#145

Post by jimbokun »

yomismoaqui wrote: post #66

Another comment already mentioned that the OP don't understand how to work with errors in Go. As with any language, Go has its own philosophy and you have to first understand why it was created and what it brings to the table. To summarize it in one phrase "Less is more" I think this post should be a mandatory reading for everybody learning Go. If this resonates with you it's possible you're gonna like the language:…

I believe I read this when it was first published but it still holds up very well today.

Re: An Honest Review of Go (2025)

#146

Post by jimbokun »

osigurdson wrote: post #94

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.

But you can learn about yourself and others by writing down specifically the things you like and don’t like, and reading other people doing the same. With the possibility of liking different things for different reasons in the future. Or just better understanding how to best use the tools you like.

Re: An Honest Review of Go (2025)

#147

Post by jimbokun »

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.

Yea but with a tiny bit more effort they could have ensured that an invalid value is never assigned to an enum, iterate over the values, ensure switch statements handle every case, etc.

Re: An Honest Review of Go (2025)

#148

Post by anttiharju »

vlovich123 wrote: post #140
anttiharju wrote: post #17

Earlier quoted context omitted.

I like Rust. I don't like that for fairly basic things one has to quickly reach for crates. I suppose it allows the best implementation to emerge and not be concerned with a breaking change to the language itself. I also don't like how difficult it is to cross-compile from Linux to macOS. zig cc exists, but quickly runs into a situation where a linker flag is unsupported. The rust-lang/libc also (apparently?) insists…

There’s cross-rs which simplifies things. But the main problem is less linker flags being unsupported and more cross compiling C dependencies somewhere in the dependency chain and that’s always a nightmare, not really anything to do with Rust (Go should have similar difficulties with cross compilation).

Fair take for nontrivial projects.

Buuut with Go one in general tends to reach less for dependencies so less likely to run into this and cgo is not go ;) https://go-proverbs.github.io

but for cross-compiling actually ended up filtering out the liconv flag with a bash wrapper and compiled a custom zig cc version with the support for exported_symbols_list patched in, things appear to work.

Should look into cross-rs I suppose. Hope it's not one of those "download macos sdk from this unofficial source" setups that people seem to do. Apparently not allowed by Apple.

Re: An Honest Review of Go (2025)

#149

Post by vlovich123 »

anttiharju wrote: post #148
vlovich123 wrote: post #140

Earlier quoted context omitted.

There’s cross-rs which simplifies things. But the main problem is less linker flags being unsupported and more cross compiling C dependencies somewhere in the dependency chain and that’s always a nightmare, not really anything to do with Rust (Go should have similar difficulties with cross compilation).

Fair take for nontrivial projects. Buuut with Go one in general tends to reach less for dependencies so less likely to run into this and cgo is not go ;) https://go-proverbs.github.io but for cross-compiling actually ended up filtering out the liconv flag with a bash wrapper and compiled a custom zig cc version with the support for exported_symbols_list patched in, things appear to work. Should look into cross-rs I s…

Cross compiling to Apple products from non Apple products is going to run into the same hurdle around SDK setup as any other. There exists documentation but it’s probably not the easiest task. This limitation though applies equally to any library that depends on system C headers and/or system libraries.

Re: An Honest Review of Go (2025)

#150

Post by [deleted] »

bccdee wrote: post #144
9rx wrote: post #130

Earlier quoted context omitted.

> I'd love a way to statically guarantee I haven't missed an important error type. It wouldn't be hard — rather easy, even — to write a static analyzer for that if you constrained your expectations to cases where sum types could practically be used. No reason to not do it right now! But sum types don't really solve for a lot of cases. Even in Go you can add additional constraints to errors to get something approachin…

> There is good reason why even the languages that support defined error sets have trended back to using open-ended constructs. Rust does it that way & has never trended in any other direction. The generally-accepted wisdom is "thiserror¹ for libraries, anyhow² for applications"—i.e., any error that's liable to be handled by a machine should be an enum of exhaustively-matchable error kinds, whereas anything that's ju…

[deleted]
Post reply on HN