Go was designed for a very narrow set of constraints that match what goes on in Google. From my perspective it’s one of the very few general purpose languages (along with erlang) that were designed to specifically match one company’s needs, rather than grown semi-organically.
If your needs align with that somewhat, you might want to use Go. If your needs are different, you should stay the hell away from it.
> From my perspective it’s one of the very few general purpose languages (along with erlang)
Maybe I'm missing something, but since when Erlang is a general purpose language? Erlang was designed for a quite narrow niche and feels very well there, but Go... well, honestly, I don't understand what Go was designed for.
One of the clear design needs for go was “you have a crap ton of code you need to write, and you need to aggressively parallelize the work over a bunch of mixed skill devs, without the worst ones fucking it up, and without the best going off the reservation and making something that can’t be understood later.”
Personally that sounds like my own hell, but that’s the world Google lives in.
Despite Pike's appalling contempt in https://talks.golang.org/2012/splash.article I'm not convinced this is a problem Google actually has. They're faced with perverse incentives but they're far from stupid.
Maybe with the exception of the old JS callback hell I have never seen any other language deteriorate code into spaghetti projects more quickly than Go with channel and duck typing abuses.
I think if it does a very poor at keeping "the worst ones" from "fucking it up".
I’m using general purpose in a very soft and squishy way. I generally mean languages that can comfortably do a few different things and not the hyper specialized cases like Matlab.
I don't think is fair to compare Go to Erlang. Erlang is really designed to do 4 things: concurrency, low latency, fault tolerance and distributed systems and it shines there. Go is indeed a general purpose language to me.
There are many reasons to learn Go but even the author didn't emphasise on performance because it is not. There are many dynamic compilers which produce faster binaries than go. I think the best reasoning in the blog was A-Grade standard lib. That is something not all available new languages enjoy. But Go from the early days had good standard lib support. Go comes with batteries but then so does Chicken scheme.
From generics to sets and several others, I think there are enough reasons to consider that go does not "come with batteries", especially when you compare it with almost any other modern (>90s) language.
14 comments
[ 3.2 ms ] story [ 44.9 ms ] threadIf your needs align with that somewhat, you might want to use Go. If your needs are different, you should stay the hell away from it.
Maybe I'm missing something, but since when Erlang is a general purpose language? Erlang was designed for a quite narrow niche and feels very well there, but Go... well, honestly, I don't understand what Go was designed for.
Personally that sounds like my own hell, but that’s the world Google lives in.
I think if it does a very poor at keeping "the worst ones" from "fucking it up".
For those in the 'Enterprise computing' business, learning a little Go won't be harmful.