Live data from Hacker News

An Honest Review of Go (2025)

benraz.dev

21–30 of 184 posts

Re: An Honest Review of Go (2025)

#21
post #6

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.

No issues here on Firefox 146 Fedora/GNOME. Also imagine it's not uncommon for a personal site to not test for Safari if they're not in the Apple ecosystem.

Re: An Honest Review of Go (2025)

#22

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…

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…

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.

Everything is literally built-in. It's the perfect scripting language replacement with the fast compile time and tiny language spec (Java 900 pages vs Go 130 pages) making it easy to fully train C-family devs into it within a couple weeks.

Re: An Honest Review of Go (2025)

#23

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…

I admit that it's nice to have a very simple, straightforward, and minimal build process. No dealing with VMs, no setting up environments, just install Go and then compile your program. Reminds me of C back in the late 90s.

Re: An Honest Review of Go (2025)

#24
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.

Re: An Honest Review of Go (2025)

#25

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.

Re: An Honest Review of Go (2025)

#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 wrap/unwrap functionality https://go.dev/blog/go1.13-errors

> In Go, errors are values. They just aren’t particularly useful values.

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

Gosh, why it's so tempting to write a post about bad language instead of just reading docs or article about idiomatic usage?

Re: An Honest Review of Go (2025)

#27

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…

You defer at the beginning, not at the end in Go. /jk

Hey you caught that! I was hoping someone would notice the joke :)

Re: An Honest Review of Go (2025)

#28

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

Then ask a JS web developer what "big standard library" would mean, and Go probably would fit somehow with that definition :)

It seems to be very relative depending on where you come from.

Re: An Honest Review of Go (2025)

#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 particularly useful values"

...sometimes user mistakes are due to the language being too complicated, maybe for no benefit, but I don't think that's the case here. It's a very good thing that you can just slap .Error() on any error to print it quickly, and not too crazy complex to say an error can be any normal type that you can use, as long as it also can print Error()

Re: An Honest Review of Go (2025)

#30

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…

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.
Post reply on HN