I’ve used Go for a similar amount of time as you. I started with Go 1.0 when I pitched it to my company at the time, and then migrated all of our BE code to Go. It solved the problems we had at the time, and I certainly don’t regret that decision.
However, I ran into a ton of issues that I really don’t think I should have. For example:
dumb bugs stemming from nil and weird interaction with interfaces (e.g. interface{}((*int)(nil)) != nil); honorable mention, functions attached to nil types can still be called, so the source of the nil could be hard to find
map isn’t thread safe; why??
nothing like Arc in Go, either use a channel or DIY with a mutex
And so on. Go strives to be easy to write, but it doesn’t do much to hide the footguns. So it’s like C, but at least you get panics instead of SEGFAULTs.
These days I much prefer Rust. I followed Rust pre-1.0, and I’ve used it a bit for personal projects since 1.0. It has come a long way, and I think it’s finally at a point where the barrier to entry is low enough and the ecosystem is robust enough that it can be a decent alternative to Go. I like that it doesn’t hide the complexity and forces you to deal with design problems at compile time instead of running into them randomly.
If Rust is too much, I prefer Python.
I wish Go would do something about its footguns. I honestly don’t like using it anymore because I get a ton of complexity with goroutines and whatnot, and very little to help manage it. The main thing I miss is pprof, and I find I haven’t needed it with Rust because things just run better.
I’ve used Go for a similar amount of time as you. I started with Go 1.0 when I pitched it to my company at the time, and then migrated all of our BE code to Go. It solved the problems we had at the time, and I certainly don’t regret that decision.
However, I ran into a ton of issues that I really don’t think I should have. For example:
niland weird interaction with interfaces (e.g.interface{}((*int)(nil)) != nil); honorable mention, functions attached to nil types can still be called, so the source of the nil could be hard to findmapisn’t thread safe; why??Arcin Go, either use a channel or DIY with a mutexAnd so on. Go strives to be easy to write, but it doesn’t do much to hide the footguns. So it’s like C, but at least you get panics instead of SEGFAULTs.
These days I much prefer Rust. I followed Rust pre-1.0, and I’ve used it a bit for personal projects since 1.0. It has come a long way, and I think it’s finally at a point where the barrier to entry is low enough and the ecosystem is robust enough that it can be a decent alternative to Go. I like that it doesn’t hide the complexity and forces you to deal with design problems at compile time instead of running into them randomly.
If Rust is too much, I prefer Python.
I wish Go would do something about its footguns. I honestly don’t like using it anymore because I get a ton of complexity with goroutines and whatnot, and very little to help manage it. The main thing I miss is
pprof, and I find I haven’t needed it with Rust because things just run better.