Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).
Go is woefully missing some really key features, which you encounter when tuning it for high performance. My list of grievances:<p>- Dep handling was never considered. Makes sense given Google's monorepo but thats not how the world works.<p>- Stdlib just loosely wraps posix features with many C flags copied verbatim. These APIs are old and could use a refresh but Go never bothered.<p>- No easy way to construct arenas/pools. Once you go down this route you have a great headache of releasing in the right places. The GC doesn't cut it, you need pools sometimes<p>- Debugging basically doesn't work on some OSes. No easy way to attach gdb and see what's happening. Doubly so if you use Cgo<p>- Similarly, Go doesnt bother to hide the differences of different OSes. Up to you as the programmer. Again not surprising for Google's all Linux world. If everything is Linux then OS difference doesnt matter. But even Python does a better job here.<p>- Logging is poorly thought out as evidenced by multitude of third-party log packages. Anemic compiler means you can't get verbose logging without paying a performance penalty.<p>- No RAII. Defers are a lazy attempt at this, but they're not even close to being as good as RAII. This is probably the biggest point where you realize Go can't dethrone C++<p>- Tricky Close() semantics force you to architect entire program around who will close() things at end of their lifetime. Lots of terrible hacks ensue when people build something that works but realize close ownership is ambiguous and rightfully don't want to rebuild it all<p>- Channels don't have a good way to deal with errors. You're forced to come up with an ad hoc solution to deal with your graph of goroutines/channels when one node errors<p>- No supervision tree. Erlang existed far before Go but they didn't learn from this key feature. But it would greatly enhance Go to have it<p>- Hacky reflection semantics that cause subtle runtime bugs when a JSON struct field's name starts with a lowercase letter. And of course, there are no generics, the larger issue here.<p>I was hopeful that Go would fix some of these things before it went 1.0 and locked in its syntax. Sadly that didn't happen as it was likely already locked in at Google. Go is ultimately kind of brain dead, useful for some very particular features but not so compelling that it can replace any other language.
Things I love about go:<p>1. Probably the best ecosystem out there.<p>2. Go routines<p>3. (Enabled by (2) actually) `defer`<p>4. That I can add interfaces implementations to structs I don’t own<p>5. No exceptions.<p>Actually (5) is one of the few things I don’t like about Haskell.<p>If Go had ADTs and generics it would easily be my favorite language.<p>Edit: and of course the channels.<p>Edit2: yeah, i have no idea why i connected (2) and (3). Had just woken up. No idea what I was thinking.
> every single cloud company has critical components of their cloud infrastructure implemented in Go<p>And this is how the "network effect" propagates. As the customers of cloud services also begin to experiment in Golang. And discover the holistic ecosystem of distributed systems packages.<p>Even Blizzard with its massive C++ codebase is gaining converts<p><a href="https://youtu.be/Az5F4lwSljI?t=23m50s" rel="nofollow">https://youtu.be/Az5F4lwSljI?t=23m50s</a>
way to go, Go!<p>Just to accentuate some of the neat things you can do with Go, watch: 'Can you write an OS Kernel in Go?' from the Golang UK Conf.
<a href="https://www.youtube.com/watch?v=8T3VxGrrJwc" rel="nofollow">https://www.youtube.com/watch?v=8T3VxGrrJwc</a>
I find myself wondering how important the "fun facts" are in this fascinating thread about Go:<p><a href="https://twitter.com/pasiphae_goals/status/923820615022399488" rel="nofollow">https://twitter.com/pasiphae_goals/status/923820615022399488</a>
A post earlier this year by Rob Pike, celebrating ten years of Go:<p><a href="https://commandcenter.blogspot.com/2017/09/go-ten-years-and-climbing.html" rel="nofollow">https://commandcenter.blogspot.com/2017/09/go-ten-years-and-...</a>
I use golang since 2010. My only complaint is that they dropped gxui. So I use golang mainly for cli utilities. The other options (I do not like javascript) are ill-maintained. For me it is more important than generics.
For me Go is amazing, is my first language where I don't need a virtual machine or interpreter to compile to machine code, C++ is OK but not for day to day web.<p>Changing something then having to wait 40 seconds for java to recompile drive me crazy, also same for tests. Yes would love to have a package system, but is coming.
Can you do something about Golang's performance on Arm servers? It seems to be terrible compared to x86 performance:<p><a href="https://blog.cloudflare.com/arm-takes-wing/" rel="nofollow">https://blog.cloudflare.com/arm-takes-wing/</a><p>This would have a positive impact on Google, too, as the more server chip competition there is, the cheaper it will be for Google to buy those chips for its cloud services.