5 ms·

No, they meant Go was intended as a systems language. Rob Pike: http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html?m=1 http://commandcen

by cwyers 11y ago

No, they meant Go was intended as a systems language. Rob Pike: http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html?m=1 http://commandcenter.blogspot.com/2012/06/less-is-exponentia... > I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. > We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care. Read the whole thing if you have time - Pike talks about how they were trying to write a language that filled a role similar to C and C++. So they came up with a compiled, statically typed language.

jasode 11y ago
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.
- cwyers 11y ago
  I don't think Rust is designed for those use cases either, honestly.
  - qznc 11y ago
    You don't think Rust is suitable for writing device drivers or realtime stuff? Why is that?
    - cwyers 11y ago
      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 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++.
      - istvan__ 11y ago
        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.
      - steveklabnik 11y ago
        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.
- 0xFFC 11y ago
  C++ for Linux device driver? Am I missing something?
  - FreeFull 11y ago
    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).
rakoo 11y ago
> 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.
rdtsc 11y ago
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.
- tedunangst 11y ago
  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.
istvan__ 11y ago
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 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.

by cwyers 11y ago

jasode 11y ago

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.

cwyers 11y ago
I don't think Rust is designed for those use cases either, honestly.
- qznc 11y ago
  You don't think Rust is suitable for writing device drivers or realtime stuff? Why is that?
  - cwyers 11y ago
    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 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++.
    - istvan__ 11y ago
      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.
    - steveklabnik 11y ago
      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.
0xFFC 11y ago
C++ for Linux device driver? Am I missing something?
- FreeFull 11y ago
  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).

rakoo 11y ago

> 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.

rdtsc 11y ago

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.

tedunangst 11y ago
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.

istvan__ 11y ago

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 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.