- cross-posted to:
- linux@lemmy.zip
- cross-posted to:
- linux@lemmy.zip
Linux people doing Linux things, it seems.
You must log in or register to comment.
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.
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.
Gender neutral pronouns might be pretty huge too, but nobody’s private data is getting hacked because of gendered pronoun use.
Ok, that made your analogy make more sense to me. I can agree with that. Thanks.
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.
😂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.
Esperanto has grammatical gender.
I don’t think it does? https://en.wikipedia.org/wiki/Gender_reform_in_Esperanto
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 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.
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 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.
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.
“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.
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.
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 ↩︎
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
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.
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.
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”.
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?
“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.
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.
Developers who are not willing to learn something new and not adapt are the worst
I think you mean people in general. Life is short, try some stuff, take risks
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.
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.
Seems like it’ll be the year of RedoxOS desktop! /s
@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
“primacy”?
Fuck that accusation of turf.
Not an expert in both the languages but I heard that C developers are trained to use memory smartly, sometimes even reuse a range of allocated memory for completely different purpose to save cycles freeing and reallocating. But for Rust developers, everything is about making sure when one should get the hand away from the memory, and whose memory is allowed to be touched.
Sounds to me like sharing rides that maximise economically but we may have some oops moments sitting on someone’s laps vs absolute private rides to make sure no one in your family will be harmed but we have to make sure everyone gets a car only when needed.
It is quite interesting to see how it will work out eventually…
