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

81–90 of 184 posts

Re: An Honest Review of Go (2025)

#81

Post by sethammons »

tschellenbach wrote: post #10

10 years ago we started out with Python. We switched to Go probably 8 years back. I think my little startup would have utterly failed without Go. Thx google :) But yes Enums are so much nicer in Kotlin vs Go. That's true, it doesn't impact productivity much, but he has a point.

I think some pythonistas maybe got their feeling hurt by your comment causing it to grey out.

Over the last 25 years in the SaaS world, I have never seen python evolve into a system that is easy to reason about and debug. It lets you do too many things. In over 30 cases, I have seen teams deliver better software faster in Go after replacing their Python.

Re: An Honest Review of Go (2025)

#82

Post by lagniappe »

lemoncucumber wrote: post #61
CamouflagedKiwi wrote: post #42

Earlier quoted context omitted.

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

I would not agree with that assertion. Just off the top of my head, being familiar with both:

- context

- net/http as a full server framework, not just a request library

- net/http/pprof

- runtime/pprof

- runtime/trace

- embed

- testing as the canonical, required test framework

- net/rpc

- net/http/cgi

- net/http/fcgi

- net/http/httptest

- os/signal with integrated channel-based delivery

- sync/atomic with language-aligned memory model semantics

- runtime as a documented and supported API surface

Re: An Honest Review of Go (2025)

#83

Post by AnimalMuppet »

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?

Re: An Honest Review of Go (2025)

#84

Post by g947o »

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 simplest thing is not to do anything but defer to caller to handle it, in languages like Python, Java, JavaScript. Often that is also the only realistic way to an error, especially for library code.

Re: An Honest Review of Go (2025)

#85

Post by the_gipsy »

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…

The author is wrong, there exist mechanisms to cast errors. But they all suck! It's all just guessing and grepping for -hopefully- unique error messages.

Re: An Honest Review of Go (2025)

#86

Post by benrazdev »

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…

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

I agree with you. I don't have problems with the `if err!=nil` syntax.

From my post: > It’s become something of a meme to bemoan the supposed difficulty of writing if err != nil. I actually won’t make that point because I think it is a very surface level point that has been talked about to death and *I don’t think the ‘verbosity’ of this code snippet is such an issue.*

I apologize if my language was ambiguous on whether or whether not I had a problem with that syntax.

>In his example author could easily use his `progError` type instead.

I agree, but it was my impression that type erasure was more idiomatic. I should have made it clear that I was criticizing that idiom, not the language.

>Well, no. See for wrap/unwrap functionality https://go.dev/blog/go1.13-errors

You are right. I should have done my research on that before writing that point. I still think that downcasting isn't the most elegant solution because it defeats the point of using the opaque return type but I agree that it is nowhere near as much of a problem as I thought it was.

Re: An Honest Review of Go (2025)

#87

Post by jdefr89 »

They don't seem to understand Go much at all. Comparisons to Rust are somewhat misplaced but that's a different topic... Back to errors. Errors are interface values. They are simple yet powerful. You can create sentinel errors that can be wrapped or just passed to be checked then discarded. Go has all the functionality it needs to provide what ever it is Rust cult members believe makes Rust error handling so great. You can use the primitive constructs Go provides to do nearly the same damn things Rust can do and it won't look like a pile of hieroglyphs your local crackhead would draw. Best of all... Its simple and the syntax of Go (veering off topic) doesn't make me want to jump off a bridge. Stop gaslighting yourselves into thinking Rust syntax is reasonable and that its some perfectly proven language with all edge cases put to rest..

Re: An Honest Review of Go (2025)

#88

Post by kllrnohj »

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…

The author is clearly aware of `error.Is` as they use it in the snippet they complain about. The problem is Go's errors are not exhaustive, the equivalent to ENOTDIR does not exist. So you can't `errors.Is` it. And while Stat does tell you what specific error type it'll be in the documentation, that error type also doesn't have the error code. Just more strings!

Is this a problem with Go the language or Go the standard library or Go the community as a whole? Hard to say. But if the standard library uses errors badly, it does provide rather compelling evidence that the language design around it wasn't that great.

Re: An Honest Review of Go (2025)

#89

Post by all2 »

irjoe wrote: post #69

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

I'm curious what the alternative would be? Python's threads/sub-processing almost requires IO queues to function well, and are nearly the same semantically as channels...

I'm not saying these are "good", just wondering what alternatives look like?

Re: An Honest Review of Go (2025)

#90

Post by jdefr89 »

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 super misguided and it sets me off.
Post reply on HN