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

161–170 of 184 posts

Re: An Honest Review of Go (2025)

#161

Post by ddoolin »

usrbinbash wrote: post #133
eddd-ddde wrote: post #112

Earlier quoted context omitted.

I definitely prefer public private over case defined visibility. You can't use an array for different types. Matching _is_ useful, no one uses matching just because it looks "cool". You can have explicit forced AND exhaustive error handling without exceptions. Go actually lacks this.

> I definitely prefer public private over case defined visibility. And I think `public` and `private` keywords are a verbose mess that adds nothing to a language. > You can't use an array for different types. Yes I can. I even provided an example for exactly that: `[4]any` can hold references to any type. > Matching _is_ useful A lot of things are useful, doesn't mean they are used for that useful case most of the ti…

> Yes I can. I even provided an example for exactly that: `[4]any` can hold references to any type.

And now you've lost type checking. `(&'static str, bool, u64, f64)` is not the same as `[4]any`.

> A lot of things are useful, doesn't mean they are used for that useful case most of the time.

I'm sure you have vast insights into what most people do most of the time.

> Go has wrapped and typed errors, covering exactly that.

Sure, "Go has X because it gives you the tools to reimplement it yourself another way" is true of most anything you can think of.

Re: An Honest Review of Go (2025)

#166

Post by dent9 »

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…

This is such a big deal and I wish more people talked about it in these types of blog posts.

I used to be a Python programmer and there were two things that destroyed every project;

- managing Python dependencies

- inability to reason about the input and output types for functions and inability to enforce it ; in Python any function can accept any input value of any type and can return any type of value of any type.

These issues are not too bad if it's a small project and you're the sole developer. But as projects get larger and require multiple developers, it turns into a mess quickly.

Go solved all these issues. Makes deployment so much easier. In all the projects I've done I estimate that more than half have zero dependencies outside of the standard library. And unlike Python, you don't have to "install" Go or it's libraries on the server you plan to run your program on. Fully static self contained executable binary with zero external files needed is amazing, and the fact that you can cross compile for any OS+ CPU arch out of the box on any supported system is a miracle.

The issues described by the original post seem like small potatoes compared to the benefits I've gotten by shifting from Python over to Go

Re: An Honest Review of Go (2025)

#167

Post by dent9 »

vlovich123 wrote: post #140
anttiharju wrote: post #17

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…

There’s cross-rs which simplifies things. But the main problem is less linker flags being unsupported and more cross compiling C dependencies somewhere in the dependency chain and that’s always a nightmare, not really anything to do with Rust (Go should have similar difficulties with cross compilation).

> Go should have similar difficulties with cross compilation

It doesn't. Go code can be cross compiled for any OS and any CPU arch from any supported system. And it comes out of the box that way. You don't have to go out of your way to install or configure anything extra to do it.

Re: An Honest Review of Go (2025)

#168

Post by osigurdson »

jimbokun wrote: post #146
osigurdson wrote: post #94

The way I do this is decide which language I like (just by gut feel) and then come up with reasons why it is good / better than others. I think almost everyone does the same thing, really.

But you can learn about yourself and others by writing down specifically the things you like and don’t like, and reading other people doing the same. With the possibility of liking different things for different reasons in the future. Or just better understanding how to best use the tools you like.

Also, if you only really know one language well, don't let your brain tell you it is the best one without a bit more investigation.

Re: An Honest Review of Go (2025)

#169

Post by vlovich123 »

dent9 wrote: post #167
vlovich123 wrote: post #140

Earlier quoted context omitted.

There’s cross-rs which simplifies things. But the main problem is less linker flags being unsupported and more cross compiling C dependencies somewhere in the dependency chain and that’s always a nightmare, not really anything to do with Rust (Go should have similar difficulties with cross compilation).

> Go should have similar difficulties with cross compilation It doesn't. Go code can be cross compiled for any OS and any CPU arch from any supported system. And it comes out of the box that way. You don't have to go out of your way to install or configure anything extra to do it.

We’re not talking about go here. This is true for rust. The issue is building against C libraries and APIs for a different OS. Unless go has done some magic I’m unaware of its the same problem, just cgo isn’t super popular in the Go community

Re: An Honest Review of Go (2025)

#170

Post by ternaryoperator »

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

Coming from Java, I find the standard lib very small. A case in point is the collections library: arrays/slices, map, list, ring, and heap -- that's about as minimal as you can get.

Post reply on HN