3 ms·
Or maybe it’s because we’ve tried golang repeatedly, been frustrated the entire way, and are desperately hoping that someone will help us understand what people
by stouset 9y ago
Or maybe it’s because we’ve tried golang repeatedly, been frustrated the entire way, and are desperately hoping that someone will help us understand what people actually see in the language.
I work and live in SF. Of people I talk to in real life who’ve used golang for non-Google, non-toy projects, sentiment is at least 4-to-1 against it, and in my anecdata that ratio generally increases as people use it for longer.
The one consistent praise I’ve heard that seems genuine (and that I don’t entirely disagree with) is that it’s easy for a new team member to jump on board and be productive. Which sounds great, but if this is what you’re optimizing for at (in my opinion) the expense of nearly everything else, then it seems like a self-fulfilling prophecy of high turnover.
- matt_m 9y agoSure, I think I can explain some of what people might see in it. Obviously its strengths/weaknesses will depend on what language you compare it to, the article mentioned Java so I'll use that. 1) Value types - in Java if you want an array of objects of a non-primitive type, each one will be individually heap allocated (with some extra per-object overhead) and stored as an array of pointers (may change in Java 10). Go allows objects to be linear in memory with no overhead. 2) Slices everywhere - in Go slices are the default list representation. This allows any API that takes a list of objects to be passed a range of a bigger list, without copying/allocating. 3) Low-latency garbage collector - I believe Go has one of the lowest latency garbage collectors in common use (sub-1ms pauses). I realize Java has several options, but I think Go's is lower latency than all but some commercial/exotic ones like Zing. This is not saying the GC is better all around, just on latency. It's also relatively easy to minimize allocations in Go due to value types. 4) Low-overhead concurrency - lightweight tasks with no blocking/non-blocking dichotomy in APIs. But threads can scale up a lot, so this might not be a big benefit depending on the application. 5) Interior pointers - you can lay out structures linearly, and still use interior pointers. Also, you can use them as interfaces without allocating any 'boxed' objects. There's probably more, but these are the things that come to mind right now. Looking back on this list, all of them are performance related. So if an application isn't performance sensitive in any of these ways I guess it would be understandable that someone might not see much in it, compared to a language with a higher learning curve but a lot of conveniences like Kotlin. Things like capitalization don't seem that big an issue though... maybe because Go is a simple language the tooling is already pretty good, and you can easily rename to upper/lower case in an IDE like GoLand. For people unfamiliar with Go and want to see something more than hello world, I think an interesting project to look at is https://github.com/fogleman/pt https://github.com/fogleman/pt. It's not enormous but not trivial either and makes use of interfaces, goroutines etc. The author's other projects are great too.