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

41–50 of 184 posts

Re: An Honest Review of Go (2025)

#41

Post by ljm »

logicprog wrote: post #33
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…

Yeah, I'm brand new to learning Go, but that was the first thing I thought when I got to his section on errors. You're supposed to return a generalized error and then use errors.is or errors.as to figure out what specific type of error it is so that you can access the specific data on it. And the reason you do it that way instead of just returning a concrete error type is because one function might want to return dif…

I think Go's concept of error wrapping is probably unusual to newcomers to the language who might be used to, say, pulling in a dependency for error handling (logrus or whatever) when it's all there in the stdlib in what Go has decided to be the idiomatic way to do errors and logging.

It's nice when you understand how to do it well and move on from, say, printing errors directly where they happen rather than creating, essentially, a stack of wrapped errors that gets dumped at an interface boundary, giving you much more context.

Re: An Honest Review of Go (2025)

#42

Post by CamouflagedKiwi »

nh23423fefe wrote: post #16
lagniappe wrote: post #7

Go is a pleasure to use. The stdlib is one of the most complete, while keeping the keyword count low. LLMs understand it very well, project size stays low, line count stays low (if err nil included), doesn't need a bunch of scaffolded boilerplate in the project directory, and it compiles very quickly for a ton of OS and architectures. Very seldom do I ever need to go outside of the stdlib. Is it perfect for everythin…

> The stdlib is one of the most complete what does this mean? Go lib seems tiny compared to JDK. anytime i review some Go code from adjacent team i'm turned off by weird stuff like append and slices everywhere, as well as a bunch of strange string packages When I think of a massive stdlib I think of a language like groovy

When I use Go, I find I can get more real work done with only the standard library than with any other language I've used (including Java, although that was quite a while ago now). It may not have the most stuff, it is more focused - but I'm okay with esoteric stuff not being in there since the tradeoff seems to be that there are high-quality implementations of e.g. an HTTP client and server, crypto functions, a unit testing library, JSON en/decoding etc, which I can definitely use in production. Conversely in Java the answer seems to be to use BouncyCastle / Tomcat / Jackson / etc, so while there may be a big stdlib, it ends up being less useful.

Re: An Honest Review of Go (2025)

#43

Post by MobiusHorizons »

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.

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.

Re: An Honest Review of Go (2025)

#44

Post by usrbinbash »

ddoolin wrote: post #19

I've only written a handful of production projects in Go so my experience isn't very deep, but I find the syntax to be the ugliest of any PL. The mixed capitalizing based on function privacy, to me, is awful (among other things, i.e. personally I loathe curly brace initialization/definition). I'm sure you get used to it? It doesn't help that it just feels very hacked together, from the wonky generics, the lack of use…

> The mixed capitalizing based on function privacy, to me, is awful

Awful compared to ... what? `private` and `public` keywords? Ugly hacks like pythons `_` and `__`?

> it just feels very hacked together

> the wonky generics

What exactly about the generics is "wonky"? "Wonky" is not a term defined in any programming textbook I ever read. And languages are not designed on feelings, especially when the design goal is to be as pragmatic as possible, as is the case in Go.

> the lack of useful types like tuples and enums,

Need a tuple? Use an array and don't change it.

  - [2]string: string 2-tuple
  - [5]int: int 5-tuple
  - [1]any: empty-interface 1-tuple
And btw. 99% of the time tuples are used, it's as a stand-in for multiple-returns. E.g. Python does that. Go simply has...multiple returns.

> and enums,

Outside of language-enthusiasm with matching and whatnot (which more often than not is used because it looks cool rather than being useful), the most common (and again, 99%) use of enums, is to give names to magic values. Go has that covered:

    type Color string
    const (
      RED Color = iota
      GREEN
      BLUE
    )
> the bolted on module system

Pray tell what exactly is "bolted on" about modules? They are simply an extension of the import system, nothing more, nothing less.

> the annoying error handling

The "annoying" thing about it is that it's explicit and forced. Both of which are positives as far as I'm concerned, because I AM FREKKIN DONE with shitty 10-mile stacktraces because some joksters library threw an "exception" 400 layers down in some sub-sub-sub-sub transient dependency lib.

Re: An Honest Review of Go (2025)

#45

Post by dematz »

ljm wrote: post #41
logicprog wrote: post #33

Earlier quoted context omitted.

Yeah, I'm brand new to learning Go, but that was the first thing I thought when I got to his section on errors. You're supposed to return a generalized error and then use errors.is or errors.as to figure out what specific type of error it is so that you can access the specific data on it. And the reason you do it that way instead of just returning a concrete error type is because one function might want to return dif…

I think Go's concept of error wrapping is probably unusual to newcomers to the language who might be used to, say, pulling in a dependency for error handling (logrus or whatever) when it's all there in the stdlib in what Go has decided to be the idiomatic way to do errors and logging. It's nice when you understand how to do it well and move on from, say, printing errors directly where they happen rather than creating…

I think it's probably confusing until you understand interfaces, which coming from other languages you might not be familiar with (my guess for what happened in this blog post). If you don't know what an interface is then maybe you assume err.Error() is some kind of string, without realizing Error() is just a required function but the err could be whatever type.

Re: An Honest Review of Go (2025)

#47

Post by gen2brain »

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 compile after 24h, I use rust-bin in Gentoo,luckily that exists.

Re: An Honest Review of Go (2025)

#48

Post by dkarl »

9rx wrote: post #40
dkarl wrote: post #34

Earlier quoted context omitted.

> I don't like the term "enums" because of the overloading between simple integers that indicate something (the older, more traditional meaning) I disagree with this. I'm old as hell, and I learned programming in a context where enums were always ints, but I remember being introduced to int enums as "we're going to use ints to represent the values of our enum," not "enums are when you use ints to represent a set of v…

"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, not the representation.

Re: An Honest Review of Go (2025)

#49

Post by weitendorf »

MobiusHorizons wrote: post #43
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.

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.

The problem is that this makes enums non-enumerable. They need to be represented as a range or union type to do that. I am pretty sure I know why/how Go ended up like this because it’s inherited behavior from proto, wrote a large comment later down the thread explaining why.

Re: An Honest Review of Go (2025)

#50

Post by MobiusHorizons »

dematz wrote: post #29

Correct me if I'm wrong, but the Error interface means you can display the error as a string, but you don't have to? Like the err.Error() is idiomatic if you just want to display something , but you could also use the error itself https://pkg.go.dev/errors#As here's an example that uses a field from your blog example error type: https://go.dev/play/p/SoVrnfXfzZy Also "In Go, errors are values. They just aren’t partic…

My guess is that the author hasn’t fully frocked how go interfaces work yet. Go errors implement the error interface, but that just makes them interoperable, it doesn’t mean that’s all they are.
Post reply on HN