Linus Torvalds: Speaks on the Rust vs C Linux Divide

[@BalancedByte]

Someone should write a C compiler in Rust and a Rust compiler in C, and compile the compilers on one another.

[@stanimir4197]

you can write a C and Rust compilers in Java, that won't do much - it reads bytes and produces bytes

[@Nootlink]

Fun fact, there already is

[@TheHermitProcess]

Wait till you hear about bootstrapping.

[@rogerxxxxxxx]

Sounds screwy to me. Somebody is bound to loose a nut.

[@robertheinrich2994]

@@Nootlink and if it is used to compile code for p-hub, even rule 34 is satisfied? ;-)

[@salthin]

I think it's better to see C and Rust as tools to use rather than ideologies to get behind.

[@ClimateChangeDoesntBargain]

what ideologies are you talking about?

[@whentheyD]

C... and Rust​@@ClimateChangeDoesntBargain

[@craigcraig6248]

There is a practicality to choosing one over another. Correct programs can be written in C, but this is engineering, we must prepare for human error. This is not ideology, this is being practical.

[@nosotrosloslobosestamosreg4115]

Sadly these are not times in which Reason is heard.

[@dixztube]

Zig !

[@konberner170]

Linus wins the "most pragmatic guy on earth" award for this year.

[@rosomak8244]

It is not pragmatism to add the burden of multiple languages in a single software system. It doesn't come free.

[@defeqel6537]

@@rosomak8244 Indeed. Rust is not an incremental change to developer habits, it's a revolution (in good and bad), and that rarely meshes well with existing structures

[@konberner170]

@@rosomak8244 I'm talking about his attitude in general. Like, hey, whatever works...

[@rosomak8244]

@@defeqel6537 They promise quite a lot of things. However if only someone bothered to invest in to the #pragma stuff... plenty of those additional assurances could be managed without inventing a whole new syntax.

[@ismbks]

he wasn't as pragmatic when it came to integration of c++ in the kernel

[@gokuldastvm]

Unbelievable how much Torvalds changed from his younger days. He has mellowed down a lot and is very pleasant and diplomatic now.

[@berarma]

He's been always like this, you just don't put garbage into his inbox.

[@gokuldastvm]

@@berarma I remember his very public (and very justified, IMO) F..U to Nvidia. After his sabbatical though, he recollected the event and refused to make any more such controversial statements in public. His tone in the lists is also much milder these days. I was expecting him to take one side and blast the other in the Rust integration issue. But he instead chose the diplomatic side - to not alienate either side!

[@berarma]

@@gokuldastvm you're taking one event in which Nvidia was giving him shit and generalizing. Watch more of his talks not just what YT throws at you.

[@GabrielPettier]

Heh when you realize how much better it is not to be angry all the time, i guess you start to look for more of that.

[@gokuldastvm]

@@berarma Bold of you to assume I don't watch anything else. Perhaps you need to watch all of them to understand what I mean.

[@whythosenames]

"Should we have a poll here in the room?", "no."

[@SavvyNik]

🤣

[@gingerboy9170]

Yea, and there is no reaction from the anchor guy😅

[@kRySt4LGaMeR]

good and balanced take. also it's great that he recognizes that regardless of whether Linux adopts or rejects Rust, people will still want to use the language to build a kernel (or even an operating system).

[@PiotrPavel]

redoxOS!

[@mrsearaphim4077]

People just get way too emotionally involved with the things they work on and that's the problem. It prevents healthy debates that can improve both sides of the table.

[@Leonhart_93]

Too balanced of a take. Saying something without saying anything. Stay in the middle of the road and you might get hit by a truck.

[@blarghblargh]

​​​@@Leonhart_93prove to me you're capable of developing at the level of decade long kernel maintainers and not some naive kid who thinks rust is a magic silver bullet, and we might take you seriously. Hint: it's on you to catch up, not on current kernel maintainers to stop the world so you can hop on. ("You" being the obnoxious Rustacians who think they don't own at least half of this problem. Maybe not actually you)

[@khai96x]

@@PiotrPavel Does Redox have a linux compatibility layer? (can it run Linux binaries?) People aren't going to rebuilding everything for a new architecture. So I think it's necessary to increase adoption and usability, I've heard that some BSD flavors are compatible with Linux binaries.

[@swannie1503]

Gonna wait until Prime reacts to this and forms my opinion for me

[@SavvyNik]

lol

[@r2com641]

Who cares about that clown except fools?

[@Gwarzonicus]

I would not go to Prime for something this low level.

[@Bingo901]

🤣

[@emhean]

This is too low level, Prime is a high level idiot

[@mrpocock]

The more I hear about this, the more I think the real problem is about programmer culture. The ethos of Rust is that as much of the semantics as possible should be documented in the types, and as much of those semantics as possible should be enforced by the compiler. The ethos of c, particularly in the kernel, is that the semantics exist primarily in the project leader's understanding and then secondarily in human-readable documentation. The code should be as free as possible from semantics, so that the developers are as free as possible to do things the way they want, or to change things in the future without touching a lot of code. Rust wants all the knowledge explicit, and kernel c culture wants it all implicit. So where the Rust and the C codebases interface, there's a corresponding interface of cultures.

[@mrpocock]

@@RenamedChannel Checked exceptions are a really nasty coder-experience. Unchecked exceptions are bugs by design. Rust's adoption of the error monad from Haskel and friends threads the needle for error handling, so we know they're being processed and where they came from, but the error-handling code is largely hidden behind the ? operator. It's a good compromise IMHO. Infinitely better than writing code that could fail at any time for reasons that aren't documented within the code you are looking at.

[@billwixon7162]

Result is the opposite of exceptions. It's similar to Either in functional languages. It's interface is designed to be composable. Explicit error states are preferable to implicit exceptions

[@mrpocock]

@@RenamedChannel I don't know enough about allocators or locks to know why that's a problem or if or why Rust can't do it. Can you explain a bit?

[@justanotheruser7843]

​​@@RenamedChannelwhat is the bump allocator with rollback mechanics? I really don't know and tried to google it with no result. I've implemented a bump allocator multiple times in rust with some difficulties, I must be frank. but it wasn't like too much of a trouble really so I wouldn't say something in lines of "rust cannot handle" when we are talking about that. not to mention numerous libs providing bump/arena allocators. but I'm really curious of that "rollback mechanics" bit. I beg you to tell me what it is

[@blarghblargh]

Rust has lots of stuff happening implicitly. Zig is much more explicit than Rust. I think Rust people often don't understand nearly as much as they think they do. They probably understand a lot, considering the complexity of pushing lifetime into the scope of generics, but I suspect a lot of them think they'll be able to avoid using unsafe contexts much more than will be useful and important in reality at the kernel level. And yeah, C is a mess for a lot of reasons. I just think RAII isn't nearly the panacea it's often seen as. You really don't want individual allocations and frees in high performance code. You want large homogeneous blocks of memory you allocate in bulk, process in bulk, and free in bulk, and RAII is generally not oriented around that sort of allocation pattern.

[@asdfghyter]

it feels so unexpected to see Linus being the calm diplomatic voice after having seen all those very much neither rants

[@orkhepaj]

what rants? imho you are just a pussy

[@andreas7944]

He failed to provide guidance for the community. Everybody thinks they can influence if rust is the future in the kernel or not. I would prefer if Linus simply says if it is a fix point of the roadmap or not. A clear vision is needed so people can figure out how to work together towards a common goal. Currently it is really one big mess. And the community is loosing more and more devs. Linus really needs to set the guiderails - or it will only get worse.

[@fanciestbanana4653]

@@andreas7944 It's not his job to babysit people. He already has his hands full with kernel development.

[@asdfghyter]

@@andreas7944 there's a limit to how diplomatic he can be before people start suspecting that he's been replaced by an impostor 😆

[@andreas7944]

@@fanciestbanana4653 Dude, that is exactly what his job is. He is the top dog. Nobody is above him. He is the only one that can make that statement. And he already did similar statements in the past. It really is the leadership 101 to do that.

[@KirinDave]

It's kinda amazing how much better of a leader Linus is these days. Before, he would have found a way to turn this conversation into a disaster. Now, he makes it look like an opportunity. Nice to see everyone can grow.

[@paulfalke6227]

Years ago, there was the monolith versus micro kernel discussion. Today there is a C versus Rust discussion. In my opinion black/white or right/wrong thinking does not help. Every solution has advantages and disadvantages. Depending on YOUR problem, some disadvantages are small, others big. Somebody with another problem sees your small disadvantage as his/her big disadvantage. Spoiler: you are both correct. It depends!

[@helmutmueller3326]

I like that he can talk about Linux to go away some day without emotion. Really important man indeed and not screaming around. Thanks a lot to him for his work. 👍😁

[@yewo.m]

That was quite diplomatic

[@dmitripogosian5084]

He has 30 years of experience of managing people

[@Daniel-bf9rn]

Linus has become a politician

[@kozlovskyi]

Old Linus was more "straight to the point" guy

[@fizipcfx]

i think it can be expected. He can be civil and reasonable most of the time. But if you read the linux mailing lists of torvalds it may seem like that guy just cusses and swears at people for no reason. I think it always is quite justified.

[@VivekYadav-ds8oz]

So whenever he's not being rash he's not being truthful? Nothing he said felt like diplomacy or playing both sides to me. He's just being pragmatic. Ffs are people now *expecting* toxicity lmfao

[@_Love_And_Peace]

imo, those who wish to completely seize the hardware, prefer C, and those who regard the OS as an upper structure over the hardware prefer RUST. They are 2 distinctively different groups of people. So, there is a divide, and I am quite happy Linus wrote the kernel in C.

[@MonkeeSage]

Folks who only know Linus from angry kernel mailing list posts that get shared on social media think he's just an unreasonable a-hole, but he's actually quite reasonable and usually has pretty balanced takes on big issues like this (although he is still kind of an a-hole sometimes).

[@defeqel6537]

his level of a-holiness... seems proportional to his expectations of people, he seems nice when he doesn't expect much of you

[@Sammi84]

@@defeqel6537 And proportional to how much these people he has high expectations of let him down.

[@Henry-sv3wv]

@@Sammi84 elon musk just fires people that let him down

[@kaasbaas9532]

@@Henry-sv3wv he can't so he has to REEEEEEEEEEEEEEEEE in mailing

[@ShaferHart]

being direct: being an a hole these days. He needs to keep zealots at bay and that's what happens.

[@BudoReflex]

I appreciate that he respects that many will feel and also do just as he did; go their own way! He doesn’t come across to me as even being diplomatic or conciliatory, rather he is referring to his own journey and knows that there will be those just like him who will create new things, even OSs with rust.

[@GungaLaGunga]

Rust? Oh man, corrosion is incidious and destructive. Get some WD-40!

[@RustIsWinning]

Stand-up comedian right here 😂

[@VolkerGoller]

They should have named ZIG WD-40 😳😂

[@RustIsWinning]

@@VolkerGoller Zigooners could never make it into the kernel lmao

[@iceteazen]

@@RustIsWinning becuase its a new thing, but i think zig could qualify but a fan of rust more than zig but i also enjoy zig.

[@aftermath1886]

​@@RustIsWinningI think zig has a long way to go

[@eliasepg]

I really like the way that Linus said about his view on the Rust vs C situation, very wise

[@andrewgreen1970]

@ 3:38 - "I think it's, actually, one of the strengths we have in the kernel - that we can specialize. Some people care about drivers, and very specific drivers, and that some people care about specific architectures, and some people like file systems. And that's how it should be."

[@Winnetou17]

Wasn't one of the main "beef" between Rust and C developers the need for documentation ? That is, Rust guys trying to remake or add things that are already in C and they're totally undocumented and only have cryptic names and asking the C developers to tell them what's what and so on and the C developers getting defensive, believing their love child is being replaced under their eyes or something like that ? That's hardly a Rust vs C problem, it's a "new devs" vs "old devs" problem. Probably just an "old devs" being too defensive problem, but I don't know the full details so I'm reserving judgement on who's to blame. Still, at face value .... and at deep value too, having the things documented should be done anyway.

[@barrykp]

The issue I saw was couched as a request for documentation (maybe it's a requirement for rust?), but the hostile response was, as far as I can tell, because internal interfaces in the kernel are not stable and the norm is that when you change/break an interface, you update everyone else's code that was using it. Now if you're a C programmer and there's a rust copy of your C interface somewhere, it may be your responsibility to go fixing a bunch of rust code cause you changed something. And that's what made that file system guy in the video lose his shit.

[@AllanSavolainen]

I think there is two issues, the lack of documention is one, but the real problem is that the Rust people are asking the C devs to create said documentation. Which is a problem in opensource development, you basicly never should demand other developers to do stuff for you, you have the source, do it yourself. It would be better for he C devs too to have said documentation, but they don't need to have it and prefer to use their time to develop new things. Second issue is the speed of change, Rust is wanting too much or too many changes or too much work from the C side. If you have worked on piece of code for decades and suddenly an outside force wants you to change how you work and it isn't immediately obvious how it will benefit you, it can be jarring. And people generally hate change. And as a spice, it doesn't help that there is also this vi/emacs, or PC/Amiga divide between C and Rust and both sides have plenty of vocal people publicly despising the other. Give it 5 more years and maybe we have more mature interoperability in the kernel, and some documentation etc.

[@CallousCoder]

@@AllanSavolainenindeed what was also my take away from that row. And the Rust people shouldn’t want to rewrite stuff and pull over the whole system so they can develop easier or faster. This is a bloody kernel not a programming language . This runs on almost a billion devices, you need to make minimal well calculated and testable incremental changes as to not cause massive compatibility or stability problems. It seems the Rust boys are not very exposed to critical system development yet.

[@neko6803]

i would go a step further and would claim that its a problem of developers being potentially unable to give the documentation because they themselves no longer know what their own code does. The lack of a need for documentation probably means those people never wrote any and now they CANT give a documentation because they have no idea what their own code is doing

[@neko6803]

@@AllanSavolainen well yes but the way you wrote it is misleading: the Rust-Bindings (which are written in C) as in the place where the rust code hooks into the C-Code dont have proper documentation. The Rust people cant write proper code if they have no idea what function expects which values as a response from the rustcode and what values are potentially assigned to special purposes on the C-Side. And the C-Devs are unwilling or much more likely frankly unable to give that information (because they themselves do not have it because they forgot because they have no documentation on it). And i side with the Rustpeople here saying "you wrote the code, so please include a documentation of your code that i can work with to write my code." Its fine to have no documentation if it is a small project and if you are the only one working on it. But if you write code together with others, this type of Documentation is mandatory, because by the time you get back to your code from developing new things you yourself have no idea anymore what the f your 1s and 0s are doing. Documentation is especially important if its a project where someone else is expected to come at any time and try to make a suggestion how to make the code better or if you might drop the maintainership and someone else wants to pick up the maintainership instead. You cant do that without documentation.

[@ryman1]

Is Linus morphing in to Saul Goodman?

[@turanamo]

Well, that settles it, then. For someone who wrote Linux and Git, to predict Rust will not be a failure is reason enough, I guess.

[@ytfeelslikenorthkorea]

well... Even if it will be a failure in Linux Kernel, it won't fail as a language (adoption).

[@ytfeelslikenorthkorea]

@@pluto8404 statement makes no sense

[@rosomak8244]

@@ytfeelslikenorthkorea I have seen too many fancy new programming languages come and go to buy in to that.

[@nikolaikalashnikov4253]

WOOSH... Linus' statements went right over your head man... To interpret... ...He was basically saying (in a polite way) that if you truly believe in *_Rust,_* then go build your own *_Kernel._*

[@TremereTT]

@@ytfeelslikenorthkorea Rust is an odd one. There are people that actually use it in a non scientific field. But it's very surprising considering as a language it's more of an academic excercise to prove a single point, just like it is done with Haskel(Haxel, Hascle, Haxle...?) . "While Programming should be like Math (Haskel)". realy only caught on in Whitepapers. It has no real world effect. "Memorysafety should be absolute and enforced by the programming language (Rust)" . Rust managed to have smal real world effect. The Problem with Rust is that while it can be usefull. It's simply too hard and unelegant, making even simple problems into a difficult feat, so realy only extreme fanatic enthusiasts would use it. Rust might need some change that makes it as easy as other languages. I'm sure if that doesn't come, it's gone.

[@tavishn]

I was at this event which happened like 10 months ago, and this whole interview was a short conversation, but it's kind of funny seeing clippings from this same interview still being fodder for more content... I see videos on my feed still of people still talking about this.

[@10e999]

It's not just infrastructure. Rust is very opinionated about a lot of things.

[@Lambda_Ovine]

so it's C, it's just that we're far more used to it so we take it for granted

[@musiqtee]

Programming languages are “opinionated”…? Surely, _users_ of them have opinions - or I’m just missing something about high levels of abstraction…😅

[@10e999]

@@musiqtee e.g. the borrow checker is an opinionated way of providing memory safety. It force the program to be architected in a certain way. It's not necessarily a bad thing. But it is opinniated.

[@musiqtee]

@@10e999 That’s absolutely right… However I understood the conversation (the video, Thorvalds) to be about the ongoing kernel dispute (opinions) - therefore also the OP’s comment. Guess I’m just not “high level” enough… 😅👍 That said, “aggressive” kernel level memory management seems (to me) to be a good way forward? The last months have been pretty ripe with both mishaps and malicious exploits. The world (sic) is a little different these days…

[@turolretar]

What a donut fucking word - opinionated. I fuckin defy anyone to find one fuckin thing that isn’t “opinionated”. The only thing that isn’t opinionated is nothingness, but it’s also completely pointless. In other words - stop with this nonsense

[@DavidAlsh]

I just like the fact that function signatures are implicitly documented by their type signatures and that standardized documentation can be generated directly from the code. Interopting with system calls today feels like stone age programming. Why is it acceptable to need to read through a friggen text file you're not even 100% sure relates to the function you're calling to understand what it means when you pass a 0,1,2 or 3 to an ambiguously named parameter? I realize that Rust isn't everyone's cup of tea but if you don't use it, for the love of god, document your public APIs excessively, unambiguously and don't make me leave my IDE to find it.

[@OlTrailDog]

What a great outlook and attitude.

[@mohamedaladwan8083]

i like how linus is looking forward for a new os

[@rosomak8244]

Plenty of clueless young people have decided already that there is time for a new OS. They went all nowhere. In esp. there have been plenty of unsuccessful attempts to actually use Rust for such endeavors.

[@FFlow]

@@rosomak8244 Linus himself was once that clueless young person that decided to write his own OS, so who knows. Maybe at least one person will get somewhere with a new OS.

[@IIARROWS]

@@FFlow Yes, in the 90s. The problem is that "clueless Linus" didn't decide to create a kernel because other kernels were written in a different language he didn't like.

[@Gwarzonicus]

@@IIARROWS lmao so on point

[@-_James_-]

@@IIARROWS Linus, in his typical "forward looking" manner decided he wanted a monolithic kernel based OS instead of the microkernel architecture of Minix (the OS Linux derived from). There's nothing particularly forward looking about Linux. Never has been, never will be.

[@75hilmar]

I don't know it for sure, but this is my impression over and over: Linus seems like a prophet if some sort to the Linux crowd and I think that has a reason. They seemed to have made Linux their utopia and he is just talking common sense, infra and market necessities. That's why he comes across like some messenger from the outside. Because they excluded the outside from their linux utopia. This is not to bash anyone. People build their own perfect world everywhere all the time. Just one point to think about.

[@vranigavrani]

So far what i have figured out is that more person spends time using 1 programing language it becomes like religion to them. Its just nature of the craft.

[@ItsYumshot]

I love this take, and completely understand why there would be alot of headaches, but hes passionate about his project. Its his. He wants greatness. Hes seen the downfalls first hand, and it makes sense that the people maintaining would have their own opinions about it especially when he describes not having a full understanding anymore. Its a massive codebase. Youll never have every avenue understood, thats why you have professionals to help you with the long standing knowledge of your own system as its progressed. I see it as positive even if people have to step away.

[@complexity5545]

Just wrap all the Rust code with "unsafe."

[@vasiovasio]

😂😂😂

[@RustIsWinning]

Classic deluxe that people think we have to use unsafe everywhere 😂 Did you also count every line with that keyword? 🤡

[@rosomak8244]

The fact that they used "unsafe" instead of "unrestricted" shows the delusions they have about the merits of those things.

[@RustIsWinning]

@@rosomak8244 Did you take your meds today? 🧓💊 Also you dropped this --> ♿️

[@RustIsWinning]

@@rosomak8244 The fact that you complain about a keyword is hilarious 😂

[@AndrewKelley]

thank you for the editing

[@p07a]

I noticed that too. It’s very pleasant, like someone edited a piece of written document and made it flow very well.

[@Onyx-it8gk]

I'm all for memory safety and the benefits of Rust, but in practice this has been a disaster. I think the only thing that can solve this is to get a new generation of Linux kernel developers who aren't so hostile to Rust, and a new generation of Rust developers who aren't so evangelical and dogmatic.

[@samjiman]

Probably too many smug Rust developers who think they know better than C veterans. Honestly I think they should stick to making their own kernel. Some more competition would probably benefit everyone.

[@mmstick]

@@samjiman The vast majority of kernel developers want to use Rust. The only smug people are those in the comment sections making statements like yours.

[@tablettablete186]

​@@samjimanHonestly, a Linux compatible kernel can be very good. And it already exists: Redox

[@samjiman]

@@mmstick Go play with your stockings. Rust is like a religion to you people.

[@samjiman]

@@mmstick D's the future.

[@rsgilbert6152]

That last part was really good and inspiring

[@chrispbacon3042]

Linux is more than thirty years old no wonder people are beginning to c rust. I would recommend a good spray lubricant to get in those tight spots a keep that kernel well lubed and stop the drivers from seizing.

[@Cyco_Nix]

As a long time C dev, I blame the C devs as much as the Rust devs. Not all of them, of course, many work fine together. A lot of it is nothing more than tribalism. Devs pointing fingers at one side or the other, need to look in the mirror.

[@jacobitosuperstar]

the DRM maintainer got shot down several times just for asking better documentation in the C bindings of the different interfaces that she has to use. As for what I have seen or experienced, the main issue stems from the lack of documentation in what each C call needs for everything to work without issues, and some of the main developers having issues with providing them, or outright denying it and attacking directly the rust implementations. So even though I do think that there is a bit of tribalism , some senior Kernel developers are putting up to much friction.

[@anon_y_mousse]

@@jacobitosuperstar And yet somehow the C developers who work on the kernel don't have a problem with that because for many C programs the code *is* the documentation. The real problem is that the Rustaceans can't read the documentation and want it translated, and all at the expense of the C kernel devs. Time is money after all.

[@Cyco_Nix]

@@jacobitosuperstar Yeah that isn't cool. There is no reason for that type of behavior.

[@jacobitosuperstar]

@@anon_y_mousse you are telling me that this things are not issues for new maintainers (even the ones that work with C) and that they don't complain too about this kind of behavior, and that if you are writing something like a driver, you should understand how everything works, even though Linus himself said that the C that they write is different C??... Holy fuck dude, I suck at my job then. Sorry mate, don't mind me, I hope one day I can stop being a waste of oxygen unlike yourself.

[@pluto8404]

People are inherently adverse to change. They can suck it up and grow up.

[@DavisTibbz]

Rust Foundation leadership is just more concerned about political movt than maintaining their language

[@sharp531]

Seems like many linux/language devs have this problem. If Gnome is half as disfuntional as is rumored there is problems.

[@JSiuDev]

Linus opinion was not about whatever programming language being used. It is about handling kernel exceptions, which is very important in production system.

[@urisimchoni3936]

The talk that caused the "explosion" in the Rust-for-Linux scene is a presentation about Rust bindings for file systems. And the backlash was that if you change something in the FS infrastructure, you break Rust and then you have to be a Rust expert as well, and the folks there didn't want that. And I think the way you introduce something like that is by bringing value. Infrastructure doesn't bring value, it enables value. Value in FS area is a kick-ass file system written in Rust. If you don't have that, why would you need FS Rust bindings? So you build your new shiny Rust FS, add bindings, maintain that for a few years out-of-tree, and then people would be keen on bringing your FS and the bindings into the kernel and start negotiating and bike-shedding over your Rust bindings. And finally you make it and those C zealots suddenly don't have a choice but to learn Rust.

[@rayo3914]

Religion

[@MrDukeeeey]

Not religion. C is a very simple language. Rust is a far from trivial. Language complexity is probably a real barrier to entry for devs especially if they are working for free in their free time.

[@rayo3914]

@@MrDukeeeey C is a very simple, so its super advantage of it and a reason to use it instead of wasting your time on Rust. And i am the Rust fan.

[@jmz8086]

Agreed. Well said.

[@RustIsWinning]

@@rayo3914 Fake Rust fan!!!!

[@ulysses4536]

I think Linus here was amazing. I loved everything he said!

[@terabit.]

Gay !

[@aytviewer2421]

I'm all for Rust fanatics working on their own OS, and C fanatics staying in their lane with traditional Linux. I do see an issue with the Rust crown imposing major change requirements on the current project just for the sake of allowing Rust developers to add code in RUST. Nothing is stopping Rust developers from contributing as long as they adapt to adopting C. Otherwise, Rust programmers should happily work on a next generation OS that has an opportunity to be better than today's status quo.

[@oneeyedphotographer]

Probably Linus understands the complexities better than you do. If Linus says Rust code is fine in the kernel, I accept his opinion.

[@username7763]

I have worked with C programmers who thought the C++ stuff was overly complex and not helpful. It turned out their C code simply skipped basic things like error handling, null pointer checking, array bounds checking, handing of error codes, heap exhaustion, freeing memory, rolling back when something failed. Yes, your C code can be simple if it doesn't do any of the important, complicated things that it needs to. It sounds like a bit of this is happening with Rust support too except the language forces you to do it while C++ doesn't.

[@NinjaRunningWild]

That's just down to bad programming. That's not the fault of the language.

[@mmstick]

@@NinjaRunningWild A language that allows you to write code badly and yet still compile is a fault of the language.

[@user-baev]

​​@@mmstickYou can't make this argument in C vs C++ discussion. C++ allows you to shoot himself in the leg at least in same capacity as C. If not more. And I think Rust is too weird of a language. Very opinionated and hard to grasp.

[@experimentalcyborg]

tbh imho C++ IS overly complex. With 40 years of backward compatibility, there are a hundred different ways to do something with only one "correct" way that changes almost every major revision. Nearly everything can be overloaded, macro'd or templated, so many code bases are basically their own language. It's absolutely maddening. And that's not even touching on the 1980's tool chain, dependency management is a total nightmare. ... and then there's cmake... which is a horror story of its own... the docs are simultaneously verbose and useless... i can't blame anyone for sticking to C even in 2024 lmfao.

[@mmstick]

@@user-baev I've worked with high school students that had no prior programming experience. Anyone can learn Rust. It's easier than C and C++.

[@rosomak8244]

The main problem is: please show me where there is a fundamental memory management issue in the linux kernel? Where? Because Rust in the kernel seems like a solution looking for a problem.

[@lolilollolilol7773]

I believe the idea was to use Rust for vendor modules. Forcing them to use a memory safe language reduced the risks when you add them in the kernel.

[@username7763]

There have been a lot of different kernel bugs. By no means is the kernel code bug-free code. One thing that compile-time checking can do is catch some types of bugs before they get into the code. Who knows how many unfound bugs remain.

[@JohnnySacc]

Also rust offers much more than memory safety, the biggest one to me is maintainability as more of the program's invariants can be expressed directly in the source code as opposed to it being scattered around comments, docs and maintainers' brains. Rust is extremely explicit which can be a downside but in the linux kernel I think it will be a huge upside.

[@stargazer7644]

There is a fundamental memory management problem in C. The kernel is mostly written in C.

[@greasedweasel8087]

If I can throw my hat into the ring, memory management isn’t the issue here. Like yes it’s a nice guarantee, but Rust does a lot besides that in terms of general design. The borrow checker, for example, tracks the lifetimes of values and makes programming with pointers much nicer because references as a construct are literally just pointers but checked at compile-time to be valid. Rust lets you prove features of your code in ways that C does not, because you can express ideas about the flow of data to the compiler and it will ensure you’re doing what you’ve told it you want to, whereas in C it falls on the developer to ensure the program behaves correctly. I think that’s what the rust folks are on about tho

[@reckless_lord]

Try doing multi-threaded stuff in C vs Rust... To me Rust is pretty amazing and has things in place to keep us from making mistakes. I don't like the comparison to Java simply from a standpoint of rust is very fast.

[@istudy9]

Idk what these nerds talking about, but please keep the internet working

[@CrackThrough]

isn't the main problem of using Rust project ecosystem or management? you can't just replace the whole thing from C to Rust in a day because it takes time (given how big the project is), and there'll always be a state where C and Rust co-exist in the project. As a project manager or developer, you have to know both now and begin slowly migrating from C to Rust. That sounds like a nightmare to me... You also have to take account for submodules and other libraries since the whole design philosophy is different. APIs may change because of that. Dependency control would be even more complicated. Unless you're crazy or unthinkably skilled, it would be really difficult to pull off while making the project stable. I like to think it's simply not feasible and unrealistic, I don't know how others thinks though

[@Freshbott2]

I don’t know or like Rust but I don’t see why the animosity turned out different to other languages. It’s normal that ecosystems and projects can have mixes of languages. Whenever there’s something new that’s a whole new paradigm or a shift in mindset the community doesn’t seem to question new adopters even if they don’t embrace it themselves. That was true of Java, Python, Swift etc. but none of those were suggested to replace C. I think the animosity has more to do with the C community and a sense of ownership of certain topics and an ironic claim of authenticity like a user is going to use a program and know it was written by a “real man” and that it’s the product of discipline rather than principle lol. All things start slow, and for a job like a Rust’s the start is slower. I’d expect it’ll do best in new things till the ecosystem is mature enough for Rust tools to replace C tools, not for C code to be swapped out for Rust code within existing C tools that already work. In principle Rust is the correct paradigm and if not for the C legacy and ecosystem, C would be the undeniably wrong tool for things that need to be secure or safe.

[@CrackThrough]

@Freshbott2 I think what you said makes sense. It seemed to me that elitism, in fact, does factor in it as I've lately seen it multiple times. but maybe that's not all. to be fair, something like a kernel that's being used in production, also known for its stability and security, may need to be considered and managed differently. it's true that we usually don't have a project like this. regardless of what language it's written in and which language it's being replaced to, it shouldn't affect the production environment and ecosystem until released. well, I mean on paper. like you said, it seems that's not how it's working right now 🫠 but on other projects, that could be the case. I'd like to think that there are a lot of mature developers in the linux community. surely, except for these few people, they know what they're doing. right?.. EDIT: holy heck I read it wrong you basically have the same idea lmao 😭 I shouldn't reply when I'm half asleep

[@WiseWeeabo]

C26 could technically add some compiler-supported features to allow a lot of the same form of safety and checks if you want it (or when using certain types). It would for sure be an improvement.

[@oserodal2702]

With the way most C production and enterprise software is stuck in C99 or C11, they should just add more breaking changes in future releases.

[@ivanv754]

Yes, I’m looking forward to using C26 in 2046.

[@RustIsWinning]

​@@ivanv754The year is 2068 and C-cels finally proved that memory safety is indeed possible with a quantum computer just like they predicted.

[@johndoe2-ns6tf]

@@RustIsWinning how much code have you written in rust? let me guess: ZERO. How about in any other laguage? let me guess: also ZERO.

[@RustIsWinning]

@@johndoe2-ns6tf YT filtered out my legendary comment damn. Also it's a little bit more than zero but you are close.

[@erkintek]

I loved how you edit/summarized their talk good work, and thanks. C is language, and you need tools/own libraries , rust comes with those included in. I don't see anybig framework that doesn't serve you its own structures ie QT.

[@achrefnasri8847]

It's hard to mix C and Rust codebases. As much as I love Rust, it shouldn't be shoehorned into an existing project like the Linux kernel. Don't get me wrong, memory safety is an important issue, but it's not THE issue for Linux kernel developers (You don't create the most widely used codebase in the world by recklessly using unsafe C code) If Rust developers want to be fully integrated into kernel development, they should build their own kernel based on Rust and prove its worth in practice....because talk is cheap

[@einargs]

They have built their own kernel in rust and proved the usefulness. Several times in fact.

[@minneelyyyy]

I feel like if Linux got competition it wouldn't be because they wrote it in Rust (it might help a little bit, but most people don't care what language something is made in), but that Linux is so bogged down by decades of design choices and old paradigm. Linux was revolutionary in that it was an open source operating system and wasn't bogged down in the same way BSD was thanks to a lawsuit, but it's still designed after UNIX which is *decades* old. We need another OS revolution before Linux loses any market share. I'm not sure if simply writing it in Rust is that revolution.

[@rosomak8244]

There is some accumulated value in it being old. It has been practically proven. Plenty of people seem to underestimate that.

[@comradeklaymore]

RedoxOS (and others) are writing new operating systems in Rust with different design choices

[@rursus8354]

1:50: I've heard pupils propone vi and in particular vim. Never emacs. So vi won the argument.

[@SavvyNik]

Wait you’ve been with vi this entire time…

[@vaisakh_km]

​@@SavvyNik emacs is the best.. ..operating system, but i only need a text editor :)

[@formbi]

not on my computer

[@lellyparker]

For me, graphical IDE's won the argument. No idea why anyone insists on fighting with arcane key combinations these days.

[@stargazer7644]

What is emacs? ;)

[@DVRC]

What if Modula-2 and Oberon were revived for systems programming, also for kernel modules?

[@JLT9150]

I'd trust Rust code to be secure more than I'd trust C code to be secure. Rust is like having guardrails for writing code. It does abstract quite a lot and is not always secure even when not using unsafe. C demands you do it all yourself, grow and maintain deep understanding, maintain strict discipline. I'd trust a C developer more when it comes to debating secure code over a Rust developer.

[@Archimedes.5000]

lmao

[@Sever3dHead]

lmao

[@lorili6885]

I would disagree. A rust programmer won't be able to even compile their code without understanding all of the memory safety things. C programmer can build a working system without giving a **** about safety

[@Sever3dHead]

@@lorili6885 more like borrow checker, as there is perpectly memory safe code that borrow checker does not allow

[@Finkelfunk]

The issue you have is that not everything in an operating system _can_ be done safely. Sometimes, you just HAVE to do unsafe operations and weird conversions in an operating system. Take the boot sector for example: You have to load the kernel _somehow._ All of this is done with raw, unsafe pointers. There are systems that just can't function in a safe way, a lot of what is done there is, by default, unsafe code. That is just how things have to work. You can't have 100% safety in an operating system. By default, this is just not possible. Couple that with the error handling Rust does. Rust isn't bothered by an application crashing with a panic. But the Kernel doesn't allow panics. You have to either handle the error explicitly and "catch" the system, or you discard it and hope it won't cause a crash. An exception will cause the whole system to become unresponsive and worst case kill the error reporting mechanisms. A graceful failure won't. And Rust isn't designed for this undefined territory because the borrow checker can't work with uncertainty. But the Kernel works like this. These are the architectural design patterns they were talking about. Rust makes this infinitely harder if you don't use "unsafe" and if you do, there is no point to using Rust just for the sake of it. Rust boys just need to accept that this is the reality of any operating system kernel.

[@davidespinosa1910]

Where can I find a good discussion of Rust vs C pros and cons for Linux ?

[@antinatalope]

I recall the days when Washington was pushing the use of Ada for systems safety. That went nowhere fast. Now they're looking at Rust for the same reasons. Personally, I prefer a standard C library I can rely on. The idea of mixing doesn't appeal to me. I just don't know Rust beyond reading bits and pieces about it, and I'm too old to learn another systems language. I do hope that other kernels do make use of Rust, and are built from the ground up. Whether I'm around to see it, that's another issue.

[@RustIsWinning]

I mean Ada never made it into the kernel so...

[@jeffspaulding9834]

​@@RustIsWinning Good point, someone should get to work on getting Ada into the kernel. I have zero desire to learn Rust but I'd be willing to give Ada a spin.

[@CyrilCommando]

Rust doesn't even have compatibility with C from what I understand. No ABI. In other words there is no way for Rust code to communicate. I understand how wildly impractical this would be, but maybe their resolve to put Rust in the kernel is that strong, or they have created some way to actually interop between C parts of the Linux kernel and Rust parts, but I don't know what that would be and it's simply additional overhead that wouldn't exist if you just used C, like we all should..

[@einargs]

​@@CyrilCommandoholy shit man, maybe actually look things up before spouting nonsense. Like literally any other language that does FFI, Rust offers a way to mark a struct, enum, or function as using the C calling convention. That way rust can call C and C can call Rust. I think you should stop talking about things you know nothing about.

[@Andy-l9p]

C has solid consistency without frequent updates and changes which is why i love it and it should be used in kernels as a standard

[@nicejungle]

Kernel need to be stable. Therefore no experimental languages that change standards each version, like rust

[@lindhe]

I have only heard two good arguments against Rust in the kernel. One is that it's (allegedly) harder to find Rust programmers than C programmers, which I think is a solid argument as long as it holds true. Your argument is the other one. I love Rust, but before it can enter the kernel I believe it must have a proven track record of great, stable, maintenence over time.

[@mikesilver2283]

YES. THANK YOU FOR COMMON SENSE.🙏

[@scanex]

Would have been much more interesting to get LT's view of the future of micro kernel OS. Redox that is mentioned is a micro kernel OS.

[@rtwas]

Rust: Yet another language. So in some number of years, some other group of yahoos will try to inject some other language into the code base (of our favorite code somewhere), touting its superiority (mainly because it's novel and they were bored or something) and denigrating C for being *evil* for one or more reasons. I knew a guy who was a language junky. The more varied and novel the better. He was very bright and was able to master many languages with ease. He thought very highly of himself for managing to integrate three separate languages into one project. I could only wince at the prospect of trying to maintain that code base. I pressed him for the reason for doing this,h e became upset for me even asking. For Linux, pick a language and *stick to it*. If you wanna convert Linux to some other language, please wait until I am dead. Thanks.

[@RustIsWinning]

Found a real C kernel dev lmao

[@_TheDudeAbides_]

rtwas: yet another pretend expert.

[@viktorstojanovic9007]

so we should just continue using c forever even tho it's been outdated for years now

[@RustIsWinning]

@@viktorstojanovic9007 You know the best part about C? It's an incredible boring language. There is nothing that is fun to code because it's lacking cool features. Why on earth would I want to use a language that makes me fall asleep? No wonder C boomers like it so much. It helps them to go to bed LMAO 🤣

[@rtwas]

@@viktorstojanovic9007 Outdated? It (C) does *exactly* what it was designed to do. It does'nt need to be anything else. Saying C is outdated is like saying a fork and spoon are outdated. C is a lot like writing in assembly language, you need to understand the logical machine at an intimate level. It seems to me contemporary coders want logical resources abstracted. They just don't seem to want to work that hard. When you work close to the metal you can't get away with that. An OS like Linux works close to the metal. For a new OS project if you want some nice ideal, abstracted framework to play in, knock yourself out. Please leave my precious Linux be.

[@SoulExpension]

Rust is a good step. Easy code review for general safety and interop; takes a load off. If you build a wall of safety, someone will knock it down with an edge/niche case. The Rust team knew they had to provide exception code for such scenarios (i.e. interop and architecture) or risk being viewed as a Lego bricked language. So, my analogy is Rust is like chiseling granite for a solid thing; C and Zig is like using clay but comes with more responsibility. My arguments are not against Rust, but of the difficulties of functional and procedural language. In light of Zig dropping async, I have only seen async, interfaces, and event loop employed well in OOP languages. These are concepts that mesh userland design with the code. Pushing it down to functional language without coloring is difficult, so inclusion in the stdlib comes into question, side effects exposed. So with Rust, you can question the amount exception code you are using... forget, manuallydrop, drop on the stack, or allocators, box::leak, any FFI. Personal choice is I would rather just allocate and destroy. The borrow-checker is a relief but not a magic bullet. Code analysis and getting away from libc was a priori.

[@satria3001Al]

Rust is a language, and C is a language, so just learn them and use them wisely. Great opinion, Linus!

[@curio78]

Not quite. Rust is a language+memory handling framework as part of syntax and compiler. C is just the language where you can add the memory handling framework as you need or like.

[@Alysonhower]

What's the problem? Just wrap the Rust parts with unwrap() or expect("This should never fail. Good look debugging it")

[@RustIsWinning]

Damn we found a comedian right here 😂

[@therealmccoy7221]

Linus made the perfect argument: the "memory safety in Rust vs "memory unsafe C" argument for Rust is a red herring because there are tons of tools in the kernel to provide memory safety for C. I mean, do the Rust people really think you can develop the system that runs the world 24/7 with an "unsafe language" ? Give me a break. Outside the kernel there are also tons of tools (Valgrind of course coming to mind first) that deliver the "memory safety" in C that the Rust people claim to have the copyright on. And of course just using const pointers and static analyzers catches most if not all of the memory bugs. It's not that the C/C++ community was sitting on their hands waiting for Rust to come and save them. That makes Rust an extremely complex language with little to no advantage over C/C++.

[@chichu_nichu]

what is bro yapping about

[@fedfer]

The thing is, all of these tools sit outside the language, they are not features of the language itself but rather tools people have developed to have a better developer experience. With no integration with the language itself such tools will never be able to achieve what Rust or other memory safe languages can. Also is Rust such a "complex" language when you consider all the tools you need to even mimic a fraction of its features in C? Because those tools add up to a lot of complexity themselves.

[@stefanalecu9532]

And even then, it isn't like Rust is the first language to have figured out memory safety or being safer than C. Ada has existed for ages, standardized in 83 and has been and is still used in plenty of critical software.

[@therealmccoy7221]

@@fedfer Running your C code in Valgrind sure is a lot less complex than understanding "lifetimes".

[@minerscale]

@@therealmccoy7221 Lifetimes are a concept you need to keep track of when writing your C as well. When you run a function that returns a handle to your shiny created object, you need to keep track of that handle and call the requisite free function at the end. The space between the object's creation and deletion is its lifetime. Having your language guarantee that all usages occur between the creation and deletion of an object and that an object is freed exactly once is one honking great idea.

[@mykolamorozov2099]

Where can I find some high level view of how Rust code communicates with C code in linux kernel(and vice versa)?

[@esra_erimez]

I completely agree with Linus Torvalds on the matter of Rust vs C

[@cybernit3]

Exactly, Linus points out with embedded system you need optimization. RUST is like C++ with the compiled code efficiency level; C is a bit more efficient. So Kernel and Drivers should be at the most efficient build code level as possible; especially for Real time or Gaming systems. If they make a RUST Linux for the government; where they want better memory safety and security; then it might find a niche market like Linus stated.

[@secretzpt176]

@@cybernit3 That's not what he said, nice try. People say Rust is a religion, C doesn't seem to be much better.

[@nigratruo]

I would say that this is the typical fight of the old against the new, the old wants no changes and glorifies everything old, just because.... it is old. But a fair comparison has to be done between the old and the new and in IT, the new is almost always better, just because it was designed to be. And in no other field is the new so useful and the old so bad and obsolete, as OSes are not beautiful in a design aspect, there is actually no artistic aspect to it (like a old car, while mechanically being total obsolete garbage, still has a nice artistic design), but it is all based on pure efficiency and power, not what it looks like. Many older people suffer from neophobia, they fear all new things because they either don't know them, don't want to know them or are unable to still learn new things. Linux needs many reforms and necessary improvements, these neophobics want to block these important upgrades. It is clear that Rust will improve the Linux kernel and there is one reason why Linux is now the most dominant OS on earth: Constant improvement and reforms, out with the inefficient old, in with the improved new. That is why UNIX is dead, it died deservedly, it did not improve anymore.

[@rosomak8244]

Every time I see a project starting to depend on a new fancy programming language in some kind of way I always go: "Fuck It wan't be possible to compile that from scratch any more." Python is most notorious for that.

[@RustIsWinning]

@@rosomak8244 Are you okay? You do not compile Python projects 😂😂😂

[@aaronbredon2948]

What? I've compiled Python from scratch quite a few times. Once I even had to compile GCC from scratch as a prerequisite to compiling Python from scratch so I could get a recent enough libC. And after compiling Python, I had to compile the Python modules needed.

[@anandhunt1000]

everything related to me are tools, as long as things are achieved, i am okay with the tool.

[@СаняСаня-з2т]

I don't understand why Rust users tying to become a part of C-linux community instead of writing their own OS i.e. Ubuntu Rust linux (URinux)... give it a go! )

[@No-mq5lw]

Redox

[@asdfghyter]

they have already done that (e.g. Redox OS), but Linus explained in this video why this approach is more productive: if you want to write Rust modules for a kernel that is usable today and not in 20 years, the Linux kernel is the better choice

[@asdfghyter]

and maintaining a fork is just needless duplication of effort

[@larswadefalk6423]

Kernel people should be humble to each others and try to agree here. I think rust is a good step really. But I sense that it will have a limited role to play. The really hardware near stuff i have a hard time to see how and why it would be done in rust. Of course some especially adapted "runtime" crates for rust must be done for kernel. Rust has what i feel a sort of crate contagion that easily happens. Crates depending on other crates where some crates even depends on different version of the same crate. Cant have that problem in kernel. I would see rust shine in kernel if drivers could be written with that, using a sort of framework for things needed, like sysfs stuff etc. While the core code of the kernel still remains in C.

[@SuedwestlichtMusic]

"fatal error: your Rust environment is older than 2 weeks" That's what I am afraid of if a generation takes over that doesn't care about backwards compatibility.

[@RustIsWinning]

Dont care. The future is now 0ldmann.

[@guest7329]

yes, it has frequent updates, but code from 1.0 still compiles fine

[@johndoe2-ns6tf]

@@RustIsWinning well, your future is as bright and interesting as watching paint dry.

[@RustIsWinning]

@@johndoe2-ns6tf John Doe the ho3 stay mad as always 😂

[@johndoe2-ns6tf]

@@RustIsWinning don't worry. i'm sure with all the crack and meth you're taking, watching pain dry will be very exciting. LOL. Ups, sorry, crack and meth are boomer drugs, right? So, I guess, it's tranq and flakka for you.

[@vishalmishra3046]

In this day and age of AI assisted development tools, languages esp. C vs. Rust don't matter as much as they used to. People just need to grow up and be open to new safer than C languages and be data driven about the pros and cons of both approaches instead of being emotional and religious about these perfectly legitimate differences.

[@gamertechkid1490]

We don't need your Intro Pre-Amble bud. It adds nothing "LETS WATCH THIS VIDEO WE ARE ABOUT TO WATCH"

[@Lemon_Inspector]

pre-ramble

[@kavehtehrani]

I code in both Rust and C. Different tools for different jobs. I think keeping Linux to C is the right choice.

[@comesignotus9888]

Linus is a wise and kind man. As for Rust, I'm afraid that the fate of Esperanto is what awaits it. Esperanto per se is nor ideal neither a horrible language, just OKish, but unfortunately it was primarily adopted by too ideologically charged and too zealous communities, which effectively had precluded and precludes till now any mainstream adoption of the language, thus defeating its original purpose as a universal "second language".

[@defeqel6537]

Problem with languages, including programming languages, is that there is no such thing as ideal. The only problem with Esperanto that I have is that the second person singular pronoun "ci" isn't more widely used, with everyone opting to use the plural form "vi" instead, which is very Middle European, and the reason English replaced thou with you, and you with "ya'll"/"you all". Other people have other problems with it, like the existence of genders.

[@johnsmith34]

Real language is an awful analogy. And the conclusion you're trying to draw is somehow worse. Esperanto's success or lack of it has nothing to do with ideology. It has no reason to exist. There's little to no reason to learn it, and every child who was made to learn it as a first language has been set back in life. What does this have to do with programming languages again? "anti-ideology" is the dumbest ideology.

[@nandoflorestan]

Wow. Everything that was said in this thread is mistaken. Wow wow wow. - Rust and Esperanto have nothing in common. - Esperanto is a wonderfully well designed language. That's why it can be learned in 6 months to 1 year, and then be used in tourism, diplomacy, science, technology, philosophy and literature. Esperanto is not a toy. It takes someone 6 years of study of English to get to the same level. On the other hand, Esperanto is a product of its time. There are many improvements that could be done to the language, but by the time those were realized, Esperanto already had thousands of speakers, and mostly they felt Esperanto was good enough, so the improvements never caught on. - Esperanto never became a *universal* second language, but that is not due to internal shortcomings, it is due to FUD like the one spread right here. It is well known that the 2nd language is a barrier for children and they can learn Esperanto to easily and quickly overcome that barrier, and then the 3rd language can be acquired much more quickly. Esperanto can be beneficial as a means to reach other languages, Esperanto is no longer an end in itself. - "vi" is not a problem at all. - Genders in a language are not a problem at all. - There is plenty of reason for Esperanto to exist. It shows how to design a language with very few and very uniform rules, no exceptions, how to severely cut down on the amount of vocabulary that needs to be memorized, how to create something easy to use in the realm of language, such that rational expectations turn out to be the reality. The idea of language neutrality is also really important, although maybe to realize how important, one would have to live abroad for a couple of years or more. - Learning Esperanto as a first language does not set anyone back in life, not at all. And no proof to the contrary has been provided here. - The only thing I agree with is, Esperanto has nothing to do with programming languages, there is no parallel at all.

[@johnsmith34]

@@nandoflorestan I consider having to learn a second language in order to talk to children their age in real life a setback. There are plenty of reasons Esperanto was created, but they are not reasons to exist as an actual language. People and community are the only reason for a language to exist, and Esperanto only has those online.

[@soloflo]

@@johnsmith34Klingon might arguably be a more fun and useful language in comparison 😂 particularly for annual conventions

[@johnnemeth6913]

The difference with the vi vs Emacs debate is that your choice doesn't affect others.

[@zezba9000]

Linux needs a driver kit then it wouldn't have any of these issues and you could write in any language without having to conform to anyone's standard outside the driver kits API. Linux kernel and kernel drivers would remain in the C language. The driver kit would just need bindings for other languages that's it. There's a reason every other operating system has a driver kit.

[@Sierra410]

You already can write out-of-tree modules and, technically, you could even write them in any language you want. You'd be completely on your own, however. If what you're proposing is an API for userland drivers: Userland drivers for devices that work over supported buses exist already. My drawing tablet's driver is written in Python, for example. Supporting completely new, unique hardware, however, often requires changes and additions in existing systems of the kernel. In those cases there's literally not a way to make any kind of API that'd work, since the drivers _are_ the API. For things that want to use the hardware.

[@RustIsWinning]

​@@Sierra410Aint no way there exists a driver that is written in the slowest language ever known lmao

[@Sierra410]

@@RustIsWinning the driver's purpose is to parse _8 bytes_ from a USB packet and pass the data on into the event system. You could write it Scratch or Brainfuck, and it'd still be fast enough to be imperceptible.

[@vasyle2236]

​@@RustIsWinningwell,you are not winning supporters for your language by disparaging other people's language 😅😂😏

[@RustIsWinning]

@@vasyle2236 I don't care what others use. I'm just allergic to C and C++

[@axuh382]

If I ever go in to a conference and they're talking about Linux kernels on the stage I've gone too far and it's time to quit, touch grass and become a gardner

[@sciencefirefly837]

If rust is so perfect why do they just panic in the Linux kernel for some situations. At the end of the day we have to accept that even Rust has flaws and just introducing it in the kernel doesn’t give you a magical boost in safety 😅

[@mmstick]

They don't allow panicking without handling in the Rust code within the kernel. The Rust Linux project already handles what would be panics in typical application code. Panics happen for the same reason they do in C. They're intentional. A situation occurred where it would be wrong to continue otherwise. Perhaps a cosmic ray flipped some bits and made an impossible condition possible. Or an error in the code caused a branch to execute that shouldn't be allowed. Perhaps the programmer purposely wants debug builds to panic in order to get a detailed stack trace to fix the logic error. It is possible to catch, unwind, and handle a panic, so it's not the end of the world if it happens.

[@phitc4242]

I've said it before and I'll say it again and always: no matter the language, it is bound to run into memory issues and/or bugs, at some point. rust included. there will always be some weird bug that is yet to be found. my opinion

[@bytefu]

Facts: there is a substantial boost in safety and it's not magical. Drugs can have side effects and don't fix every health issue they are supposed to. Does that mean we should not use drugs ever?

[@mmstick]

@@phitc4242 That's simply wrong. Rust's syntax was explicitly designed to enable static code analysis to prevent 100% of memory safety vulnerabilities. As evidence of proof, Google's security engineers wrote a report in 2022 where they highlighted in bold text that they have written 1.5 million lines of Rust code across 4 years in Android and had exactly 0 memory safety vulnerability in their Rust code. In the same time frame, 89% of known exploited vulnerabilities were memory safety vulnerabilities from C++ code written in that same timeframe.

[@noweare1]

Linus embracing that wisdom that comes with age and experience.

[@friedrichdergroe9664]

Let's put Haskell in the kernel! Seriously, C has been doing the job for decades. I don't see a real advantage to start stuffing Rust in the kernel at all. There is a lot of C kernel experience, it is well-understood, it is battle-tested, and no surprises. What do we really gain from Rust to make it worth the herculean effort to stuff it into the kernel? Not seeing it. C++ is not accepted into the kernel either, though it would be potentially a better fit than Rust. Maybe I am too conservative, but if it ain´t broke, why fix it? Stay with C.

[@secretzpt176]

"it is well-understood", have you not been following this situation? The C devs got mad because they didn't want to document code that had things like hidden lifetime requirements...

[@k1m1]

Ok he hired a diplomatic coach or read a lot of diplomatic books

[@sebastiang7394]

Anything that prevents bugs and security vulnerabilities is good. That buffer overwrites and overread exploits are still a major problem in 2024 should be a major embarrassment to the it community.

[@EmptyZoo393]

I've gotten to experience those issues first-hand in the embedded world. Read a variable off a rom chip, use it as a (too large) index into a look-up table and--WHEEEEEEE!--watch the program counter fly off into unknown territory. The rom doesn't stay updated with the rest of your code, which makes debugging this one a real pain in the butt. Oh yeah, and your debugger is liable to reset every fifteen minutes. That project really had me looking into Rust, but the vendor support just isn't there in the embedded world yet. There's been a lot of work to get ARM chips going and Rust crates to get the registers properly referenced and chips supported. You're still running at least a week to get a development environment up and running, for a language no one else on your team uses. Give it another ten years to filter through from the Linux world.

[@abhijit-sarkar]

Rust: Thy promise to solve thou problems thou never hath

[@mehmetdemir-lf2vm]

Yes, it is early to say that using rust is a failure, but that time will come and it will be very late to turn back to C or C++. It is an eternal truth that mixing lots of languages in a project is a very bad thing, but people are generally too dumb to learn it without experience.

[@RustIsWinning]

If it is bad why is it so common 🤔

[@Vincent-hx1ql]

I have seen many Chinese programmers called Rust "The Genshin Impact of programming languages". It's basically saying Rust programmers are really obnoxious because they will show up unpromptly and start going off about how Rust is superior whenever somebody talk about other languages, like how Genshin players (mostly the ones in China) will claim Genshin is better when people talk about other games.

[@RustIsWinning]

They also call the us dogs so... your point is?

[@gabrielbarrantes6946]

Honestly, would be great to see another alternative. A new kernel written in rust would be great to promote competition

[@jylpah]

And then the user space libraries, and then the applications. 😉 But seriously, it’s completely feasible. It just needs to start from somewhere. Embedded world is always so fragmented due to the HW, but maybe a RustOS would provide a platform to run (Rust) cloud applications securely and with high performance. Then over time it could be applicable to more use cases. Such a change is completely possible but it needs to start somewhere and start gaining steam. It’s hard to challenge the dominant platform, but never impossible.

[@gabrielbarrantes6946]

@@jylpah I think that with enough motivation it can be done, and certainly the rust community seems motivated to prove their side is better 😂

[@FireCrack]

I think that's what RedoxOS is trying to do

[@therealjezzyc6209]

it already exists... yet no one uses it, because that's just not how that industry works, there wouldn't be any competition without adoption, and no one is going to switch to an OS that isn't Windows or Mac unless they're possibly already using Linux. Linux isn't a product that is competing with other operating systems as a product, so your idea is nonesense on that basis anyways.

[@gabrielbarrantes6946]

@@therealjezzyc6209 does it? So why is people pushing so hard for rust in Linux?

[@TheBreadlord]

I have no problem with Rust in general, but for me it has always felt like syntactic sugar that doesn't add much more than some functional paradigms and memory security - which is fine, but very much usage dependent. I remember when Scala was introduced to the JVM ecosystem: Totally fine, but unnecessary and now it's 2/3rds toward being a dead language while Java (rightly or wrongly) continues apace in the corporate space. My concerns around Rust in the Kernel are that in 5, 10 years the same will happen. Big chunks of code in a language nobody cares about anymore. But that's all they are: concerns. At the end of the day it all turns into opcodes.

[@justdoityourself7134]

Linus spiting facts, C is memory safe when it is needed to be so. It is easily extended with architecture and enforced conventions. Rustbros out here pretending that all c code is raw dogging memory.

[@viktorstojanovic9007]

linus did not say that, he stay on the fence

[@justdoityourself7134]

@@viktorstojanovic9007 lol watch it again he literally does.

[@secretzpt176]

@@justdoityourself7134 He quite literally doesn't.

[@restreflex]

The full conversation from the show kzbin.info/www/bejne/hX7CaYiFhaujp6csi=5C3xGyoyuR_0Rta1 somehow missing in the description

[@the-MaZe]

Why the jumpcuts. With the echo of the sound it is unpleasend to hear.

[@sv_gravity]

7:45 "complete Linux distribution running on most 5G modern chips, so in your iPhone is a chip that runs as its firmware Linux" - is this true ?

[@pabllosee]

Even SFP+ modules are running Linux.

[@Henfredemars]

Yes, but the public information about this is almost zero because the software on their modems is the secret sauce. You won't be able to learn any information without thick NDA agreements. You aren't going to find anything precise about what's running on what chips. Even the firmwares are heavily obfuscated.

[@turolretar]

What the hell, why is this sudden need in safety, I thought memory related bugs indicated skill issues of developers not the shortcomings of a language. What it more looks like is Rust foundation just wants a piece of that pie

[@lolilollolilol7773]

You thought wrong. C is a powerful but also a terrible language, everyone agrees about this.

[@DanCojocaru2000]

It's both. Someone with an equal level of skill will make more mistakes writing C than Rust.

[@RustIsWinning]

Machines will always be better.

[@p39483]

​@@DanCojocaru2000😂Because the C devs will make more software.

[@RustIsWinning]

​@@p39483Comedian. C devs wont write any code anymore because they will be in their retirement home LOL 😂

[@rlevitta]

It’s good that linux is the same everywhere and will run exactly the same on every computer - just like java.

[@gxtoast2221]

"A memory safe architecture" - imagine the hours (and stress) that will be saved by not only the rigorous infrastructure supporting Rust code but the unique attributes of Rust (such as semantic algebraic data types)!

[@anastrophe]

I realize that for brevity it's often useful to make fast cuts to remove extraneous content, but...at about 5:30, there's a fast cut within a sentence Linus is expressing, of literally just one word: "have". That seems a bit dicey to me. Not implying anything nefarious, just noting what seems a bit overzealous trimming.

[@SavvyNik]

Yeah it’s improved in newer vids. But thanks for the feedback!

[@anastrophe]

@@SavvyNik Thank you for not taking it as a personal dig or attack, which regrettably happens pretty often. It's a great video, and the concision is excellent.

[@anastrophe]

"which happens pretty often" IN KZbin COMMENTS, that was kind of dumb to leave out; not that YOU take things as personal attacks often...!

[@SavvyNik]

Haha no worries, always love to hear constructive feedback

[@aesculetum]

rust should never been allowed in linux kernel; the rust community isn’t just infiltrated by people more concerned with politics than the language itself, it is only people who are ideologues first, programmers (if they are programmers) second

[@defeqel6537]

Perhaps. IMO it should be more isolated with clearer rules, but perhaps that is something that will emerge with time.

[@MarcCastellsBallesta]

Wow! Last time I saw Linus he wasn't Linus the grey. I always forget that great wizards can also level up.

[@mmstick]

Surprised that he didn't seem to be aware of the existence of Redox OS. The general purpose microkernel-based desktop OS written in Rust already exists.

[@SavvyNik]

I thought he mentioned it? Might have been Dirk.

[@christopherjr7189]

@@SavvyNik Redox OS was mentioned by Dirk, in the video. (Timestamp: 6:26).

[@SavvyNik]

You’re the best! Thanks for the timestamp

[@AndrewMorris-wz1vq]

Does anyone use it yet or is it still at the novelty stage?

[@anonymousalexander6005]

@@AndrewMorris-wz1vqIt’s being used by some, but not as a replacement for Linux, and it’s definitely still in research-development/proof-of-concept levels of production readiness (although that would be true for any OS less than a decade old as far as some people are concerned).