Comment by jasode | Hacker News Reader

Comment by jasode | Hacker News Reader

Go and Rust competes in the narrow space of, "what's The Next Interesting Thing to learn?"

In that narrow sense, it doesn't matter that the underlying semantics and runtimes of Go and Rust are targeted for different use cases. They get lumped together in the same conversation because people have a vague sense that something... (newer programming language, newer database engine, newer CSS templating, etc)... will make their project better. In that nebulous cloud of possible future benefits, it's understandable for people to mention both in the same conversation. However once people get past the unspecified idea of "better" and actually analyze (i.e. write concrete programs) the real costs & benefits, the differences of Go & Rust will reveal themselves. People will realize that Go is inappropriate to write a 60 fps graphics rendering engine and likewise, Rust is inappropriate to write quick scripts for Google-scale cloud orchestrations.

One other reason that Go is mentioned along with Rust is that Google used the adjective "systems" to describe it. "Go is intended as a systems language". Unfortunately, a lot of folks didn't realize that Google was using an idiosyncratic definition of "systems" to mean a programming language to help the management of their datacenters. To others, "systems language" means writing operating systems, device drivers, embedded chips, etc. There was a nuance that got lost and it ended up muddying the discussion. The phrases, "Go is a systems language", and "Rust is a systems language" look the same but they mean different things.

No, they meant Go was intended as a systems language. Rob Pike:

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.

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.

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

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.

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.

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

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

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

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.

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.

Reply on news.ycombinator.com