I don’t expect to see any actual Mesa Vulkan drivers in Rust for a few years yet. My current goal is merely to explore the possibility. When the time comes that someone does choose to write a Vulkan driver in Rust, I want us to be ready. This exploration may also be useful for informing the Rust community about language features which would make the task easier. Converting existing Vulkan drivers to Rust is an explicit non-goal at this time.
Rust seems everywhere.
“Rust seems everywhere.”
I’m surprised the compiler isn’t called oxidation or something like that.
afaik it has been named after a type of parasitic fungus, so it should rather be called “infect” or something like that.
That is also a better namesake as oxidation of iron in the long term destroys the original structure, where the parasite can and will migrate over to another host to keep on living š
Lets be honest. Rust isn’t everywhere. Languages like C and C++ on the other hand are. The infrastructure that currently runs the world is written in languages such as C and C++. And in next 10 to 20 years this won’t change. What can happen though is some of it could get rewritten in Rust. The trouble here is that still doesn’t come down to automatically all start using the Rust rewritten one. What is more likely is some new projects could be written in Rust. From scratch. And what currently seems the most likely thing to happen is for new device drivers to be written in Rust. But for this to stick we will need much more than lets say Asahi Linux. At minimum a company like Google must write and upstream device drivers for their flagship devices. And to do that in Rust. Or one of their partners to do it for them. If something like this happens. Then there is likely no turning back from Rust. But until something like that happens in my opinion Rust can be a nice choice for some new application. Especially in environments facing and serving lets say internet. Beyond that it’s just one of the languages competing and trying to make a living. Point being it would be nice to put languages like C, C++, Python … in the spotlight from time to time too. They deserve some hype too. They make all of this happen.
Python doesnāt deserve any hypeā¦ (Especially not on a blog focused on operating systems.)
That is a rather narrow view. Considering Python can be considered as being an integral part of many operating systems. Like lets say JavaScript. All in all both being just as important, enabling and used as Rust (or C, C++). Including Vulkan.
Geck,
There are pros and cons with Rust, like any other C/C++ alternative, like Java, C#, D, C–, Carbon, and yes Python.
All things aside — including syntax differences, I would say the major pain point is interoperability. It is easy to call C from Rust (and C#, D, …), but it is much harder to integrate with C++ codebases.
Both Rust and C++ wants to be the “main” in general. (High level observation, don’t have much direct experience with Rust). So they can “consume” C libraries, they can export “hooks” for C integration, but native definitions (templates especially) are behind those doors.
There seems to be some integration for essentially a small C++ subset, which excludes STL: https://docs.rs/cpp/0.4.0/cpp/macro.cpp_class.html
But that won’t be more practical, than say, using https://github.com/rdotnet/rdotnet to “integrate” R code in C#.
sukru,
I like what rust offers in terms of safety, but it’s hard to deny it is very “different”. I really like D as a more direct replacement for C/C++. It fixes some of the worst gripes developers have with C/C++ while not feeling completely alien š
It’s not surprising that Rust feels different. It’s more of the ML lineage than the C lineage.
Rust is more or less an Ocaml derivative with no garbage collector, a bit more of a lean toward the imperative side of multi-paradigm-ness and cherry-picked bits of C++ syntax to make it feel less alien to mainstream programmers.
That’s where syntactic elements like
let,match,Option,Some,None,'a, and->come from, and the compiler was originally written in Ocaml before it became self-hosting.@sukru
For Rust to make a dent anytime soon somebody big needs to commit. Google seems the obvious choice here. They tried for a while with their own kernel. Likely realizing that effort was a bit naive. Going forward. As their main competitor is Apple. And Apple has Swift. Google might get behind Rust at some point. But Google made Go. And then what is up with that. I feel that Linux can cope with Rust in regards to accepting Rust written device drivers. So i guess it’s up to Google now (and partners). To make such push. Or not. The thing i wonder is can Google hire 400 experienced Rust developers. If and when needed. Compared to 400 experienced C (or C++) developers. I somehow doubt that. Rust is not considered to be an “easy” language. The truth being most of them are like aliens would made them anyway. Still for a big company i do imagine to get behind Rust. That should come down to spending considerable resources on training. Once you are there you in my opinion do gain an advantage. As all the new web facing code written today. For that it can make sense to be done in Rust. If your company is ready for it. Due to past investments.
On the other hand if a (big) company decides OK lets do Rust. And 95% of the staff or currently used software doesn’t talk Rust. Then such company would likely fail (big).
Geck,
It depends. So far linux rust projects have been limited to using C interfaces under rust, but you don’t really get the full benefit this way since it’s all “unsafe” in rust terminology. In order to truly get the benefits of safe rust, linux would have to make significant changes to it’s APIs and deprecate unsafe C interfaces. I don’t think linux is anywhere close to ready to do this.
Well, they could hire all of rust’s original developers right from under mozilla’s nose if they wanted to. Sadly they’ll probably be laid off by mozilla eventually anyways š
Actually, I don’t think rust would be a good choice for doing web stuff (unless you mean the implementation of the browser in the way mozilla is using it).
This indeed feels like some sort of cultural thing. That could get in the way. That is Rust movement indeed feels a bit pushy from time to time. That is basically saying it’s not enough to write only device drivers in Rust. As we don’t want to use the “unsafe”. This is childish behavior. If we are talking about Linux and Rust. Best to accept the opportunity. For being able to write device drivers in Rust. You likely won’t get that elsewhere. On such level anytime soon. On top of that no C isn’t going anywhere. If you can’t cope with that. Then the whole Rust thing is still to immature to start with. And best if they sort this out on some smaller scale projects first. Then to bother projects such as Linux with it.
Geck,
Well no, it’s not childish at all, if your switching to rust merely for the syntax while not embracing it’s safety protections, you’d largely be defeating the fundamental purpose of rust.
That’s true. You gotta take what you can get. It might fall short but arguably if one’s goal is just to increase market share presence then unsafe rust code may be better than no rust code. However this goes against my personal motive in advocating for rust.
This isn’t news to anyone here, I don’t know why you keep saying this as though it’s a surprise.
I agree, although rust is more evolved than C despite being less mature.
Rust is being used for many projects already. Linux devs are extremely stubborn and TBH I didn’t expect them to embrace rust as much as they have even in the limited form that they did. I’m glad at least some of them agree it’s time to evolve past C, but I still don’t think they have the numbers to move the linux kernel beyond the common denominator of C interfaces any time soon, if ever.
@Alfman
Rust wouldn’t have added “unsafe”. If there would ever be a belief it can coexist without C. In some foreseeable future.
Geck,
Everyone including rust developers are well aware of just of just how dominant unsafe code is. That doesn’t refute the importance of safety though. Safety needs to be the goal. Merely switching the language syntax to rust without embracing safe constructs would defeat the point of rust.
If you disagree with this, then what do you consider the goal should be?
@Alfman
For a new language potentially used in future projects. It’s likely a good thing Rust was created. For having this choice. As for existing reality. Here i feel that it doesn’t really help or solve all that much. But lets give it a decade. Who knows what will happen. Maybe nothing. Maybe indeed flagship device drivers for Linux written in Rust. We’ll see.
Geck, Alfman,
I don’t think Google would need to hire 400 new engineers if they wanted to invest in Rust. On the job training is handled well inside Google (I learned Go there), and can have people switch on their own time.
And since Fuchsia OS already had significant of Rust code, they don’t even need to do that either:
https://github.com/vsrinivas/fuchsia (not an official repo).
Those being said, switching core Linux structures to Rust, and hence dropping C compatibility on those portions, also mean losing kernel contributors who don’t want to switch to Rust. Having one or two device drivers with a limited api, and not enforcing safe code is one thing. But alienating very vocal kernel developers will be a much bigger challenge.
Yes exactly. Google invested in training for employees to learn Go. Hence there are two main issues here. For Google to get behind Rust. They likely need to retire Go and train their employees to speak Rust. Then they would probably need to go against C++. On a large scale. Likely this is not exactly realistic thing to happen. But they do need a fast and memory safe language with things such as good concurrency. So it’s not like not doing anything is an option for them too. We’ll see.
Geck,
Without going into too much detail, the internal trainings actually don’t work that way. They are usually more voluntary, and then you just start using that language in your existing project, apply for internal transfers, or start a new project.
Anyway, Fuchsia was/is such an attempt for a more secure kernel. But I don’t know its fate after the recent changes.
@sukru
Thanks for the info. If migration to a new programing language is not even paid. And the motivation to do so is purely personal. Then i can imagine it could take a while. Before considerable amount of Googlers switch to Rust. And on top of that become proficient in it.
Memory Safe Languages in Android 13 – Google Security Blog
Supporting the Use of Rust in the Chromium Project – Google Security Blog
According to ISRG, Google is also funding Miguel Ojeda’s work to get Rust into the Linux kernel.
Beyond that, I remember seeing Apple looking to hire Rust developers (probably for iCloud work) a couple of years ago.
I forget who said it, but Rust is designed around the idea that there shouldn’t be room to need a lower-level language between assembly and Rust.
I highly recommend reading Rust in Perspective on that topic. Here’s the TL;DR: from the top of it:
@ssokolow
But is that enough? To really undermine C/C++ being considered an industry standard. In lets say next 10 to 20 years? In my opinion this is not enough. Rust will need to up the game. Considerably.
Geck,
It sounds like you’ve defined a criteria for success to mean that rust must replace C in a 10-20 year timeframe, but I’m afraid this definition can set it up for failure even when it’s making real progress. Rust, as with all young languages, will find the most growth in new projects. And for better or worse it will take a long time for new projects to displace old incumbent projects. Just as ancient mainframes are still around, C/C++ will almost certainly be around longer than we are.
Exactly. Just what i said.
Geck,
So we agree that rust can success as a language even if it doesn’t kill off C? That’s great since obviously legacy code bases are going to be around for a long time!
Sure. Rust can succeed or fail or a bit of both. What it likely can’t do is to obsolete C++ anytime soon. As i do imagine C++ is the main competitor ATM. Not necessarily C. As imagine the idea to rewrite things like KDE or Qt in Rust. Tiny bit of code from some larger perspective. But nearly impossible to happen anytime soon. So most of the software stacks out there will stay “unsafe” for now. Potential new ones likely need at least a decade. To mature.
Geck
Ok, but this is straw man territory since nobody is saying it will.
As I’ve consistently said, I think a transition is going to take longer than the 10 or 20 year timeline you keep mentioning. Much of the dominant unsafe software today will still be dominant by then. And I for one don’t see this as a failure of rust so much as the fact that our tech industry is one of habits that are notoriously hard to change.
Then you are not really a Rust advocate. Imagine your advocate would be OK for you to do 30 years. While claiming you are indeed innocent. What “true” Rust advocates are saying is. Rust now. Ditch C/C++. Now. I even gave you prominent examples in this discussion. Hence you saying 30 years from now. That is what “true” C/C++ advocate (and possibly Rust opponent) can for sure agree with. As that is more or less as saying DOA. Move along.
Geck,
Seriously dude, you have exactly zero standing on what I advocate for.
I don’t fit into your narrative of what a “rust advocate” should be. By extension your straw man arguments targeting this stereotype haven’t been able to the mark. Frankly I think you need to extend your worldview a bit to include people like myself rather than trying to deny the sincerity of my position.
What even is that supposed to mean?
I don’t need you to tell me what I am. Let it be known that I am a true promoter of rust. My views are formed by my own experiences and pragmatism, or what I consider to be realistic paths forward and not pie in the sky ones.
This is where you and I differ the most. Everything to you is entirely one way or the other, a binary with no shades of gray whatsoever. I’ve noticed this sort of binary philosophy keeps coming up in our discussions, not just as it pertains to rust but also in the context of open software, linux and firefox too. The real world is incredibly varied and complicated though. Not even one dimensional shades of gray are enough to capture full perspectives. There may be a temptation to collapse everything into black and white boxes, but it doesn’t do the world justice. IMHO this prevents us from being able to see things eye to eye.
I’m very here for it. If anything GPU drivers seem like a good use case. Rust’s strengths in terms of memory and thread safety sound appealing given the record of insecurity and instability in graphics stacks, and modern hardware is powerful – sacrificing a little performance for fewer crashes and vulnerabilities seems smart.
Here’s a relevant series of tweets from Asahi Lina.
You’ll want to read the whole thread, but here’s how it begins before going into detail.
Wow. That’s… even far better than I had expected actually.
After reading about Servo 2023 roadmap over at Phoronix. I feel that it’s rather safe to say C and C++ aren’t going anywhere anytime soon. Hence people at NSA and Microsoft suggesting we should just ditch this two languages. Or Google pressuring others. Feel free to do that. Put your code where your mouth is. Imagine we would really kill off languages such as C++. In such naive fashion. And lets say in ten years time from now Rust not to be universally accepted. What then? We should all use C#? Thanks but no thanks. C/C++/Rust are all fine. If you prefer one over another. Feel free to code in it. I will be watching closely on how much device drivers code written in Rust will be upstreamed to Linux in the next decade. By the mentioned companies. And that is really all i need to know at this point.
Geck,
Who are you talking to? I think you’d be hard pressed to find a single person who thinks C/C++ are going away any time soon. New work might consider new languages, but we have too much time and money vested to replace large existing code bases. Major corporations are maintaining expensive mainframes over the span of several decades and the same will apply to C for a very long time.
Among others both NSA and a prominent Microsoft exec said it’s time to move away from C/C++. You personally said a couple of times. If “unsafe” is used in Rust. Then what is the real point. Even C++ creator had to respond and defend C++ safety in a recent response. Hence who? The general buzz i guess? So if Apple is willing to give up Swift, Google to give up Go, Microsoft to give up C#. If something like that would to happen. And all would back Rust. Then sure. The industry can move away from C/C++. To Rust. But if they are not prepared to do that. Then lets get real. C/C++ will remain the industry standard.
Geck,
Yes, many of us have been saying this for many years. But at the same time it doesn’t mean that we don’t recognize the momentum that C & C++ carry.
Yes, that’s what I think. If the goal isn’t to ultimately use safe rust, then I don’t see the point in switching to rust. I think the main reason to deploy unsafe rust is to begin a transition to safe rust.
You keep saying this as though it’s unexpected, but it’s not. We already know that unsafe code will continue to be widely deployed for a very long time. It will likely be generations before we see significant change.
It’s not just the momentum C/C++ carry. It’s the industry standard. Compared to some platform specific languages out there. As for the goal being to eliminate C/C++. You can’t. At least not in foreseeable future. And i personally doubt a new solution will emerge anytime soon. Written in Rust to replace Linux as the industry standard. Or to replace some other big C++ software stack build over the past couple of decades. This just won’t happen. For this to happen at minimum Microsoft, Google and Apple would need to get fully behind Rust. But they won’t. So better to keep it real. What will happen is some portions of code will be written or rewritten in Rust. And maybe we will see some new device drivers in Linux kernel written in Rust. Here i feel that Google is under pressure. As Apple is only getting more and more vertically integrated. And if Google wants to keep up. For them vertical integration comes down to upstream Linux device drivers on the software side. And obviously they are a bit behind on the hardware side too. On software side i don’t feel some in-house project can help them. They need to get fully behind the technologies they already use extensively. That enabled them to even be a thing in the first place. If they don’t want to do it then somebody else will. We’ll see.
Geck,
These two things are not unrelated, they go together.
I’m going to start calling out this line of argument as a strawman. You keep repeating it as though it makes rust promoters like me wrong, but it doesn’t refute anything actually being said. Everyone acknowledges how much momentum C/C++ with dominant platforms. It’s not going anywhere and I’ve said so repeatedly, every post in this thread in fact. We know C is dominant and will remain so for the foreseeable future. So please let’s move on.
In my opinion there is a big difference in saying something has momentum and something is already an established standard everybody use. For majority of the code written. As for Rust promoters. They are rather open about their mission of replacing C/C++ altogether and ASAP. In my opinion this can’t work. Not due to having anything particular against Rust. I shared many opinions of mine already on why i think that in this discussion. Hence i won’t repeat them again. My advice hence would be learn C/C++/Rust. As you will likely use them all during your career in next lets say 30 years. Rust still having a long way to go to be considered on the same level as C/C++.
Geck,
The reason you are calling C a “standard” is the exact same reason I’m saying it has momentum. If it weren’t popular and didn’t have momentum, then it obviously wouldn’t serve as a industry standard. Call it whatever you want, but it’s different ways of saying the same thing.
Please speak for yourself because as a rust promoter myself I don’t think your agenda and expectations for rust are realistic.
Do you do any programming yourself? You seem to be of the mindset that marketshare is the only thing that matters. However for real world programmers things aren’t so one dimensional. We choose what to program in based on a host of factors. Naturally existing projects will put large emphasis on reusing the existing code already in production, which is often C. This isn’t a failure of rust so much as common sense. It’s very expensive to start from scratch and rewrite code regardless of the merits of a language. It’s mostly in new projects where we will have greater opportunity to fully embrace new languages, but it will take time for these projects to become mainstream especially when they’re competing with established incumbents.
I agree with you that most of the things we are saying are the same thing. But that is not necessarily equal to what the Rust promoters are saying. As for momentum and established. Here i don’t agree with you. For me the difference is huge.
Geck,
These two statements seem contradictory to me, I cannot reconcile them in a way that makes sense in the context of the discussion.
I am a rust promoter, you shouldn’t assume we all think the way you describe.
Meh.
Re: the safety of unsafe Rust. One should remember that unsafe Rust still uses the borrow checker, so it has better memory safety than C (though I can’t speak for modern C++), and if nothing else is less prone to memory leaks in the heap.