Ask HN: What do you like/dislike about Golang?

Languages must choose tradeoffs, and I think Go gears its tradeoffs towards large projects.

Generally the larger a project becomes, the longer it takes to add features and fix bugs - so to combat this Go favors quick compile times, easy monorepos, simple tooling, and most of all: very consistent code. Go's limited syntax is a feature, not a bug.

Syntax sugar in a language allows for writing code quickly, but it (arguably) opens up more opportunities for bad code - e.g. using language features inappropriately, mixing the "sugar" approach with the "manual" approach in the same codebase, being terse and hard to read, etc. If most of a developer's interaction with code is spent reading rather than writing, then it makes sense to value quick to read but long to write code. Go's philosophy of there being "one way" to do things (arguably) achieves that.

Having a very transparent control flow (including treating errors as simply values) is in line with that. Yes errors pollute one's code - I would like an operator for that, but I'm glad the error conditions are being represented clearly.

Go is perhaps not a good language if you want to get an MVP going quickly, or write something with a performance focus.

Disclaimer: I love Go. I taught myself Go while I was working as a Java dev and it was a big factor in me finding a new job.

LIke:

- Decent speed of compiling and execution.

- Expressiveness.

- I like the struct/receiver/interface interplay to create an analog of classes.

- Nice standard library.

- Cross compilation.

Things I wish for:

- Ternary operator.

- Something a bit closer to inheritance. Embedding structs in other structs fools you into thinking there's inheritance, but you quickly learn that it doesn't work the way you think it will.

- At the same time, fully implementing a functional programming paradigm isn't particularly easy either.

But all in all, I'm a big fan.

Not OP, but I am also in the camp of "like goroutines, not a fan of channels". Low cost threads are great - but channels can represent so many intermediate states, especially when error handling is involved. I wish there was a simpler default for coordinating goroutines

(Do we add an error field to the struct we send through a channel? Do we close the channel on error, or only on success? Do we make a separate channel to send errors on - and if we close that one it means for sure that there were no errors? If we select on the two dependent channels, do we have to make sure that they are in different sequential selects, so that we don't go out-of-order or deadlock?)

At 2/3 of every screen, error handling is absurdly noisy. A DSL for wrapping and bubbling up errors (the 99% case) is desperately needed.

The builtin containers just suck. They’re always mutable. Map write conflicts might panic, yet there’s no support for preventing them. They aren’t comparable, which can cause panics elsewhere. You have to pretend slices have move semantics, because copies may or may not share state after an append. They don’t implement any interfaces, so you can’t even replace them or reuse their sugar.

Functions can return tuples, but tuples aren’t first-class, there are no maps or channels of tuples.

No overloading, each type sig needs its own func name and IDE refactoring won’t choose the right one.

Reflection is very limited. No access to types or functions by name. No type or func or arg annotations, just a single string on a struct field.

The GC design is pretty old and people go out of their way to avoid relying on its throughput.

Liked: The memory footprint is pretty small. Parts of the community are starting to rely on code generation to work around the base language (e.g., piles of ignored boilerplate because Mockito can’t be implemented at runtime).