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

121–130 of 184 posts

Re: An Honest Review of Go (2025)

#121

Post by [deleted] »

bccdee wrote: post #25
iamcalledrob wrote: post #18

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

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.

[deleted]

Re: An Honest Review of Go (2025)

#122

Post by benrazdev »

shirogane86x wrote: post #70
lenkite wrote: post #20

His example criticizing errors in `rootInfo` func is silly. There is utterly no need to do a `strings.HasSuffix(err.Error(), "not a directory")`.

but how would you do that otherwise? Genuinely curious cause I looked up both the go docs and source (disclaimer: not a go dev), and there doesn't seem a way to handle that specific kind of error through stuff like `errors.Is`, at least from what I can tell, at least in the os and fs packages

From what the comments are saying I think you downcast with `errors.As` and then work on the underlying error type. But I don't know for sure.

Re: An Honest Review of Go (2025)

#123

Post by benrazdev »

tptacek wrote: post #106
benrazdev wrote: post #104

Earlier quoted context omitted.

>this is false. It's mostly false. Technically, if you use `fmt.Errorf`, then the caller can't get anything useful out of your errors. Types are promises. All the `error` interface promises is a string representation. I acknowledge that most of the time there is more information available. However, from the function signature _alone_, you wouldn't know. I understand that this is more of a theoretical problem then a p…

The subtlety missed in these conversations is that almost all the information there is for typical error handling --- that is, all the information that would be present in a typical Rust error handling scenario as well --- is encoded in the type tree of the errors. (Rust then improves drastically on the situation with pattern matching, which would simply improve Go with no tradeoffs I can really discern, just so we'r…

>that is, all the information that would be present in a typical Rust error handling scenario as well --- is encoded in the type tree of the errors.

it's only present when you downcast though?

Re: An Honest Review of Go (2025)

#124

Post by benrazdev »

anttiharju wrote: post #111
Xeoncross wrote: post #22

Earlier quoted context omitted.

Yeah, I've never seen an all-in-one language like Go before. Not just a huge stdlib where you don't have to vet the authors on github to see if you'll be okay using their package, but also a huge amount of utility built in like benchmarking, testing, multiple platforms, profiling, formatting, and race-detection to name a few. I'm sad they still allow null, but they got a lot right when it comes to the tools. Everythi…

Oh Go with Rust's result/none setup and maybe better consts like in the article would be great. Too ba null/nil is to stay since no Go 2. Or maybe they would? Iirc 1.21 had technically a breaking change related to for loops. If it was just possible to have migration tooling. I guess too large of a change.

Technically, with generics, you could get a Result that is almost as good as Rust, but it is unidiomatic and awkward to write:

    type Result[T, E any] struct {
        Val   T
        Err   E
        IsErr bool
    }

    type Payload string

    type ProgError struct {
        Prog   string
        Code   int
        Reason string
    }

    func DoStuff(x int) Result[Payload, ProgError] {
        if x > 8 {
            return Result[Payload, ProgError]{Err: ProgError{Prog: "ls", code: 1, "no directory"}}
        }
        return Result[Payload, ProgError]{Val: "hello"}
    }

Re: An Honest Review of Go (2025)

#125

Post by benrazdev »

surgical_fire wrote: post #109
Xeoncross wrote: post #9

One of the things I wish more people talked about isn't just the language or the syntax, but the ecosystem . Programming isn't just typing, it's dealing with dependencies and trying to wire everything up so you can have tests, benchmarks, code-generation and build scripts all working together well. When I use modern languages like Go or Rust I don't have to deal with all the stuff added to other languages over the pa…

> However, I'd pick Rust when the team isn't scared of learning to program for real. I've been learning Rust. It's elegant, and I am enjoying it. The Rust people however are absolutely annoying though. Never have I seen such a worse group of language zealots.

I can't speak for other Rust programmers but I can speak for myself.

I obviously enjoy programming Rust and I like many of the choices it made, but I am well aware of the tradeoffs Rust has made and I understand why other languages chose not to make them. Nor do I think Rust functions equally as well in every single use case.

I imagine most Rust users think like this, but unfortunately there seems to be a vocal minority who hold very dogmatic views of programming who have shaped how most people view the Rust community.

Re: An Honest Review of Go (2025)

#126

Post by RSHEPP »

surgical_fire wrote: post #109
Xeoncross wrote: post #9

One of the things I wish more people talked about isn't just the language or the syntax, but the ecosystem . Programming isn't just typing, it's dealing with dependencies and trying to wire everything up so you can have tests, benchmarks, code-generation and build scripts all working together well. When I use modern languages like Go or Rust I don't have to deal with all the stuff added to other languages over the pa…

> However, I'd pick Rust when the team isn't scared of learning to program for real. I've been learning Rust. It's elegant, and I am enjoying it. The Rust people however are absolutely annoying though. Never have I seen such a worse group of language zealots.

Guess I am scared to program for real since I don't use a "real" language like Rust. What a wild statement to make.

Re: An Honest Review of Go (2025)

#127

Post by benrazdev »

Minor49er wrote: post #58
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…

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

Its not really a matter of logic, I guess.

Writing `pub` is personally more annoying to me than writing `if err != nil`. I understand that most people don't like how capitalization determines visibility, but I think it actually makes sense when you think about it.

Re: An Honest Review of Go (2025)

#128

Post by benrazdev »

OkayPhysicist wrote: post #24
tombert wrote: post #3

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

I agree with your point in general, but I would challenge the idea that tuples aren't something that is intuitive to explain (even in less than 30 seconds). Perhaps it's difficult to explain why tuples and not lists, but that's also relatively simple (homogeneous vs heterogeneous)

Re: An Honest Review of Go (2025)

#129

Post by tptacek »

benrazdev wrote: post #123
tptacek wrote: post #106

Earlier quoted context omitted.

The subtlety missed in these conversations is that almost all the information there is for typical error handling --- that is, all the information that would be present in a typical Rust error handling scenario as well --- is encoded in the type tree of the errors. (Rust then improves drastically on the situation with pattern matching, which would simply improve Go with no tradeoffs I can really discern, just so we'r…

>that is, all the information that would be present in a typical Rust error handling scenario as well --- is encoded in the type tree of the errors. it's only present when you downcast though?

It's not super ergonomic, but the information is there, in about the same density as it would be in a Rust app, supporting the same error handling strategies (ie, discriminating between transient and durable errors, &c).

Re: An Honest Review of Go (2025)

#130

Post by 9rx »

bccdee wrote: post #25
iamcalledrob wrote: post #18

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

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 approaching sum types. You don't have to use a naked `error`. But you are bound to start feeling pain down the road if you try. There is good reason why even the languages that support defined error sets have trended back to using open-ended constructs.

It does sound great in theory, no doubt, but reality is not so kind.

Post reply on HN