Hacker News Reader

Comment by cwyers | Hacker News Reader

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.

Reply on news.ycombinator.com