Linux people doing Linux things, it seems.
Here’s the thing: you’re not going to force all of us to learn Rust.
That’s precious coming from Linux developers.
I am a heavy Linux user. I run multiple microservices on multiple headless devices all Linux.
This sounds like every fucking Windows user you’ll ever encounter.
“Here’s the thing: you’re not going to force all of us to learn to use Linux.”
So, yeah…
It’s just their ego showing through.
It basically now comes down to the current devs depending on new Rust devs for anything that interacts with Rust code.
They could just work together with Rust devs to solve any issues (API for example).
But their ego doesn’t allow for it. They want to do everything by themselves because that’s how it always was (up until now).
Sure, you could say it’s more efficient to work on things alone for some people, and I’d agree here, but realistically that’s not going to matter because the most interactivity that exists (at the moment) between Rust and C in Linux is… the API. Something that they touch up on once in a while. Once it’s solid enough, they don’t have to touch it anymore at all.
This is a completely new challenge that the Linux devs are facing now after a new language has been introduced. It was tried before, but now it’s been approved. The only person they should be mad at is Linus, not the Rust devs.
I finally watched the talk today and that wasn’t what I thought he meant. What I thought he was getting at was that the rust parts of the kernel interact with lots of other modules written by people who don’t know rust. When those C modules change their semantics in ways that break the rust code, they can’t go fix it because they don’t know rust. In fact, whenever they make a change, they don’t even know if they broke some rust module, because they don’t understand the rust code well enough. And this is something that everyone is going to have to live with for the foreseeable future, because you can’t force all those other kernel hackers to learn rust.
If you are that good in C(pp), I guess understanding rust code of a module is not sooo hard… I mean, I learned what I know about C from reading stuff in the Kernel that made my embedded Linux project not working.
But I have yet to read rust.
It’s a whole different ballgame. I’ve written a good amount of C and C++ in my day. I’ve been learning Rust for a year or so now. Switching between allocating your own memory and managing it, and the concept of “Ownership” https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html is just something many devs set in their ways aren’t willing to do.
I understand where they’re coming from, I’ve gone through massive refactors with new tech in my career. I think this approach needs to be more methodical and cautious than it is, but I don’t think they are correct in the end result. I think a memory-safe language is the way to go, and it needs to happen.
This to me is a classic software project with no manager and a bunch of devs arguing internally with no clear external goals. There needs to be definitive goals set over a timeline. If someone doesn’t agree after a consensus is reached they can leave the project. But as of now I think as others have said this is 80% infighting, 20% actual work that’s happening.
Switching everything from C to Rust because it has better memory safety is more akin to changing languages from English to Esperanto because it has gender neutral pronouns and other cool features. Maybe it’s a good idea, but it’s understandable that some people are reluctant.
Maybe it’s a good idea, but it’s understandable that some people are reluctant.
I understand that position. I also understand how the words and phrases that the C community has used to communicate with the Rust community seems to be completely dismissive, not just reluctant.
I quoted what I did explicitly because of how a statement like that comes off to the person it’s aimed at. It doesn’t make them feel like they’re on an even footing working on the same project with the overall goal of it becoming better.
memory safety is more akin to changing languages from English to Esperanto because it has gender neutral pronouns.
I mean… not at all? Memory safety is huge for cybersecurity, buffer overflows and the like are common attack surfaces. C requires you to have deep knowledge of safe memory management practices and even then you can end up with memory issues. Rust was developed to avoid such issues entirely. I understand the reluctance but it feels to me like arguing “we should just stick with COBOL because it works.”
Gender neutral pronouns are pretty huge too. Sure you can do them in English without too many problems usually, just as it’s also possible to code safely in C. It requires everyone to change their old habits, but it’s much less of a change than is involved in adopting a whole new language.
Anyway, I do like Rust better personally.
I would still say that getting people to the point where they can write safe C code every time is harder than learning Rust, as it’s equivalent to being able to write rust code that compiles without any safety issues (compiler errors) every single time, which is very difficult to do.
Ok, that made your analogy make more sense to me. Thanks.
Gender neutral pronouns might be pretty huge too, but nobody’s private data is getting hacked because of gendered pronoun use.
Don’t thinknits possible by on write safe c code. Otherwise we would not have these issues time and time again. But yes its only the idiots begin don’t know how to code. Projects are big and complicated itsneasy to make mistakes.
I understand the reluctance but it feels to me like arguing “we should just stick with COBOL because it works.”
For those depending on COBOL code that does the job and has been doing it just well for a few decades, there are approximately zero good reasons to not stick with it.
- Eventually all the people who know and are good at cobol will die.
- A while before that happens, the people who know it will continually demand more money for their rare skills.
- Eventually, the cobol systems out there will need to interface new systems in some way it wasn’t designed to and it’ll be more expensive to shoehorn the remote system than to let the ancient beast retire.
Even if, we are talking about the Linux kernel. Our entire ecosystem builds upon C. People choosing C for new projects because it is the common denominator.
If Rust should be adopted in the kernel faster, patches should be send which comment how each line addresses issues of memory management solved and elaborations for rust specific patterns unfamiliar to a C dev.
Lurkers will pick up Rust that way as well.
Each Rust dev had to pick it up and therefore should be able to enable other - probably more experienced - Linux kernel hacker to provide reviewable patches.
It shouldn’t be the other way around, else you are just stepping on the efforts the other human provided to that project.
I’m not against Rust. I’d like to see something less dangerous with memory than C, but I don’t think it’s time yet for the kernel to leave C.
It’s pretty clean, stable, it’s working well at the moment and the C language (or variants of it) is/are still actively used everywhere. I think the kernel universally going Rust will be a long road of everything under the sun going there first before it’s ported in earnest.
Does it count as “doing it well” when every release has fixes for previous releases’ memory bugs?
Vast majority of the cybersecurity community: “an absolute ton of exploits come from memory safety issues with C/C++, we should move to memory safe languages like Rust to greatly reduce security risk and make everyone safer”
You: “Ehh Rust has a couple features, but it’s totally not worth switching from my precious precious C”
Yes people are also like you can code c safely yet it doesn’t seem to be that way. With the amount of bugs found over and over again.
like Rust
But no one is talking about that that is doesn’t need to be Rust. There are alternatives that can do as much if not more with the type system & safety while being as low-level as C without some of Rust’s restrictions.
rust was literally written as a systems programming language to take a similar place as C. i’m not sure of the restrictions you mean
Turns out there is a name for that. I had to look it up. Never seen such a striking example before.
Not quite, had I done something more broad than sure. But I reference a specific group of people whose job it is to provide security guidance on such matters. The ones who are out there fighting the good fight, RE’ing malware and busting down botnets among many security things
But I’m sure you are similarly credentialed as the SMEs in the cybersecurity field right?
Nah. If you’d been leaning on specific statements of any given expert — of which it is of course possible to find plenty that might in such casual rhetoric be used to support whichever conclusion you like — that would’ve been argumentum ad verecundiam, an appeal to authority. Instead you cited an imagined “vast majority” to exaggerate the universality of your opinion.
P.S. Whilst I’m indulging my argumentative side perhaps it is also worth pointing out that you totally mischaracterized my own statements and motivation. I am not primarily a C programmer, and I’ve been happy to use Rust myself when the opportunity arises. I have no personal stake in this particular fight.
Ah I see your default is to sprinkle in a bit of argumentum ad logicam and add a dash of straw man at the end
Your statement comes across as the migration from C/C++ is more of an upgrade for new features and increased “ease of use” rather than an urgent security issue when it definitely is. It’s more than just a case of a couple of experts and some articles, you’ve got multiple governmental and NGOs like The NSA, The Whitehouse, CISA, DARPA all calling for the migration away from C/C++ to memory safe languages
https://devops.com/darpa-turns-to-ai-to-help-turn-c-and-c-code-into-rust/
“DARPA, the Defense Department’s (DOD) R&D agency, will lean on emerging AI capabilities in a new program to deal with the costly and time-consuming challenge of rewriting C and C++ code to Rust in a move designed to meet the push for federal agencies and private organizations to adopt memory-safe programming languages.”
https://www.theregister.com/2023/12/07/memory_correction_five_eyes/
"CISA, in conjunction with the National Security Agency (NSA), FBI, and the cyber security authorities of Australia, Canada, the United Kingdom, and New Zealand, said its call for better memory safety follows from its Secure By Design recommendations – endorsed by all of these cyber authorities.
“With this guidance, the authoring agencies urge senior executives at every software manufacturer to reduce customer risk by prioritizing design and development practices that implement MSLs [memory safe languages],” the report argues."
~
"CISA suggests that developers look to C#, Go, Java, Python, Rust, and Swift for memory safe code.
“The most promising path towards eliminating memory safety vulnerabilities is for software manufacturers to find ways to standardize on memory safe programming languages, and to migrate security critical software components to a memory safe programming language for existing codebases,” the CISA paper concludes."
well, if this isn’t argumentum rocksolidum
Indeed the language is extremely fashionable among government types and many others. I did not really mean to suggest otherwise. If accusing me of erecting a straw man is your way of apologizing for your initial comment, I accept it.
Esperanto has grammatical gender.
I don’t think it does? https://en.wikipedia.org/wiki/Gender_reform_in_Esperanto
😂i wish my country switched from german to English because of how difficult it is to talk genderless in that language. Like, every fucking word seems to be gendered here.
“It’s herding cats: introducing Rust effectively is one part coding work and ninety-nine parts political work…”
All software development in a team is. More like 20/80 or 40/60 if you’re lucky.
Except in this case, it was a bunch of old C devs who aren’t just resistant but openly hostile to change, and they’d rather bully people into silence than try to progress.
God bless Douglas Adams
If I go to any of the teams I interact with who program their components in C++ and proposed Rust or anything else, I’d get a similar reaction. They’re very good at C++ and they very rarely have memory and threading issues. 😂
They very rarely have memory and threading issues
It’s always the “rarely” that gets you. A program that doesn’t crash is awesome, a program that crashes consistently is easy to debug (and most likely would be caught during development anyway), but a program that crashes only once a week? Wooo boy.
People vastly underestimate the value Rust brings by ensuring the same class of bugs will never happen.
They don’t get, that without memory issue resistant language, not a lot of new blood will be as good as them dealing with that stuff since they already have that solved in the language itself.
It is about making kernel development future proof, so that new devs keep on coming and don’t create massive security holes on the way.
Well this is how I understand it.
And it’s a bad argument anyway. You’re only good at memory management until the first bug takes down production.
Rust isn’t a panacea and certainly has problems, but eliminating an entire class of potentially very dangerous bugs is a very good argument.
Note that Rust does not “solve” memory management for you, it just checks whether yours is memory safe. Initially you might rely on the borrow checker for those checks, but as you become more and more used to Rust you’ll start to anticipate it and write code that already safisfies it. So ultimately you’ll still learn how to safely deal with memory management, just in a different way.
Yeah all of the times I see Rust being described as “harder to learn” than C I just shake my head. It’s like saying that it’s easier to just fall off the cliff at the Grand Canyon instead of taking the path down. Any additional difficulty is because the language forces you to understand memory and pointers properly, instead of just letting you fuck around and find out.
😃I see, nice to know
Several downvotes with zero comments to refute or discuss your point. Some devs don’t like you calling them out
In a twist of delicious fate, my instance doesn’t have downvotes. They get dropped before they even hit the database. So I’ll never know or “feel ashamed” if they don’t bother to take time to refute it. 🤣
Why isn’t a Rust kernel being developed in parallel ?
I mean, it is. RedoxOS is just that. But it’s not Linux and that means a lot of things.
Maybe this is the fork in the road for something new. These circumstances were kind of how GNU/Linux was born, after all.
Rust for Linux used to be developed in parallel to the mainline Linux before Linus Torvalds merged support in the main tree.
Ironically the majority of the rust memory management ruleset is called ownership, and they are unwilling to release any of it, and claiming all of it, so there’s an out of memory error.
I didn’t understood your criticism, what are they unwilling to release? What are they claiming all of? Why would ownership rules cause an OOM?
Sharing stack memory is a bad practice in C as well btw.
Lol the out of memory error was a joke. A reference to that two people both trying to do the same thing will fill the heap since there’s unnecessary work.
I tried to make a code joke but it failed.
As far as what are they unwilling to release? Control. Ownership of any bit of the kernel they control
kernel maintainer Ted Ts’o, emphatically interjects: “Here’s the thing: you’re not going to force all of us to learn Rust.”
Lina tried to push small fixes that would make the C code “more robust and the lifetime requirements sensible,” but was blocked by the maintainer.
DeVault writes. “Every subsystem is a private fiefdom, subject to the whims of each one of Linux’s 1,700+ maintainers, almost all of whom have a dog in this race. It’s herding cats: introducing Rust effectively is one part coding work and ninety-nine parts political work – and it’s a lot of coding work.”
If you want to talk about bullying you ought to include all the rust zealots who show up to shit on C every chance they get.
Okay, but this was but an example of that, so it’s not really a relevant grievance, is it?
bunch of old C devs
I knew this ageist bullshit would pop up. I know we lost our mentors and are kinda feeling in the dark, but the moment people pop out the ageist slurs I know they’ve got nothing to say.
The C developers are the ones with the ageist mindset.
The Rust developers certainly are not the ones raising the point “C has always worked, so why should we use another language?” which ignores the objective advantages of Rust and is solely leaning on C being the older language.
“Old” doesn’t have to mean biologically old. In this case, it means people who have been doing it for a long time—long enough that they’re set in their ways.
So while I can understand the confusion, it doesn’t apply here.
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.
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 ↩︎
How to Win Friends and Influence People by Dale Carnegie should be required reading for everyone. It’s full of things that are so obvious in hindsight but go against our natural instincts so we blunder through attempts to persuade not realizing that we might be increasing resistance rather than decreasing it.
Like the whole, “you might be right but you’re still an asshole” thing. Being correct just isn’t enough. In some cases you get crucified and then after some time has passed, the point you were trying to convince others of becomes the popular accepted fact. And they might even still hate you after coming around on the point you were trying to make.
That book won’t turn you into a persuasive guru, but it will help avoid many of the pitfalls that make debates turn ugly or individuals stubborn.
Or, on the flip side, you can use the inverse of the lessons to become a more effective troll and learn how to act like you’re arguing one thing while really trying to rile people up or convince them of the opposite. I say this not so much to suggest it but because knowing about this can make you less susceptible to it (and it’s already a part of the Russian troll farm MO).
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
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.
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:
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.
I don’t know. Rust seems like a better C++ to me rather than a better C. Actual C is a very simple language.
That’s fair, but my point still stands.
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.
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.“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
refdoes references that are guaranteed to be valid to their lifetime, and thus have said limitations.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 existingPointers are not guaranteed to be safe
So I guess they are forbidden in
@safemode?but it’s being replaced by something else instead
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.
part of the problem is that old-time kernel developers are used to C and don’t know Rust," Torvalds said. “They’re not exactly excited about having to learn a new language that is, in some respects, very different. So there’s been some pushback on Rust.”
Linus hit the nail on the head. If you’ve been a Kernel dev for a decade or more, and have spent decades learning the ins and outs of C, why would you want to switch to something that is similar, but different in a lot of ways, just because a small subset of devs think it’s the best way forward? Let them handle Rust and the majority of devs will keep using C, even though Rust is objectively better.
As one of the other quotes suggested: fork the kernel project and rewrite it entirely in Rust, that way there isn’t any push back from the C devs. Replacing C with Rust in the upstream kernel is akin to replacing the engine in a car while it’s running or being used every day.
This specific talk was about defining shared common interfaces so these different groups could work together and the guy who actually talked him into stepping down essentially said “I’m gonna keep writing C and if that breaks your rust stuff that’s not my problem”. This isn’t about convincing the c devs to write rust it’s about convincing them to work together when some of them seem to have made up their mind to sabotage rust support (either through indifference or willful interface regressions). Personally I’m more ashamed what this points to for someone new wanting to come in contribute to Linux.
Ah, but I still agree with the C devs, it creates unnecessary headaches for them. Also, old habits die hard.
I view it as the same way ZFS is supported: Linus and Greg KH are like “you can maintain it, but we don’t give a shit about it, and if what we do breaks ZFS support, well too bad.”
The reverse is also true. Any dev wanting to contribute to Linux in rust which linus himself allowed (despite his silence on this matter) are just going to have to deal with constant headache trying to maintain compatibility with the C interfaces which the devs keep breaking. Either they should’ve never allowed rust in the kernel or they should force devs to at least act in good faith and collaborate (and any that refuse to, well they should be ousted because they can’t behave responsibly). This entire situation is so toxic and I see that as a failure in leadership. That zfs comment is also a little toxic but I don’t think it’s a direct quote. It also doesn’t seem like a fair comparison because from what I can tell zfs isn’t even part of the kernel code base and due to legal reasons cannot be. While it would be great for the kernel not to break it, it is, for all intents and purposes an external project. This rust debacle is different because it’s rust kernel devs and c kernel devs both operating in the same project and trying to find some kind of alignment. To me it seems like there’s enough of an acknowledgment of the value of memory safety that rust support was considered but there’s no authority figure actually supporting it or defending the devs that were invited to actually contribute in it. What a mess.
I think all the Rust devs should remove their code and leave. And when in the future the Linux devs change their tune and ask for their help, they should refuse.
Just because some deva are assholes you gonna sabotage the work of the others 10 thousands?
I get the sentiment but that is in no fashion a way to move forward.
Well, when I’m not wanted I tend to burn bridges.
As one of the other quotes suggested: fork the kernel project and rewrite it entirely in Rust
That’s not practically possible given the scale of the kernel. And doing a total rewrite is almost always a recipe for getting stuck and, if you ever create anything, creating something worse.
Replacing C with Rust in the upstream kernel is akin to replacing the engine in a car while it’s running or being used every day.
Almost all real-world software development is like this. That’s what we do.
Yeah it is a monumental task, but it’s also the one with the least push back. I don’t mean start from scratch, but convert the C code to Rust in a dev branch or something and release a Linux-Rust kernel image.
Almost all real-world software development is like this. That’s what we do.
I’m aware, I’ve written my own software even though I’m a SysEng, all I’m saying is that it’s not an easy process with a potential for disaster. Just look at CrowdStrike (not saying that they were attempting to switch languages but just the scale of the fuck up and the fallout that it caused), we don’t want that to happen with Linux.
The kernel is probably too large to rewrite the whole thing at once. This could lead to a future without any new C kernel devs, leading to stagnation, while the Rust kernel could be many years away from being finished. (Assuming we actually move away from C.)
At that point you might as well just start an entirely new kernel and hope it is good enough to eventually replace the Linux one once all devs are gone. Kinda the X11 and wayland thing.
You can very safely remove the “probably” from your first sentence.
the Rust kernel could be many years away from being finished.
the number I saw floating around was 3 years to production useful. regardless, C’s end days as the go-to, large systems level language are drawing nigh.
edit: tear
I think this number is overblown. Production useful doesn’t have to mean 1:1.
Running it without all graphics drivers would be fine for server use. Also, not all filesystems need to be ported: basic ones should be enough for start. But not only servers, home routers run Linux kernel…
If every OEM starts contributing their drivers in rust, this could move quickly…
I agree. C isn’t going anywhere anytime soon, but if we don’t start modernizing the kernel now we could end up with a future like the US government is in where all critical systems run on COBOL code and no one wants to touch it for the fear of breaking everything.
I’m not sure if it was in my above post or not, but the article said we should start modernizing the kernel now before someone does to Linux what Linux did to Unix.
Redox OS already exists and is functional (meaning it boots and has a GUI, but it’s lacking in various aspects), from what I understand it’s pretty much Linux/Unix rewritten entirely in Rust and looks pretty promising. In 5 or so years it could be a competitor with BSD and then overtake Linux once it has a proven track record.
It blows my mind that Linus is just so darn based all the time. That guy has a good take on like every issue.
Strong opinions. Sometimes Linus’s takes are ‘bangers’ &, while probably fewer, he’s had a lot ‘woofs’ on the opposite end.
got some examples of the woofs? I’m not doubting the claim just interested :D
Replacing C with Rust in the upstream kernel is akin to replacing the engine in a car while it’s running or being used every day.
That’s in no way what’s been proposed. Rust is used in a very well defined niche, nobody wants to get rid of C.
But it’s just that sentiment that got us here, you’re arguing against a non-existent threat, and thus reject the whole proposal.
I’m not rejecting it, I’m just saying that it’s very difficult to completely change the code of a critical piece of software. The long-term goal is for Rust to overtake C in the kernel (from what I understand, I’m a System Engineer, not a software dev. I know Go, not Rust) due it being memory-safe and about 30 years newer. Critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit (and get bitched out by Linus 😂) so I’m sure there is tons of code from the early 90s that could be made better with a newer language like Rust, but it’s not as mature as C right now so that’s not going to happen for a while, if at all.
The long-term goal is for Rust to overtake C in the kernel (from what I understand
Your understanding wrong. Rust is limited to some very specific niches within the kernel and will likely not spread out anytime soon.
critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit
The entire kernel is “critical”. The entire kernel runs - kind of by definition - in kernel space. Every bug there has the potential for privilege escalation or faults - theoretically even hardware damage. So following your advice, nobody should every touch the kernel at all.
even though Rust is objectively better.
In some of its characteristics, Rust is certainly a good language. The borrow checker, however, still haunts my restless dreams today.
The borrow checker is exactly what the kernel needs.
I’m a C/C++ dude but I heard it being called the “Karen compiler”. It doesn’t look that scary based on samples I’ve seen, but there’s way more to it I am assuming.
I’m no Rust expert, but in my experience the borrow checker is a pain for a bit, then you start to get a sense of what works and what doesn’t, and after a while it has taught you to write cleaner code.
“Karen compiler” is almost perfect, except unlike Karens, the compiler is delightfully helpful with the error messages it gives you (usually). It usually gives a straightforward error, an error code, and sometimes, an easy fix.
As someone that started with Rust, but just yesterday had to fix some C++ code, working with any other compiled language makes me shudder. I have nothing but respect for devs that have to wade through stuff like that.
To be fair, most of them aren’t as nasty as C++. But Rust certainly gives you a sense of security you don’t get with most other languages.
At least it has something to complain about, unlike Karens.
Ha, I’ll steal that! “Karen compiler” - quite fitting, to be honest.
Oh, so the main reason why it’s so good?
I’m not a software dev (I’m a SysEng), and have never touched Rust (I’ve looked at the Rust source code and it scares me haha), but I know a fair amount of Go, and even the Go compiler is a pain in the ass occasionally. I’ve “mother fucked” it so many times.
Tl;Dr: Old farts holding us back, as always
“If it ain’t broke, don’t fix it!”
I’m not a software dev, but I’d imagine that the codebase could definitely be reduced once most things are converted to Rust. From what I’ve heard, the kernel is a huge mess of spaghetti code that most people don’t want to touch, for the fear of going insane in the process 😂
Rust is not objectively better. That’s your opinion
One detail about Rust in the kernel that often gets overlooked: the Linux kernel supports arches to which Rust has never been ported. Most of these are marginal (hppa, alpha, m68k—itanium was also on this list), but there are people out there who still use them and may be concerned about their future. As long as Rust remains in device drivers only this isn’t a major issue, but if it penetrates further into the kernel, these arches will have to be desupported.
(Gentoo has a special profile “feature” called “wd40” for these arches, which is how I was aware of their lack of Rust support. It’s interesting to look at the number and types of packages it masks. Lotta python there, and it looks like gnome is effectively a no-go.)
It seems like gcc rust would pretty much fix that issue, since soon gcc will be able to compile rust for any architecture gcc supports.
Assuming that it works out, yes, this might fix the problem. On the other hand, I remember gcj, which kind of quietly vanished after a while, so I prefer to reserve judgement until gcc’s Rust implementation is ready for production use.
wd40
We are all such dorks.
You say that as though it’s a bad thing. 😆
The gccrust and rustc frontend for gcc projects aim to address that.
i wonder if theres a goose farm in his future
Ted is the maintainer of ext4 and there are not many people in the world who understand this code.
For Rust to succeed, it has to get the subsystem maintainers to agree. It is going to be many years of petting very angry bobcats…
And that is not even the worst I’ve heard, makes you a bit numb if you follow LKML.
not many people in the world who understand this code.
Kinda sounds like maybe he writes some freaky garbo C that nobody can figure out 😅
Yeah. Isn’t it funny that the most popular file system in the world has such a codebase, and it is not even well documented how it works!
I have my reasons to choose XFS or bcachefs with my machines.
Linus is the leader of the kernel project. As a leader, it’s his job to get the maintainers to agree. It’s not Rust’s job to make the C devs stop bullying them.
If Linus thinks Rust is a good direction, he should show it by actually standing up to Ted and developers like him and making them behave.
If he doesn’t think it’s a good direction, he should say that too, so the remaining Rust devs can stop wasting time on the project.
When someone in a niche part of the project steps down like this, that’s a problem with the top-level leadership. Linus’ record on leadership is… mixed. Trending in a good direction the last few years, but this makes me wonder. He can still save this, but he has to want to.
Yes and no. Linus can yell to people and he does, he can force his say as he has been recently doing by expecting sched_ext to land in 6.12. BUT. Linux is a bazaar, it’s so big and there are so many different factions forcing them to do anything is going to take a long time. Lots of different teams are working on Linux, with their own priorities.
His job is to not get the maintainers to agree, but his job definitely is to bark a bit if somebody behaves like Ted.
It might even be Rust is not meant for Linux kernel and it will never happen. Or it happens in the driver layers, but stays out from the core. We do not know yet. The concern Ted is raising is definitely valid: if the C APIs change, people who work daily in the C code cannot spent cycles fixing the Rust APIs. These people have their day jobs which pays them to maintain these subsystems, and it is at least not yet clear will these employers fund rewriting anything in Rust. There are tens of filesystems in Linux, with lifetimes passing around that are not documented and might not work in Rust.
Note: I’m a Rust dev for the past 10 years, and I follow this discussion with high interest.
No one’s saying the points raised are not valid, just that there’s no need to be a cunt about it in what should be a professional setting.
- rake in the lake
Developers who are not willing to learn something new and not adapt are the worst. Besides that, nobody is forced to learn Rust, only those who want to work on Rust parts.
Developers who are not willing to learn something new and not adapt are the worst.
And this is why COBOL developers are desperately needed these days: because too many people think that “old” was the same thing as “needs a replacement”.
“Learning something new” does not mean the thing you are learning is new. It just means it’s new to you. One of the best things you can do for yourself as a dev is to learn to be fluid and be able to adapt to new languages, protocols, and technologies.
So basically you’re saying one of the best things you can do for yourself as a dev is be young.
It’s a well-documented fact that as people get older their fluid intelligence declines.
If you predicate your tech culture on requiring high fluid intelligence, you (a) make less readable code since the people writing it have more working memory and can hold more lines in their mind at a time and (b) break long-term institutional memory resulting in the reoccurrence of solved problems.
At the level of organizational architecture, a culture of emphasizing fluid intelligence as the strategy for attacking problems and adaptation causes serious losses of efficiency, and hence fluidity at a higher scale.
Ensuring compatibility with greybeards’ brains is key to long term success, and that means respecting an upper boundary on the rate of tools change.
It’s a well-documented fact that as people get older their fluid intelligence declines.
I’m quickly approaching grey beard status. I recognize that I’m nowhere near as fluid as I was 20 years ago but I make an effort. You have to continually practice fluidity and actively learn things lest you solidify and lose that skill like any other. It’s important to stay fluid because things change and change faster than we all expect.
At the level of organizational architecture, a culture of emphasizing fluid intelligence as the strategy for attacking problems and adaptation causes serious losses of efficiency, and hence fluidity at a higher scale.
Ensuring compatibility with greybeards’ brains is key to long term success, and that means respecting an upper boundary on the rate of tools change.
There’s some truth to that. PHP is still in use and Wordpress is still somehow a behemoth. But the fact is that PHP has fallen out of favor, isn’t used by new projects, and there’s less demand for people with that skillset. So as a dev, it’s important to recognize that tools come and go and be flexible.
This example doesn’t work as well with C/++ since that’s older than most people here (though the language has also gone through iterations) and likely won’t be going away any time soon. But still, in most cases you probably don’t want to use that language for general work. So you’ll probably have to pick up other things for your toolchain (and higher level) work which of course has changed a lot.
The good news is though, that it’s relatively easy to transfer core skills between most languages. Especially the ones with C-like syntax, which is most languages.
You have to continually practice fluidity and actively learn things lest you solidify and lose that skill like any other.
I’m all for keeping one’s cognitive skills. However it is a fact that this decline happens, and that there is a phase of life where one has wisdom without necessarily having the same raw intelligence they had before. The wisdom is encoded in crystallized intelligence.
By wisdom here I mean “The tendency to make decisions that turn out well”.
My father was an equipment operator well into his 70s. After he retired they kept bringing him back to train the younger guys, and to get things don’t they couldn’t get done.
That was possible because those machines don’t change too much as time marches on. Because they use a stable platform, his organization was able to do better work by relying on his deep expertise. He could train those younger guys because it was the same platform he’d always used. Same dirt, same physics, mostly the same machines, same techniques, same pitfalls, etc.
His fluid intelligence is almost zero. The man’s practically an ASIC at this point, yet he’s fascinating to talk to and competent in the world. Fluid intelligence is not the only way to get things done.
We of course play plenty of video games together to keep him sharp. We also eat mushrooms, paper when necessary, and he works out a lot. We do all we can, believe me.
PHP is still in use and Wordpress is still somehow a behemoth. But the fact is that PHP has fallen out of favor, isn’t used by new projects, and there’s less demand for people with that skillset
Also while I’m driving, my Uber app locks up. Siri talks to me in a halting, broken voice, and responds with “something went wrong”. Google Maps shows a brief flash of my home before flipping to my current location. Then back to home again, then back to my current location. Spotify doesn’t remember what song I was listening to. Amazon Prime Video can’t remember what episode I was last watching.
Enshittification is everywhere. Our tech is buggy as fuck and solved problems in project management and devops are recurring. It’s not just about focusing on advertisers’ needs over customers. It’s also about wanting to kick out the greybeards as part of our great cultural revolution. It’s about driving trains into tunnels without adequate ventilation because fuck the previous generation thinking they know better than me.
It is the case that new technologies are introduced all the time, but that’s not necessarily right.
This example doesn’t work as well with C/++ since that’s older than most people here (though the language has also gone through iterations) and likely won’t be going away any time soon. But still, in most cases you probably don’t want to use that language for general work.
Why not? Because you won’t be able to hire younger devs? That is a function of this culture of pushing for change in everything. Younger people don’t learn C++ because it’s a little harder to read and because culturally we don’t respect established things. I’m sure there’s a word I don’t know here, but we generally have a culture of hating the past.
The good news is though, that it’s relatively easy to transfer core skills between most languages.
I agree. Design patterns, work patterns, these transcend languages. And they’re 99% of the success or failure of a project.
And yet here we are emphasizing how C++ and Rust can’t realistically coexist in a serious project, because there’s some mismatch in their capabilities. I point to the current conundrum as the counter to this idea of transferability. The devil’s in the details and if the wisdom transfers between languages so well then we don’t need new languages.
Fundamentally, the question is “What are these news things that need to be done by code, that weren’t being done by code 30 years ago, such that it necessitates new languages?”
It’s cool to be able to tell your college buddies you’re building a new programming language.
In fact, it’s great that people are making new languages as a way of keeping language design wisdom alive. It’s great that CS kids build logic circuits from scratch for the same reason.
But then again, Netflix can’t remember what episode I was watching, when I’m almost certain they had that ability a few years ago.
Lots of good insight there. While I disagree with much of it, I get it.
I’m all for keeping one’s cognitive skills. However it is a fact that this decline happens, and that there is a phase of life where one has wisdom without necessarily having the same raw intelligence they had before. The wisdom is encoded in crystallized intelligence.
Yeah, realizing you have that wisdom is eye opening and it’s actually pretty powerful. I can hunt down bugs by smell now with surprising accuracy. But I’m not convinced it’s mutually exclusive to fluidity. I guess I’m just hoping my brain doesn’t petrify and am battling against it.
That was possible because those machines don’t change too much as time marches on. Because they use a stable platform, his organization was able to do better work by relying on his deep expertise. He could train those younger guys because it was the same platform he’d always used. Same dirt, same physics, mostly the same machines, same techniques, same pitfalls, etc.
It’s a poor analogy for software though. Software is an ongoing conversation. Not a device you build and forget about. User demands change, hardware changes, bugs are found, and performance is improved.
I’m honestly curious what the oldest line of code in the Linux kernel is now. I would be pretty shocked to see that anything survived 30 years. And I don’t think that’s because of enshittification.
This example doesn’t work as well with C/++ since that’s older than most people here (though the language has also gone through iterations) and likely won’t be going away any time soon. But still, in most cases you probably don’t want to use that language for general work.
Why not? Because you won’t be able to hire younger devs? That is a function of this culture of pushing for change in everything.
No, because C/++ isn’t the right tool for every job. If I want to write up something quick and dirty to download a sequence of files, I’m not going to write that in C. It’s worth learning other things.
I have to admit though that the conservative approach is more suited to things like a kernel, aerospace applications, or other things with lives riding on it. But also software that doesn’t change becomes useless and irrelevant very quickly. For instance, running Windows XP is a bad call in just about any case.
But again I’m also not trying to say all software should be trend following. Just that devs should embrace learning and experiencing new things.
Netflix is using FreeBSD for servers. You can’t blame everything they do wrong as being a problem with the new hires. They are using an OS older than Linux that changes more slowly than Linux, simply because it performs the best for their specific application. Rate of change isn’t the issue here.
In fact that’s 90% of what this comment is. Blaming new people and new techniques for problems when you aren’t a part of that organisation and don’t actually know what’s happening.
Working with computers is not the same as working with construction equipment. Some degree of fluid intelligence is needed in this field, no matter how experienced you might be, just like how a surgeon needs steady hands. The people you call greybeards aren’t nearly as old as your father is. We are talking about people who are in their 50s and 40s. They don’t have that level of cognitive decline yet. Likewise some things like ext4 aren’t likely going to be ported to Rust now or even ever. They can keep maintaining them as they are now for the foreseeable future. Plus I don’t want people to have to keep working into their 70s and 80s. At some point it becomes elder abuse. Let people retire man.
C has existed for a long time now. We’ve been trying to replace it for ages, for most of it’s lifespan even. C++ actually was one of the new options at one point. I get it seemed immovable only a decade ago, and I think that has lulled people into a false sense of security. In truth it was inevitable it would have to be replaced one day. It’s already well outlived the life expectancy of a programming language. Just think about Ruby: created long after C yet has already become mostly irrelevant. You talk about the maximum rate of tool change, but C is one of the oldest tools we have, keeping it around would be almost 0 rate of tool change over decades. If you can’t see that C is very slowly dying then you haven’t seen the writing on the wall for the past several years. It’s on you at that point.
We should look back with pride at everything that has been accomplished with C, and just how long it’s been relevant. We can do this while still acknowledging it needs to be phased out gradually.
No one is asking for change that rapid either. Linux started adopting Rust four years ago now. It’s probably still going to have C code inside it for at least a decade from now. This isn’t some quick change, it’s a gradual process. People have plenty of time to adapt, and those who are too old to do so will be around retirement agent if not already dead by the time C is fully phased out.
We of course play plenty of video games together to keep him sharp. We also eat mushrooms, paper when necessary, and he works out a lot. We do all we can, believe me.
Honestly you take more care of yourself and your father than I do. I am only in my 20s and suck at video games. If I took mushies or LSD I would probably lose my mind, assuming it’s all still there in the first place. I suspect there is a good reason why people like me only have a life expectancy of 58 or so.
C has been around for a very long time. I don’t think wanting to replace a 1970s language, that was old when current gray beards were young is a bad thing. People have had more than enough time, and still have a good decade or two to make their careers writing and maintaining C code. Sometimes things have to change, old people be damned. It’s diatribes like this that remind me the human race advances one body at a time as those holding us back die out.
Edit: also we aren’t talking about people in their 70s and 80s here. Most of these “greybeards” are in their 40s and 50s at most. Linux itself is from the 1990s and is therefore more modern than C.
Why? I mean, I, personally, try to be as polyglot as possible, but not everyone working on the Linux kernel is even interested in doing anything that’s not C kernel code, nor is it their profession.
Learning is key in this field. Being able to learn new things allows you to move from one thing to the next as needed. You also learn a lot from experiencing different things. Other ways of doing things, other points of view, other concepts that you may have not been exposed to before.
It also expands your employment potential and general usefulness. Knowing only one thing will severely limit your abilities.
It also expands your employment potential and general usefulness.
I have already mentioned that programming is not everyone’s profession. Not everyone chooses what they do in their unpaid free time primarily based on whether it makes them a more useful person. I think the very phrase ‘my usefulness’ is dangerous.
Are we only worth something as drones?
I never said anything about someone’s usefulness as a person. Their usefulness as a software developer was the topic at hand. Maybe it’s not your profession but a hobby but the point stands.
I think the very phrase ‘my usefulness’ is dangerous. Are we only worth something as drones?
And yet it’s drones that do one thing and only one thing their entire lives, never learn and grow.
Maybe it’s not your profession but a hobby but the point stands.
To be honest, I’ve hardly ever asked myself how I could best please a potential employer with any of my hobbies. But I recognise that you’re probably taking a different approach.
employment potential and learning are generally problems if you are young. if you are old, the time investment to learn a new language is generally not self beneficial as your time of employability starts to dwindle.
Linux ultimately will have to run into the situation of if the people want the newer language to become the mainstream, they need to be more proactive at the development of the kernel itself instead of relying on yhe older generation, who does ot the way they only know how, as relearning and rewriting everything ultimately to them, a waste of time at their point in life.
think like proton was for gaming. you dont(and will not) convince all devs to make linux compatible games using a vulkan branch. the solution in that front was to create a translation layer to offload most of that work off because its nonsensical to expect every dev to learn vulkan. this would be applied moreso to the linux kernel, so the only realistic option (imo) is that the ones who are working in rust need to make the rust based kernel and hope that it takes off in a few years to actually gain traction.
employment potential and learning are generally problems if you are young. if you are old, the time investment to learn a new language is generally not self beneficial as your time of employability starts to dwindle.
Middle age software engineer here. Very disagree. Hoping to code until arthritis gets me. My point wasn’t only for employment (more of a perk), but primarily self-improvement and improvement on your craft. The day I can no longer do that, that may be the end for me.
That said, I don’t know what Linux community should do about Rust adoption. I just wanted to point out that I think it’s very important for all devs to be able to embrace learning new things and expand and refine their skillset.
One problem is (even Linus acknowledged it in some interview, sorry I have no source) that in future C might no longer be the popular language to learn. I mean learning basics is one thing, but getting good at C and writing in the Kernel, while trying to dodge memory issues is a huge task to ask.
Lot of people learn Rust instead for systems programming today. Meaning in future it might be very useful to get new people into Kernel programming. And as said before, those who are not interested into Rust are perfectly fine using C. The Kernel is huge! Even new code in C is allowed, so this is not something that is going away. Remember, its an addition to the base, not replacement.
The situation of COBOL has nothing to do with Rust in Linux. C is not replaced by Rust, first. Secondly, there are legitimate reasons why Rust was introduced, as a secondary language. You are conflicting two different cases that are two different problems. It’s not replacing a language.
Third, we do not need COBOL. All those systems that are still running on COBOL are businesses that shouldn’t exists in the first place anymore.
Like banks and insurance companies?
deleted by creator
Exactly.
So you advocate for the abolition of money also?
deleted by creator
People who model learning new things as a process without costs are also the worst.
“Because that’s how we’ve always done it” is a far more valid reason for doing something in a particular way than it is given credit for.
Adding rust to a massive mature C project that targets lots of architectures and has many contributors is a difficult process. If it succeeds it is going to take a lot more time and patience.
Especially when Rust has limited support for less common architectures. This has been forcing distros like gentoo to drop support for more niche arches since many common packages like python-cryptography are now pulling in rust as a mandatory dep.
IMO this has been very publicized in certain circles, and will have the effect of martyrdom. More people are going to be interested in doing this.
deleted by creator
@reminder 20 years
Is there an email thread where c and rust Linux kernel devs actually discuss what’s about? Because so far I see some Linux drama and I have no slightest clue what’s about
Rust guys want to make the kernel safer, more expressive, and easier to maintain. To do that they need to know how the kenrnel talks between its parts to ensure they are creating matching behavior. The C guys don’t really care about the Rust guys and say that they can’t be bothered to guarantee interoperability because they like to change how things work on the C side to make things better in the C code.
“primacy”?
Fuck that accusation of turf.
After almost 4 years
he didn’t last much
How long would you stay in a job you hate?
me, personally?
why would it matter how long i would (or did) stay?
It’s a rhetorical question. Would you consider 4 years to be a “short amount of time” to remain at a job you didn’t like?
i would consider 4 years to be
- too long amount of time for a job you don’t like (it took you 4 years to realize that you don’t like it?)
- too short for a job you are committed to (you give up only after 4 years?)
After almost 4 years, I find myself lacking the energy and enthusiasm I once had
once i had? energy and enthusiasm he had only 3 years ago?! When i started reading the article i was expecting 15 years, 20, 30+
Commitment issues.
The rust community is its own worst enemy. The political infighting and constant compulsion to shit on other languages is a turn off to many, and there are plenty of applications where memory safety is not the highest priority.
In this case, the issue is really the C kernel devs, not the Rust devs. Some are not open to new ideas at all. Take a look at the conference video he linked to for example: https://youtu.be/WiPp9YEBV0Q?t=1529. He clearly states that he’s not trying to make the C devs learn Rust.
My comment was speaking in a general context.
I’ve seen the video and I agree with Ted. Anyone with experience understands creep, and although Wedson denies it it’s exactly where they’re headed. Ted and others are right to voice these concerns and attempt to set very clear expectations for the rust developers.
They took on the task knowing it was experimental, would be difficult, and that they would be second class citizens - you don’t get to agree to the terms and then complain about them later.
then complain about them later.
I don’t see where they’re complaining? They don’t seem to be asking anything of the C devs other than help with API definitions.
Wait until you see the Lisp community. But yes, Rust is currently in its “why are there even any other languages lol” phase. Just wait.
