I see almost the opposite, with many new distributed systems being written in Go.
But every time I need to dig down into the source code, I quickly realize why Docker falls over all the time with weird bugs, and why Vault's high-availability backend for etcd falls over once per week, and why Kubernetes is capable of inspiring such epic love-hate relationships.
There's a ton of code in Docker where nil can sneak in, and where the types of certain data structures are harder to determine than they should be. Sometimes nil represents "none", and sometimes the empty string does. There's a bit of multithreaded stuff in Vault's etcd backend (or was) that doesn't understand the corner cases inherent in concurrency.
I'm totally convinced that these new distributed tools are awesome and a boon to our industry. I just wish that somebody had a long conversation with a good type checker and thread safety checker at critical moments during the implementation process.
This may be a classic case of the "New Jersey approach": https://www.jwz.org/doc/worse-is-better.html Software that's sufficiently innovative and which works will be forgiven odd corner cases and bugs.
Vault's documentation clearly states to not use ETCD as the HA backend.
Docker's problems stem from their bone-headed decision to start with a client/server architecture that they've been unwinding ever since. They should have started with small composable tools that integrated well with the existing infrastructure (init systems, file distribution, and security infrastructure). Instead they started with an architecture where everything goes over an HTTP socket through a daemon with high probability for contention, deadlock, and failure. None of that has anything to do with Go. They could have built that abomination in any language.
I can't speak for Kubernetes. I have not used it in anger yet.
Yes, when I reported bugs against the etcd HA backend they said they were going to add more prominent warnings to the docs, if I remember correctly. :-) I think the underlying bug comes from overly optimistic multithreading code using CSP, but I stared at the code for several hours and couldn't see how to make it unambiguously correct.
We now have our own in-house Redis "HA" backend that I wrote which appears to be rock solid in production, but which temporarily disables Vault during Redis restarts. So it's really "fake HA" but it works nicely for our use case and never requires manual intervention or embarrasses us during business hours. I refuse to set up and administer an entire Consul cluster for a single leader-election lock. Managing Consul has its own complications: https://www.consul.io/docs/guides/outage.html
> Instead they started with an architecture where everything goes over an HTTP socket through a daemon with high probability for contention, deadlock, and failure. None of that has anything to do with Go.
The Docker daemon's wire protocol suffers from a kind a of sloppy thinking about data types, in my opinion. Consider this line in a Rust Docker client: https://github.com/faradayio/boondock/blob/bf29afb0c78f8d5d6...
pub Ports: Option<HashMap<String, Option<Vec<PortMapping>>>>,
There's a lot of really foggy specifications going on in the network layer of the Docker server. It's not bad in the way that certain old Unix servers like `csvd` were bad, but I feel like Docker could be better if Go demanded more clarity about data types.
On the other hand, Docker is clearly a raging commercial success, and it actually works quite nicely (at least if you use Amazon's ECS to manage your clusters). So maybe I'm just being overly fastidious. Clearly all this new Go-based devops infrastructure is hugely successful, even if many of us get frustrated with it now and then.
Still, I really wish that more programming languages forced you to be clear about which values can be `null` and which can't. Hoare called it his "billion dollar mistake": http://lambda-the-ultimate.org/node/3186
Ultimately it's the architectural decision to couple everything that allowed them to be loosey-goosey with internal-only interfaces. Why bother specifying them thoroughly if you can update all components simultaneously and have no dependencies outside of your control? I'm sure a tighter language would have helped in the small, but their problems are categorically big problems that I believe transcend smaller and more localized failings.
My experience using Consul for the Vault backend has been pretty good. Yes, you have to manually go in and clean up old nodes after a restart, but that isn't too bad. So far (knock on wood) we haven't run into a situation where a replacement node has refused to join the cluster or the cluster has out-right failed.
That said, I do wish they would put the effort to properly integrate with Etcd. We've gone through the motions of setting up and managing a highly-available Etcd cluster for quite some time now and are more confident running it than Consul. I'd rather standardize on Etcd myself, but I'm not inclined to swim upstream. :)
Docker's faults do not come from Go, and the same goes for Kubernetes.
Rust Roadmap says this much for production use:
"Production use matters for the obvious reason: it grows the set of stakeholders with potential to invest in the language and ecosystem. To deliver on that potential, Rust needs to be part of the backbone of some major products.
Production use measures our design success; it's the ultimate reality check. Rust takes a unique stance on a number of tradeoffs, which we believe to position it well for writing fast and reliable software. The real test of those beliefs is people using Rust to build large, production systems, on which they're betting time and money.
The kind of production use matters. For Rust to truly be a success, there should be clear-cut reasons people are employing it rather than another language. Rust needs to provide crisp, standout benefits to the organizations using it."
https://github.com/aturon/rfcs/blob/roadmap-2017/text/0000-r...
Don't get me wrong, it a great, practical, engineering-oriented 90% solution kind of language; "conceptually sound" seems like computer language theory got involved, and it didn't.
None of those languages strike me as being both elegant and state of the art at the same time.
Meanwhile the "weapons for a civilized time" such as Lisp or Haskell haven't really gotten a major hold in either a Fortune 1000 company or the software giants on the West Coast.
It's like there's no correlation between "hacker points" for a programming language and the actual results delivered with that language! I'm being ironic, there isn't any. I'm open to someone proving me wrong though...
Not that this defends the very poor syntactical choices that Lisp and Haskell and their communities have done (minimal grammar is not a good thing! One-symbol names are horrible!), but a lack of popularity is not as damning as it sounds.
Ecosystem is part of technical merit, but I'd agree that in many cases (particularly non-software firms), languages aren't chosen by technical merit (including ecosystem), but for social reasons.
Last I checked, the list of publicly acknowledged production Haskell uses included several significant ones in Fortune 1000 firms, and various Lisps have seen production use at major firms, both inside and outside the software industry.
To pedantically respond to your question, note that what i said was that master programmers "won't be choosing it as their tool of choice", by which i mean that it won't be the language they dream about being able to use on their next project. Of course, if Go is the right tool for the job, a sensible and honest programmer will use it.
That's a fair point.
This is a terrifically powerful, and very unusual, advantage for a language to have. Master programmers won't be choosing it as their tool of choice. It won't be used to attack the craft's hardest problems. But it allows a huge number of people to write programs they otherwise would not have been able to write, and, conversely, a huge number of programs to be written which otherwise would not have been written. There's something rather "quantity has a quality all its own" about it. As with PHP, this is something of a mixed blessing, but it certainly puts a dent in the world.