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

Re: An Honest Review of Go (2025)

#61

Post by lemoncucumber » Thu, Jan 08, 2026, 5:15 PM UTC

CamouflagedKiwi wrote: post #42

nh23423fefe wrote: post #16

Earlier quoted context omitted.

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

Python's standard library seems comparable IME

Re: An Honest Review of Go (2025)

#62

Post by booi » Thu, Jan 08, 2026, 5:16 PM UTC

christophilus wrote: post #30

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…

C# is pretty close.

This was not the case for a long time. Actually it seems like it's fairly recently you get native AOT and trimming to actually reduce build sizes and build time. Otherwise all the binaries come with a giant library

Re: An Honest Review of Go (2025)

#63

Post by tptacek » Thu, Jan 08, 2026, 5:17 PM UTC

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…

In fairness, the idea that you needed to scrape error strings to handle errors was a very popular complaint about Go that was valid 10 years ago, including in the standard library.

Re: An Honest Review of Go (2025)

#64

Post by travisgriggs » Thu, Jan 08, 2026, 5:18 PM UTC

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.

Re: An Honest Review of Go (2025)

#65

Post by tptacek » Thu, Jan 08, 2026, 5:18 PM UTC

iamsomewalrus wrote: post #52

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…

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

The article claims:

"The user now has an interface value error that the only thing they can do is access the string representation of."

This is false. Didn't used to be, but that was many years ago.

Re: An Honest Review of Go (2025)

#66

Post by yomismoaqui » Thu, Jan 08, 2026, 5:19 PM UTC

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:

https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

Re: An Honest Review of Go (2025)

#67

Post by jimmytucson » Thu, Jan 08, 2026, 5:20 PM UTC

Not shilling for Go here but there are a few misconceptions in this blog post. In addition to the others mentioned:

> All of these examples involve assigning to a constant a value known at compile time but none of them will work

Maps are not known at compile time. Hash functions are randomized based on a seed only known at execution time. The hashed value of "HELLO" is actually different each time the program runs. Even if the hash function weren't random, the runtime has to allocate buckets for map values on the heap, which involves calling the OS to get memory addresses for those buckets, etc.

In Go, `const` means "the compiler can completely evaluate this expression and store the final bytes in the executable," which has the effect of making them non-reassignable, but protection from reassignment is not an actual feature of the language the way it is in Java and C++ (goes back to the maintainers wanting to keep it simple).

Re: An Honest Review of Go (2025)

#68

Post by divan » Thu, Jan 08, 2026, 5:22 PM UTC

stouset wrote: post #55

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…

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

> The noise this pattern introduces

Here is the thing... it's NOT a 'noise'. Untill you see handling 'error path' as noise, you will be trapped in searching magic bullet language solution to hide it. We've all been there.

Re: An Honest Review of Go (2025)

#69

Post by irjoe » Thu, Jan 08, 2026, 5:24 PM UTC

I always felt like go channels were more of a clever solution than a good one. Goroutines are a pleasure to work with though.

Re: An Honest Review of Go (2025)

#70

Post by shirogane86x » Thu, Jan 08, 2026, 5:25 PM UTC

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