Rust is sufficiently different that you cannot expect C developers to learn rust to the level they have mastered C in order to be working at the kernel level. It’s not going to happen.
I don’t really know too much about rust. Maybe one day I’ll actually mess around with it. But the one time I looked at a rust git repo I couldn’t even find where the code to do a thing was. It’s just different enough to be problematic that way.
So I think probably, the best way IS to go the way linus did. Just go ahead and write a very basic working kernel in rust. If the project is popular it will gain momentum.
Trying to slowly adapt parts of the kernel to rust and then complain when long term C developers don’t want to learn a new language in order to help isn’t going to make many friends on that team.
But that’s the thing where you are wrong. They clearly state they don’t want C developers to learn Rust. In the particular video posted he was saying “I want you to explain to me how this particular API works so that I can do it”
The concerns about who fixes what on a merge when the C code breaks Rust code are valid, but that’s easily fixed by gathering with the Rust developers, explaining the changes and letting them fix it.
This isn’t a disagreement. One person is stating something incorrect. You can disagree on opinion, but facts are facts. The person being referred to here isn’t asking others to learn Rust, they are just asking for more information about the already existing C code so that they can write their Rust code to interoperate with it. This misunderstanding is exactly why that developer was getting heckled on stage, and is the reason why now one has left the project. I would appreciate it if you didn’t make a misunderstanding sound like a valid opinion. Enough damage has already been done.
It doesn’t matter if you know it’s a fact, and i agree with you for the record. It’s about bringing people along with you - you catch more flies with honey than vinegar - and creating good vibes in the softwaresphere
That to me sounds like exactly the reason why developers like the above have left. They are having to take on the burden of gently letting down other devs who are angry over a simple misunderstanding. A misunderstanding that wouldn’t have happened if they had been listening or bothered to ask first before jumping to conclusions. Imagine someone heckles you on stage and you have to respond kindly. I certainly wouldn’t. If someone had listened to my talk, misinterpreted it, then heckled me over it you can bet I would be angry and would respond in kind. To then see this misinformation being spread again would drive me nuts. I can see why they left.
The bottom line for me is that Rust devs who work on this stuff for free shouldn’t be getting hounded by C devs just for asking for proper documentation that frankly they should have provided in the first place. I say this as someone who is skeptical of Rust for various reasons.
They are having to take on the burden of gently letting down other devs who are angry over a simple misunderstanding.
I feel like, if anyone would be happily willing to do that in their free time, they would have been a Politician or an HR and not a Developer.
I’m pretty n00b as a dev, but if I were to see someone misinterpreting my explanation, the most I would do is rephrase the same in a more understandable manner.
Definitely not going to resort to using “people management tactics”, specially not in an Open Source Free Work setting, where the expectation is that the other person wants the good of the project as much as I do [1].
Facts are more important than feelings, specially when written text is the medium, where the reader can, at any time, go back and re-read to make sure they are at the same page, which a responsible, non-sleepy, non-drunk person would do in such a case.
On this note, I went and re-read the above comment and I realise, the “But that’s the thing where you are wrong.” sentence is kinda useless. If the previous commenter were to have read the rest, they would realise that’s where they were wrong. Mental note to not use useless stuff like this as the first sentence in a reply, because I probably have the habit
Yes, I know I joined both circumstances, this comment thread and the condition of the Rust Linux dev. It seemed relevant to me.
as compared to a corporate setting, where if they are getting money to sit and do nothing, they will prefer that ↩︎
Yup. Often best to use phrases like ‘oh my understanding was x, am I missing something’ or ‘Wait I don’t see how you’re accounting for x, what am I missing?’ or ‘i looked at the source a few times and it seems to be indicating x, not y, am I misunderstanding the impact of z?’. Basically, people are much more willing to admit err when you are. If you start a ‘debate’ by recognizing you could be wrong you immediately soften the ground for both parties. Plus, everyone walks away feeling like ‘we’ won since we ‘beat the problem’ . Also, sometimes you actually are missing something and now when it’s explained to you you don’t feel like a jerk. Good vibe kinda shit
I’ve inserted myself into your C project because only idiots write C. Rust is the one true god, mUh MeMoRy sAfteY! Now please explain to me how C works.
That’s not what they’re asking. It’s not about how C works, it’s about how specific APIs written in C work, which is hard to figure out on your own for anyone who is not familiar with that specific code. You’ll have to explain that to any developer coming new into the project expected to work with those APIs, no matter their experience with C.
But the one time I looked at a rust git repo I couldn’t even find where the code to do a thing was.
IMO that tells more about how the project was organized and names things than the language used.
So I think probably, the best way IS to go the way linus did. Just go ahead and write a very basic working kernel in rust. If the project is popular it will gain momentum.
As the other commenter pointed out, there’s Redox. The issue is that this completly disregards an incremental approach: you have to rewrite everything before it comes usable, you can’t do it piece by piece. Currently the approach of Rust for Linux is not even to rewrite things, but to allow writing new drivers in Rust.
Trying to slowly adapt parts of the kernel to rust and then complain when long term C developers don’t want to learn a new language in order to help isn’t going to make many friends on that team.
Have you seen the conference video? That’s not just refusal to learn a new language, it’s open hostility. And it’s not the only instance, for example Asahi Lina also reported unreasonable behaviour by some maintainers just because she wrote Rust code, even when Rust was not involved.
I think the point of redox is more than just rewriting Linux in Rust. Architecturally they are very different. Redox uses the more modern microkernel approach, whereas Linux is a modular monolith. There are advantages and disadvantages to both designs. They are actually polar opposites in fact. The compromise is something called a hybrid kernel which is used by Windows NT.
This is true, but the differences go even further than that. Redox is intentionally non-posix-compliant. This means that userspace programs written for posix operating systems may or may not need patching to even compile.
Part of the philosophy of Redox is to follow the beaten path mostly, but not be afraid of exploring better ideas when appropriate.
I’m not sure. I remember seeing an example in the docs, but I can’t find it now. Actually the docs in general are a lot less opinionated than I remember them.
One thing that I did find is that the ion shell document mentions that it isn’t a posix compliant shell because they would have had to leave out a bunch of features.
RedoxOS! There’s been solid progress too, beyond just having a functional microkernel, they have many of the userspace tools/their version of coreutils, even a desktop environment already mostly implemented!
My understanding is that it shouldn’t be too bad to port some other things over as well. The main issue I had was just the lack of drivers, especially since it’s still tricky even on Linux, and the microkernel architecture (though more secure) also means there’s no way to reuse any of those from Linux
I think this overall is a better idea. I’m going to say this because, I thought I’d look into rust today. So I installed it, setup vscode to work with it etc. And it’s all up and running. I thought I would port over a “fairly simple” C# project I wrote recently as a bit of a test.
While I’ve generally had success (albeit with 30+ tabs open to solve questions I had about how to do certain things, and only making it about 20% into the task) I’m going to say that it’s different enough from C, C++ and C# (all of which I can work with) that I really don’t think it is fair to expect C developers that have day jobs and work on the kernel in their spare time to learn this. It’s fundamentally different in my opinion.
Now, I don’t condone any bad attitude and pushing away of rust developers from the project. But there’s no way they’re going to want to do anything to help which involves learning a new language. It’s just not going to happen.
Likewise, C is not a language most new developers are learning. So, I feel like over time there won’t be so much of an influx of new kernel developers and any Rust based kernel could find itself with more contributors over time and taking over as the de-facto kernel.
In terms of Redox (not looked into it yet). So long as there’s a different team working on the userspace tools. I would say the main task should be getting a solid kernel with drivers for most popular hardware etc in place. The existing GNU tools will do until there’s a kernel that is able to compete with the C one. But that’s just my opinion.
Not even, it will suffocate on its own by having the capitalists keeping their changes from each other. Like a bucket of crabs; where if one crab is about to get free the others grab onto it and pull it down.
Kernels really benefit from being “forced” to share the code changes as the GPL license, they are too tied to HW, and HW needs a lot of capital when iterating.
Permissive licenses mean faster and more widespread adoption, it’s up to project maintainers if the tradeoff is worth it. Ideally a company would realize that an open source part of their project probably isn’t radically going to affect their revenue stream, but you don’t just have to convince devs, you have to convince the suits and lawyers, and they will tell you to just build your own rather than give up any precious IP.
Hey you guys with 20-30 years of experience doing a single thing very well. Let’s nullify most of that skillset and replace it with a thing we’re good at.
Don’t worry, we will teach you.
They’re not technically wrong about Rust being a better choice for a kernel, of course. They’re just incredibly misinformed about the social hurdles they need to climb over for it to happen.
Honestly, if anyone has become a master in C, they can become a rust master in short order. It’s different, but not THAT different. The roots are the same.
Just go ahead and write a very basic working kernel in rust.
I don’t get this stance, really. If I want to write a driver in Rust I should start by creating a completely new Kernel and see if it gains momentum? The idea of allowing Rust in kernel drivers is to attract new blood to the project, not to intentionally divert it to a dummy project.
Rust is sufficiently different that you cannot expect C developers to learn rust to the level they have mastered C
If you watch the video, no one asked anything from the C developers other than documentation. They just want to know how to correctly make the Rust bindings.
Note that Rust is not replacing C code in the Kernel, just an added option to writing drivers.
Has a much more C-style syntax, except much more refined from the years of hindsight. The catch? No corporate backing, didn’t jump on the “immutable by default” trend when functional programming evangelists said for loops are a bad practice and instead we should just write recursive functions as a workaround, memory safety is opt-in (although “safe by default” can be done by starting your files with @safe:), some of the lead devs are “naive centrists” who want to “give everyone a chance at coding even if they’re bad people (nazis)”, implementing new changes to the lang has slowed down significantly up until the departure of Adam D Ruppe and the drama surrounding it, etc.
“safe by default” can be done by starting your files with @safe:
Last time I heard about that it was much more limited than Rust, for example it even disallowed taking references to local variables. Has something changed since then?
D has many memory safety features. For local variables, one should use pointers, otherwise ref does references that are guaranteed to be valid to their lifetime, and thus have said limitations.
For local variables, one should use pointers, otherwise ref does references that are guaranteed to be valid to their lifetime, and thus have said limitations.
Should I take this to mean that pointers instead are not guaranteed to be valid, and thus are not memory safe?
Pointers are not guaranteed to be safe. DIP1000 was supposed to solve the issue of a pointer referencing to a now expired variable (see example below), but it’s being replaced by something else instead.
int* p;
{
int q = 42;
p = &q;
}
writeln(*p); //ERROR: This will cause memory leakage, due to q no longer existing
Here’s what I think. Both opinions are correct.
Rust is sufficiently different that you cannot expect C developers to learn rust to the level they have mastered C in order to be working at the kernel level. It’s not going to happen.
I don’t really know too much about rust. Maybe one day I’ll actually mess around with it. But the one time I looked at a rust git repo I couldn’t even find where the code to do a thing was. It’s just different enough to be problematic that way.
So I think probably, the best way IS to go the way linus did. Just go ahead and write a very basic working kernel in rust. If the project is popular it will gain momentum.
Trying to slowly adapt parts of the kernel to rust and then complain when long term C developers don’t want to learn a new language in order to help isn’t going to make many friends on that team.
But that’s the thing where you are wrong. They clearly state they don’t want C developers to learn Rust. In the particular video posted he was saying “I want you to explain to me how this particular API works so that I can do it”
The concerns about who fixes what on a merge when the C code breaks Rust code are valid, but that’s easily fixed by gathering with the Rust developers, explaining the changes and letting them fix it.
You could alternatively phrase “But that’s the thing where you are wrong” as “But here’s the crux of why I disagree”, it’s a bit more personable
This isn’t a disagreement. One person is stating something incorrect. You can disagree on opinion, but facts are facts. The person being referred to here isn’t asking others to learn Rust, they are just asking for more information about the already existing C code so that they can write their Rust code to interoperate with it. This misunderstanding is exactly why that developer was getting heckled on stage, and is the reason why now one has left the project. I would appreciate it if you didn’t make a misunderstanding sound like a valid opinion. Enough damage has already been done.
It doesn’t matter if you know it’s a fact, and i agree with you for the record. It’s about bringing people along with you - you catch more flies with honey than vinegar - and creating good vibes in the softwaresphere
That to me sounds like exactly the reason why developers like the above have left. They are having to take on the burden of gently letting down other devs who are angry over a simple misunderstanding. A misunderstanding that wouldn’t have happened if they had been listening or bothered to ask first before jumping to conclusions. Imagine someone heckles you on stage and you have to respond kindly. I certainly wouldn’t. If someone had listened to my talk, misinterpreted it, then heckled me over it you can bet I would be angry and would respond in kind. To then see this misinformation being spread again would drive me nuts. I can see why they left.
The bottom line for me is that Rust devs who work on this stuff for free shouldn’t be getting hounded by C devs just for asking for proper documentation that frankly they should have provided in the first place. I say this as someone who is skeptical of Rust for various reasons.
I feel like, if anyone would be happily willing to do that in their free time, they would have been a Politician or an HR and not a Developer.
I’m pretty n00b as a dev, but if I were to see someone misinterpreting my explanation, the most I would do is rephrase the same in a more understandable manner.
Definitely not going to resort to using “people management tactics”, specially not in an Open Source Free Work setting, where the expectation is that the other person wants the good of the project as much as I do [1].
Facts are more important than feelings, specially when written text is the medium, where the reader can, at any time, go back and re-read to make sure they are at the same page, which a responsible, non-sleepy, non-drunk person would do in such a case.
On this note, I went and re-read the above comment and I realise, the “But that’s the thing where you are wrong.” sentence is kinda useless. If the previous commenter were to have read the rest, they would realise that’s where they were wrong. Mental note to not use useless stuff like this as the first sentence in a reply, because I probably have the habit
Yes, I know I joined both circumstances, this comment thread and the condition of the Rust Linux dev. It seemed relevant to me.
as compared to a corporate setting, where if they are getting money to sit and do nothing, they will prefer that ↩︎
Yup. Often best to use phrases like ‘oh my understanding was x, am I missing something’ or ‘Wait I don’t see how you’re accounting for x, what am I missing?’ or ‘i looked at the source a few times and it seems to be indicating x, not y, am I misunderstanding the impact of z?’. Basically, people are much more willing to admit err when you are. If you start a ‘debate’ by recognizing you could be wrong you immediately soften the ground for both parties. Plus, everyone walks away feeling like ‘we’ won since we ‘beat the problem’ . Also, sometimes you actually are missing something and now when it’s explained to you you don’t feel like a jerk. Good vibe kinda shit
Have you ever tried catching flies? Vinegar works better than honey, after all, flies eat shit.
I see your point, but in this case I feel OP was misinterpreting the situation
I’ve inserted myself into your C project because only idiots write C. Rust is the one true god, mUh MeMoRy sAfteY! Now please explain to me how C works.
LMAO
That’s not what they’re asking. It’s not about how C works, it’s about how specific APIs written in C work, which is hard to figure out on your own for anyone who is not familiar with that specific code. You’ll have to explain that to any developer coming new into the project expected to work with those APIs, no matter their experience with C.
IMO that tells more about how the project was organized and names things than the language used.
As the other commenter pointed out, there’s Redox. The issue is that this completly disregards an incremental approach: you have to rewrite everything before it comes usable, you can’t do it piece by piece. Currently the approach of Rust for Linux is not even to rewrite things, but to allow writing new drivers in Rust.
Have you seen the conference video? That’s not just refusal to learn a new language, it’s open hostility. And it’s not the only instance, for example Asahi Lina also reported unreasonable behaviour by some maintainers just because she wrote Rust code, even when Rust was not involved.
I think the point of redox is more than just rewriting Linux in Rust. Architecturally they are very different. Redox uses the more modern microkernel approach, whereas Linux is a modular monolith. There are advantages and disadvantages to both designs. They are actually polar opposites in fact. The compromise is something called a hybrid kernel which is used by Windows NT.
This is true, but the differences go even further than that. Redox is intentionally non-posix-compliant. This means that userspace programs written for posix operating systems may or may not need patching to even compile.
Part of the philosophy of Redox is to follow the beaten path mostly, but not be afraid of exploring better ideas when appropriate.
What part of posix is redox trying to get away from?
I’m not sure. I remember seeing an example in the docs, but I can’t find it now. Actually the docs in general are a lot less opinionated than I remember them.
One thing that I did find is that the ion shell document mentions that it isn’t a posix compliant shell because they would have had to leave out a bunch of features.
Makes sense. Posix was created a long time ago and there are most probably some features that could be changed
RedoxOS! There’s been solid progress too, beyond just having a functional microkernel, they have many of the userspace tools/their version of coreutils, even a desktop environment already mostly implemented!
My understanding is that it shouldn’t be too bad to port some other things over as well. The main issue I had was just the lack of drivers, especially since it’s still tricky even on Linux, and the microkernel architecture (though more secure) also means there’s no way to reuse any of those from Linux
They are actually looking into using the Linux Kernel for modular drivers in a really interesting way.
Same with Ironclad kernel and OS written in Ada Programing language. Nice to see these systems development
Gives me vibes of a second iteration of the OS writing boom. Though this time, the kernel mostly.
I think this overall is a better idea. I’m going to say this because, I thought I’d look into rust today. So I installed it, setup vscode to work with it etc. And it’s all up and running. I thought I would port over a “fairly simple” C# project I wrote recently as a bit of a test.
While I’ve generally had success (albeit with 30+ tabs open to solve questions I had about how to do certain things, and only making it about 20% into the task) I’m going to say that it’s different enough from C, C++ and C# (all of which I can work with) that I really don’t think it is fair to expect C developers that have day jobs and work on the kernel in their spare time to learn this. It’s fundamentally different in my opinion.
Now, I don’t condone any bad attitude and pushing away of rust developers from the project. But there’s no way they’re going to want to do anything to help which involves learning a new language. It’s just not going to happen.
Likewise, C is not a language most new developers are learning. So, I feel like over time there won’t be so much of an influx of new kernel developers and any Rust based kernel could find itself with more contributors over time and taking over as the de-facto kernel.
In terms of Redox (not looked into it yet). So long as there’s a different team working on the userspace tools. I would say the main task should be getting a solid kernel with drivers for most popular hardware etc in place. The existing GNU tools will do until there’s a kernel that is able to compete with the C one. But that’s just my opinion.
Good news there’s a project that aims to implement Unix in Rust called Redox and it’s already a good enough project for studying microkernel design
Bad license though
Good license to capitalists.
Not even, it will suffocate on its own by having the capitalists keeping their changes from each other. Like a bucket of crabs; where if one crab is about to get free the others grab onto it and pull it down.
Kernels really benefit from being “forced” to share the code changes as the GPL license, they are too tied to HW, and HW needs a lot of capital when iterating.
Permissive licenses mean faster and more widespread adoption, it’s up to project maintainers if the tradeoff is worth it. Ideally a company would realize that an open source part of their project probably isn’t radically going to affect their revenue stream, but you don’t just have to convince devs, you have to convince the suits and lawyers, and they will tell you to just build your own rather than give up any precious IP.
Yeah, the Rust guys’ proposition is roughly this:
They’re not technically wrong about Rust being a better choice for a kernel, of course. They’re just incredibly misinformed about the social hurdles they need to climb over for it to happen.
Honestly, if anyone has become a master in C, they can become a rust master in short order. It’s different, but not THAT different. The roots are the same.
I don’t know. Rust seems like a better C++ to me rather than a better C. Plain C is a very simple language.
That’s fair, but my point still stands.
I don’t get this stance, really. If I want to write a driver in Rust I should start by creating a completely new Kernel and see if it gains momentum? The idea of allowing Rust in kernel drivers is to attract new blood to the project, not to intentionally divert it to a dummy project.
If you watch the video, no one asked anything from the C developers other than documentation. They just want to know how to correctly make the Rust bindings.
Note that Rust is not replacing C code in the Kernel, just an added option to writing drivers.
That’s why I often recommend D instead.
Has a much more C-style syntax, except much more refined from the years of hindsight. The catch? No corporate backing, didn’t jump on the “immutable by default” trend when functional programming evangelists said
forloops are a bad practice and instead we should just write recursive functions as a workaround, memory safety is opt-in (although “safe by default” can be done by starting your files with@safe:), some of the lead devs are “naive centrists” who want to “give everyone a chance at coding even if they’re bad people (nazis)”, implementing new changes to the lang has slowed down significantly up until the departure of Adam D Ruppe and the drama surrounding it, etc.Last time I heard about that it was much more limited than Rust, for example it even disallowed taking references to local variables. Has something changed since then?
D has many memory safety features. For local variables, one should use pointers, otherwise
refdoes references that are guaranteed to be valid to their lifetime, and thus have said limitations.Should I take this to mean that pointers instead are not guaranteed to be valid, and thus are not memory safe?
Pointers are not guaranteed to be safe. DIP1000 was supposed to solve the issue of a pointer referencing to a now expired variable (see example below), but it’s being replaced by something else instead.
int* p; { int q = 42; p = &q; } writeln(*p); //ERROR: This will cause memory leakage, due to q no longer existingSo I guess they are forbidden in
@safemode?Do you know what is the replacement? I tried looking up DIP1000 but it only says “superceded” without mentioning by what.
This makes me wonder how ready D is for someone that wants to extensively use
@safethough.https://github.com/ZILtoid1991/newxml/tree/main
This XML parser of mine uses safe by default.
It also seems to require a GC though…