I've read that and I disagree with your interpretation.

Google was using C++ in the "systems management" of their datacenters. Rob Pike is using a Google-idiosyncratic definition of "systems".

I do believe that Google did use C++ for many classic low-level scenarios (e.g. writing custom Linux device drivers, failover code, etc) but they were also using C++ for "high-level" systems orchestrations and batch jobs. It's the "high-level" uses of C++ that that Rob Pike successfully addressed with Golang.

I'm saying a large percentage of programmers outside the Google bubble think of "systems" as low-level stuff like realtime embedded, low-latency device drivers, etc that require zero-cost abstractions. Rob Pike did not design Go's semantics & runtime for those use cases.

C++ for Linux device driver? Am I missing something?

It is possible to write a Linux device driver in C++, although most will be written in C (and I think all the ones that actually come with the kernel are in C).

I don't think Rust is designed for those use cases either, honestly.

You don't think Rust is suitable for writing device drivers or realtime stuff? Why is that?

Well, no, that's not what I said. I said it's not designed for those use-cases -- if Go is 'designed for systems programming at Google', then Rust is 'designed for systems programming at Mozilla', which if anything is further from the metal than a lot of what happens at Google. I think Rust made a lot of design decisions that probably makes it better for those use cases than Go. But there have been people who have tried to write low-level OS code in Rust and found some significant pain points:

http://scialex.github.io/reenix.pdf

Now, some people who know a lot more about Rust than I do have said these are problems that can be solved in Rust, and I have no reason to disbelieve them. But I don't think writing that sort of stuff was a design focus of the language, compared to writing the sort of large user-space applications that are currently written in C and C++.

Fun story about the history of that paper:

We used to think Rust needed a runtime to be safe, so it had one. There was an attribute, #[no_std], which would not link in the runtime, and also get rid of the standard library. As such, the decision was made for std that it should just panic on OOM, because you'd be clearly writing an application, and generally, you don't even seen OOM in that use-case.

Fast forward a few years, and we remove the runtime, and suddenly, it's not impossible to use std to build things like operating systems. So now, people use it this way, and see that it might not be well-suited to that purpose.

So in some ways, the claims put forth by that paper are historical accidents. Which doesn't mean that they're not interesting, or valid, it's just that an additional possibility came up, which challenged a design assumption.

We absolutely do care about the lowest-level case with Rust, and had a number of discussions at the workweek (Mozilla all-hands, full week of meetings) to talk about how to improve the "I'm writing a kernel" case with Rust.

I think what matters is: outside the organization where the certain language was invented what is the the most users use it for.

Aka: outside Google what is Go used for? Mostly web related project and low level IO, databases, data stores, etc.; based on the popular Go projects on Github, if somebody has time it would be good to see some stats on this

outside Mozilla what is Rust used for? This is a more tricky question because the most programmers I know of do not consider a language for anything before 1.0. Rust 1.0 just got released recently so they have years to go to have relevant stats about the usage patterns.

Just to be clear: it would not be possible to attempt to write that paper in Go. That is what people mean.

That one single statement "systems programing language" bit Go more than anything probably as far as expectations and the number of words generated in blog posts talking about Go.

It was funny that the first response to "Oh but it can't compete with C" was "Well, we meant systems programming language to be more like back-end web servers not your traditional systems programming..." Now, had that come from other people I might have believed, but I cannot imagine Ken and Rob had no idea what a systems programming language was and just got a little confused.

But based on that blog post it is clear that they did want a better C or better C++.

In the end they did a mini-pivot and instead got a better Python|Node.js|Ruby + types + better concurrency + easier_dependencies_and_deployment, which worked out pretty well. So they see a lot of developers from those ecosystem jumping to them. But anyone familiar with an advanced type system (Java, C#, C++, ...) might not get as excited about. interface{} as void* -- yeah no thanks, this is not 1999 anymore.

It's not remarkable to me that Ken and Rob would consider whatever language all that stuff in /usr/bin is written in to be a system language. "The language that runs in supervisor mode" seems like a pretty narrow definition.

> they were trying to write a language that filled a role similar to C and C++

... as used in Google, ie not necessarily the low-level stuff that drives a network card, but more the high-level systems (as in, server software) like the one that powers dl.google.com (see the famous rewrite by Brad Fitzpatrick). This is not a task that was necessarily best suited to C nor C++, so they wanted a better language for this.

I don't think it is a big surprise. C++ programmers like features that Go does not have. Ruby/Python guys like out of the box performance that Ruby/Python does not have. :)

A good summary of Go here:

https://news.ycombinator.com/item?id=9267211

As a systems language Go is ok, as a business domain language Go is subpar based on the current state of the language. CSP makes Go great for Ruby/Python guys because these features (channels, go routines) solves lots of problems those languages do not have a great solution to.