| Thank you for the insights on Go and how Go has added value to your
organizations and enabled a better environment for development at your
organization! I love hearing viewpoints on tradeoffs and general evaluations on
value of new(ish) development technologies. I'd also like to point out that I write this a Python-phile that has come to the
understanding that Python is great until it isn't. When Python becomes to
burdensome, the understanding of the problem delivered by my Python sketch
helps to narrow the focus of what I need to solve the problem efficiently. By
that time, Go has never been the correct tool for me. I'm comfortable writing
solutions in C, Rust and Java, perhaps this is my problem. Whenever I read or write Go I don't understand how it managed to capture the
mindshare that is has. Especially in the face of other technologies available,
Go seems like a timid step forward in descriptions of computation, when there
are bolder choices that deliver valuable additions to my development ecosystem. I appreciate that Go places a premium price on simplicity, however with
languages like Rust make some big steps towards static guarantees at compile
time the guarantees that Go makes seem pretty weak. But I feel that when I make
the leap from Python to Go, I admittedly don't understand the allure. Static
compiltion is really nice! Statically linked binaries for distribution is very
nice! The tooling is out of this world! Hands down, Go has one of the best out
of the box toolchains I've ever encountered. But when helping me think about
computation, Go doesn't. Go's concurrency primitives don't feel like a great deal of a step forward
compared to C. I know, I know, this is crazy talk. I feel like I am missing some
great wisdom about Go, I truly do. Concurrency is really hard and Go has clearly
helped a lot of people minimize concurrency problems. But whenever I use
channels I am reminded Go does not allow me to shut my brain off, and whenever
the deadlock bug strikes, I feel that I might as well be writing C. I don't mean to disrespect Go and the great things it does, the opposite of
that! I am hoping Go delivers a bulletproof abstraction for concurrency. Until
then I've become too familiar with other tools to justify using Go for more than
incredibly niche use cases. I really hope that will change (both my mindset and Go)! |
Rust's static guarantees come at a price: You have to learn Rust to take advantage of them, which is apparently no mean feat.
> I am hoping Go delivers a bulletproof abstraction for concurrency.
Don't hold your breath. Go has always been and will always be about “good enough”, not “bulletproof”.