There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

avidamoeba , (edited )
@avidamoeba@lemmy.ca avatar

“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.

Telorand ,

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.

possiblylinux127 ,

1000003885

pete_the_cat ,

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.

cm0002 ,

Tl;Dr: Old farts holding us back, as always

tux0r OP ,
@tux0r@feddit.org avatar

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.

pimeys ,

The borrow checker is exactly what the kernel needs.

TimeSquirrel ,
@TimeSquirrel@kbin.melroy.org avatar

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.

tux0r OP ,
@tux0r@feddit.org avatar

Ha, I’ll steal that! “Karen compiler” - quite fitting, to be honest.

floofloof ,

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.

trevor , (edited )

“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.

PotatoesFall ,

It blows my mind that Linus is just so darn based all the time. That guy has a good take on like every issue.

emax_gomax ,

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.

De_Narm ,

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.

qprimed ,

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

Eranziel ,

You can very safely remove the “probably” from your first sentence.

floofloof ,

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.

SnotFlickerman ,
@SnotFlickerman@lemmy.blahaj.zone avatar

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…

kbal ,
@kbal@fedia.io avatar

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.

SnotFlickerman ,
@SnotFlickerman@lemmy.blahaj.zone avatar

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.”

kbal ,
@kbal@fedia.io avatar

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.

SnotFlickerman ,
@SnotFlickerman@lemmy.blahaj.zone avatar

Ok, that made your analogy make more sense to me. I can agree with that. Thanks.

explore_broaden ,

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.

refalo ,

People prefer what’s familiar to them. Rust is completely foreign to them, the syntax is very different, the community is different (and often much younger), it still has many issues and is not ubiquitous, and many people are just slow/averse to change in general. So I absolutely understand the hesitation. And some just don’t like it for other reasons like the syntax, learning curve or other reasons. There’s also still a host of memory-related things Rust doesn’t fix like stack overflows, leaks, bitflips, unsafe context code, and just bad coding practices in general.

Octorine ,

I blame C++. When these kernel hackers hear about how they should switch to this shiny new language that’s going to make their code so much cleanser and more manageable, I don’t blame them for thinking it’s all bullshit. It was last time.

refalo ,

To be fair, there’s nothing wrong with only using the parts of C++ you want. If you avoid things like templates, exceptions, RTTI etc. then e.g. your compile times will not suffer like people always complain about, your error messages will not be cryptic, plus you’ll have stronger typing, easier/safer lifetime management with ctor/dtors and easier to read code from class usage.

Personally I think Swift has great potential if it can get past the speed and cross-platform issues, as it was designed by (among others) some C++ committee folks, and so it feels a lot more familiar than say, Rust, plus it fixes a lot of long-standing issues.

There is also an Indian kernel fork that allows C++ drivers.

tux0r OP ,
@tux0r@feddit.org avatar

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.

cm0002 ,

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”

kbal ,
@kbal@fedia.io avatar

Turns out there is a name for that. I had to look it up. Never seen such a striking example before.

cm0002 ,

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?

kbal , (edited )
@kbal@fedia.io avatar

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.

xan1242 ,

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.

Octorine ,

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.

thingsiplay ,

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.

tux0r OP ,
@tux0r@feddit.org avatar

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”.

thingsiplay ,

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.

melroy ,
@melroy@kbin.melroy.org avatar

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.

treadful ,
@treadful@lemmy.zip avatar

“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.

tux0r OP ,
@tux0r@feddit.org avatar

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.

treadful ,
@treadful@lemmy.zip avatar

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.

tux0r OP ,
@tux0r@feddit.org avatar

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?

treadful ,
@treadful@lemmy.zip avatar

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.

tux0r OP ,
@tux0r@feddit.org avatar

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.

Dudewitbow ,

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.

thingsiplay ,

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.

unionagainstdhmo ,
@unionagainstdhmo@aussie.zone avatar

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

merde ,

After almost 4 years

he didn’t last much

avidamoeba ,
@avidamoeba@lemmy.ca avatar

Commitment issues.

originalucifer ,
@originalucifer@moist.catsweat.com avatar

i wonder if theres a goose farm in his future

gravitas_deficiency ,
  • rake in the lake
pimeys ,

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.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines
    •