3 ms·
Not sure I can really agree with this. I will preface the rest of this with saying I did have a good 4 years professional experience with Golang, more if you co
by jpgvm 7y ago
Not sure I can really agree with this. I will preface the rest of this with saying I did have a good 4 years professional experience with Golang, more if you count my current gig with does involve working with it occasionally unfortunately.
It's main selling point is ubiquitous support for concurrency via a green-threaded runtime and standard library.
You could additionally argue compilation speed is very good.
Also it has a quite low latency GC, I think that is also an important feature of Go.
However that is pretty much where its pros stop and its cons begin.
Arguing for "simplicity" sort of falls apart given its rather expansive runtime. It's not really "simple" in the way C is and it's not "easy" in the same way Python/Ruby are.
I would instead say it's "easy to learn" but I would also go on to say that it's very hard to master because of the complex interactions between channels, strange behaviours that can be encountered with cgo. Sharp edges in the standard library is also another big one that places mastery out of the reach of most. I think this ends up being a net con as the investment required to reach mastery in Go is much higher than what is required to each competency in a language with a better force multiplier.
Lack of a reasonable type system given it's vintage, primarily no provisions for generics despite in-built generic data structures being the very foundation of the language - just not implementable in usercode.
Really poor quality packaging and distribution for the majority of its lifespan, even now Go modules have more sharp edges than is reasonable.
Go is plain awful from an expressivity perspective which results in verbose code and by extension impacts readability of business logic in particular.
I could go on but the reality is that it's not a pleasant language to use beyond it's core domain of shuffling bytes from one socket to another.
If you need low memory footprint + concurrency + performance then you probably want Rust. Higher upfront learning cost but much more pleasant thereafter.
If instead you want a workhorse language for less constrained environments I recommend Kotlin. It's a JVM language so there is some investment required to get your head around that ecosystem but in turn - huge return with access to full JVM platform.
Kotlin has all the features Go should have been built with, gets away with minimal faults despite great Java compat. Is fast enough for almost anything you might want to do. Great type system including awesome generics, including reified generics, data classes etc.
The only thing I wish Kotlin had that Go does is a fully async/coroutine aware standard library.
Rust is getting this with asyncstd but it could be a while before Kotlin gets the same.
In summary despite spending quite some years learning Go, writing some big and high performance programs in it I didn't learn to love it, I grew to find it tiresome and despite all my investment don't pick it up to solve problems except in very specific scenarios.