Linus Torvalds: Speaks on the Rust vs C Linux Divide

Linus Torvalds Speaks on the the divide between Rust and C Linux developers an the future Linux. Will things like fragmentation among the open source community hurt the Linux Kernel? We'll listen to the Creator of Linux.
My Linux Cheat Sheet and 25 Page Checklist here:
📚 learn.savvynik...
Share this free tool and support Small KZbinrs
editbulk.com
(I made this tool to help creators)
Useful Links/Commands:
Discord Link - / discord
Summit - • Keynote: Linus Torvald...
#opensource #linus #linux

[@SavvyNik]

Do you think there's a Rust and C Linux divide?

[@rursus8354]

No. I think the Rust affiniados are too impatient. When Rust is mature, it will be established. Personally I don't like Rust, for me it is like Java: when will young men listen to the 80-90 year's of experience from programming paradigms? It breaks the imperative and the functional paradigms violently. But something with it must be right, because developers like it. In future there will be tools that help programmers bypass the weird scope-disrespecting design that at least in theory will make it hard to read and maintain others' code.

[@mmstick]

@@rursus8354 Rust was developed by a large team of PhDs using research papers that were written 2-6 decades ago. The motto early on was that Rust is technology from the past coming to save the future. They're neither young, nor did they ignore research in PL theory from the last 80 years. Please do some research.

[@skuwamy]

Yes, because it seems that the culture in Linux Kernel Development doesnt want to adopt new things. Even if you introduce Zig to them Im pretty sure they will just tell that its just another C-like language.

[@mmstick]

@@skuwamy The people who write drivers largely do want to use Rust. It's just a handful of maintainers who are resistant. Zig is not relevant because it's not memory safe.

[@SmplySilver]

It's entirely C devs who don't want to learn new things, plus maybe a couple of them have egos about being too good for the compiler keeping them from doing stupid things. everyone complaining about rust devs proselytizing saw a few people on reddit back in 2018 that programmed in rust for a few hours and thought it was the second coming. those people aren't kernel devs.

[@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

[@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 !

[@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.

[@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.

[@RenamedChannel]

@@mrpocock We already did checked exceptions in Java in the 90s and in the end everybody hated them. Rust cannot handle bump allocators with rollback mechanics and read-write locks with linear scaling (ones that rely on atomic addition in hardware instead of cmpxchg).

[@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

[@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.

[@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

[@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

[@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.

[@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.

[@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.

[@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.

[@waynzignordics]

The problem with Rust is the ideological bent of its die-hard users. I've seen how ideological activists can destroy a company, and the Rust community is showing all the signs of being that.

[@raspy_on_osu]

True bliss is understanding every language sucks for its' own reasons, and just using which one you like most. No need to be so fussy about preferences.

[@Leonhart_93]

That is exactly what everyone currently does, and what the Rust guys don't understand when they try to worm their way in constantly. It won't work, people won't magically be convinced to switch to Rust. The value proposition is just not there.

[@defeqel6537]

@@Leonhart_93 they should demonstrate the value proposition by out-competing instead of infecting

[@Leonhart_93]

@@defeqel6537 There is also no value proposition. They will come preaching "safety" in return for a much more convoluted process, to which the C developers will hear "are you downplaying my ability?". That's why it will only ever work with very specific programmers.

[@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.

[@yewo.m]

That was quite diplomatic

[@dmitripogosian5084]

He has 30 years of experience of managing people

[@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!!!!

[@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

[@smallbluemachine]

No one wants to upset Rust developers.

[@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++.

[@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.

[@te-wei]

The solution is very simple (but not easy), Rust dev need to build their own fork of kernel.

[@RustIsWinning]

I just made a fork. Now what?

[@stefanalecu9532]

​@@RustIsWinning show us how Rust is winning. I'm sure you guys can figure it out from here.

[@commander3494]

That seems like an entirely different project, not a solution to anything here...?

[@nullid1492]

I'm choosing the kernel for my new device. Do I a) choose linux (stable, robust, popular) or b) use a random person's rewrite in rust (an untested hobby project). Clearly I'm just going to install linux. This new fork doesn't stand a chance at widespread adoption. This is why many people dedicate their time to improving the existing option.

[@Leonhart_93]

You are missing their objective here. They don't want their separate project, they won't be happy until they completely take over the existing one to prove how "superior" Rust is.

[@eliasepg]

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

[@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.

[@bnolsen]

I hope zig matures fast enough to displace rust. Linus didn't like c++ and rust also suffers from hidden allocations. And zig is designed to work with c.

[@r2com641]

I won’t jump on zig until JetBrains does tooling for it

[@ITSecNEO]

🤡🤡 Zig is not even close to 1.0 and still people believe it's worth investing time in Zig xD Rust reached 1.0 in 2015 and the language is still not mature enough for some people and areas. If Zig gets 1.0, you can add another 15 years until everything is mature enough for adoption in a Kernel

[@BosonCollider]

Rust and Zig are very different and complementary. Imho though, if a project grows past a certain size, Rust is just a lot nicer when it comes to enforcing structure on a large project and enforcing that APIs are called correctly. Zig is great for smaller projects where everyone involved knows each other and problems are technical rather than social.

[@LabiaLicker]

wtf is a "zig"?

[@smoked-old-fashioned-hh7lo]

no shot, it's not even 1.0 and the ecosystem is tiny. it's going to take at least 8-10 years to reach a point where it's viable. that's how long it took rust and rust has support from aws, google, microsoft, etc. timing is more important than anything when it comes to these things

[@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.

[@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).

[@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.

[@jwr6796]

Rust is like C with training wheels that don't let you move unless you're a pro unicyclist, and I love it so much.

[@dmitripogosian5084]

You will never become pro unicyclist if you do not ditch the training wheels, and earlier is better. So I hope for rust your analogy does not stand

[@Traumatree]

Is Rust a good language? Yes since it is a C copycat Do we really need to replace C with Rust in code that has been debugged and streamlined and optimized since the last 25 years? *NO* Hats off to Rust and what it can do for "future" developments, but can we stop re-inventing the wheel each time a new language gets traction please? We all "ucked up web development pretty bad (and everything that required scripting) when we ditched Perl for PHP/JavaScript/Python/etc., and suffered performance issues, code quality issues, compatibility issues, etc, just because the "new coders" weren't as tight as the ones coding in Perl back then.

[@RustIsWinning]

Found the boomer who still uses Perl 😂

[@johndoe2-ns6tf]

@@RustIsWinning found the vegan high priestess of the woke church of rust.

[@RustIsWinning]

@@johndoe2-ns6tf Uhm but I'm not a vegan lol --> 🦀

[@ssokolow]

Rust isn't a C copycat. It's not even descended from C. Its lineage is ISWIM (1966) → ML (1973) → Standard ML (1983) & Caml (1985) → OCaml (1996) → Rust (2015) with a liberal coat of C++ paint to make it more appealing to mainstream developers. (That's where syntax like `fn`, `match`, `Option`, `Some`, `None`, `→`, and `'a` come from. They're straight out of OCaml. Hell, the Rust compiler was written in OCaml before it became self-hosting.)

[@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…

[@vaisakhkm783]

​@@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? ;)

[@turtlefrog369]

mixing languages is very bad mmmkay.

[@username7763]

Tell us web developers that. We use HTML, JS, TS, CSS, JSX, SVG plus a bunch of other languages on the backend like PHP, Java, C#, Go, all in the same product. Yeah it gets a bit crazy, but you'd think a project could handle 2 languages at least.

[@Leonhart_93]

@@username7763 That's all smoke and mirrors. The browser still only understands pure JS and the skeleton is the same HTML. It doesn't care what the backend is as long as it sends the right response.

[@muhdiversity7409]

@@username7763 web anything is garbage. If a kernel was written to behave like the average webapp the kernel would be unusable.

[@RustIsWinning]

ok Mr. Mackey

[@defeqel6537]

@@username7763 ahh yes, the world that turns a few kilobytes of data/code into gigabytes of nonsense

[@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.

[@MrInsanityplea]

The rust people should just write their own kernel, linux is bloated like hell as it is.

[@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.

[@imaquackaholic]

If the wider Linux/developer community could just learn to not treat their tools as religions to be worshiped, the rate at which stuff would actually get done would be exponential.

[@letmeregisterbitch]

People who dont treat their work as religion does not work on opensource projects for years

[@defeqel6537]

Much of it is dependent on friction; the harder/bigger the change, the more opposition it faces

[@bytefu]

Damn humans.

[@chuckcrizer]

Rust is about fixing bad programmers and bad software design processes. You CAN write memory safe software in C but you need competent programmers and smart development. Rust will be a security nightmare when the LLVM is bugged or hacked.

[@mmstick]

Unfortunately, there's ample evidence to prove that competent programmers and smart development is not sufficient to write memory safe software in C. See Google's security blog article titled "Memory safe languages in Android 13". Google has some of the best programmers in the field, and they've written a lot of static and runtime analysis tools specifically for detecting memory safety issues in C/C++. Despite that, the evidence is damning. 80% of known-exploited security vulnerabilities were directly caused by memory unsafety in C++. Their best runtime analysis tools barely had any effect. They were only able to reduce the vulnerability rate by writing more code in Rust than C++.

[@TheOnlyJura]

That's why each release has thousands of tests.

[@mmstick]

There is no C programmer alive that can write memory safe software in C. There's an insurmountable amount of evidence to prove otherwise. See Google's security developer report titled "Memory safe languages in Android 13".

[@ssokolow]

I don't follow your point. Linux depended on GCC's extended dialect of C for most of its life, with LLVM Clang support only arriving when LLVM gained support for the relevant parts of GNU C. What's the difference? Also, there are TWO projects in progress to bring Rust to GCC. (One which lets the existing rustc compiler frontend use GCC as a backend instead of LLVM via the AOT compilation support in libgccjit and one which is writing a whole new Rust compiler in C++ so it can be upstreamed into GCC.) ...plus, LLVM already isn't the only compiler backend for rustc. There's also the Cranelift backend which, while it doesn't have all the SIMD support implemented yet, aims to become the default for debug builds for a more Go-esque "lazier optimization in the name of faster iteration" workflow.

[@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?

[@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.

[@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.

[@nahuelcutrera]

sometimes I think we forget this tools are there to make our life easier, which one does that ?? that's the question in my eyes. It's the same problem with linux in general, it's making life easier for a limited amount of technically inclined people, but it makes life harder for the vast majority of not technically inclined people, and that's why never becomes the predominant OS that was meant to be. Simplify should be the main thing instead we overcomplicate by diversifying everything.

[@lolilollolilol7773]

Dude, you know your phone runs on Linux, right ? Just for that, it is the predominant OS.

[@nahuelcutrera]

@@lolilollolilol7773 I know, but you know what I mean also...

[@mmstick]

With Rust, programmers don't have to worry about documentation so much due to self-documenting types, state machines, and function declarations. Security auditors also know to go straight for lines of code which are inside of unsafe keyword scopes, reducing the burden and costs of security audits. It makes life easier for C programmers, too. Bindings can expose hidden flaws in the code it binds to.

[@_TheDudeAbides_]

You may think so but you are wrong. Linux does not make people's liver harder at all. The people who don't want to fiddle with linux will just not do it. Instead it helps the internet infrastructure and other things which makes life easier for you users. Rust can be difficult but that does not matter to you who are a software user. If computer programs crash less and systems get hacked less because they are made in Rust, thta makes life easier for everyone except perhaps the programmer.

[@derfiemcgoo9673]

A friend of mine wrote a operating system for the bbc-a microsystem in javascript.

[@_TheDudeAbides_]

Your imaginary friend. That does not count.

[@OriginalJetForMe]

“I don’t want to add error handling because it’s a bug if it happens.” No wonder shit is vulnerable to attack.

[@DreadHalfling9]

"In your iphone" funny to assume theres ppl in that audience using iphones

[@segment932]

On writing a own operating system I have my own experience from a class in embedded systems and I thought what if I did that thing and provided that thing... I totally burned my self so hard that I could not walk properly for a week or two. Then I realized that I have bean writing my own operating system. So DON'T DO IT.

[@rumplstiltztinkerstein]

I like how one of the devs said that "Rust is a religion" as if C languages are nothing near it.

[@sprytnychomik]

So, what do you expect if you bring your own religion to a group of people devoted to another religion? Peace? Coexistence? Like if Rust Witnesses eager to replace C are welcome in C community.

[@rumplstiltztinkerstein]

@@sprytnychomik indeed. I'm a heretic.

[@NinjaRunningWild]

They all are. But Rust advocates are coming from an activist era which doesn't help.

[@rumplstiltztinkerstein]

@@NinjaRunningWild Yeah. When I hear the old "70% of bugs are memory bugs" I just want to scream.

[@mmstick]

@@rumplstiltztinkerstein Go read "Memory Safe Languages in Android 13". Say the first sentence out loud.

[@nyx211]

Rust is a language that exposes how shitty you are at developing because it forces you understand what you're doing and get it right the first time. Otherwise, the code won't even compile. If you don't know what pointers are, can't explain covariance vs contravariance vs invariance, or if you insist on using doubly-linked lists in a memory-safe language, you're gonna have a rough time.

[@LubosMudrak]

You can still do unwrap() and clone() but everyone will very well see, what you did 😀

[@bytefu]

@@LubosMudrak Because sometimes you have to unwrap() and clone(). We already have a purist language where you cannot do these "bad" things - Haskell. I wonder why many people seem to love it, but hilariously few actually use it.

[@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.

[@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

[@johnnysmith4714]

Linux now has it's own version of the BSoD in anticipation for Rust's out of memory panics. The future is now.

[@mek101whatif7]

Because right now the BSOD for pure C was a frozen screen...

[@ssokolow]

OOM panics are a feature of the Rust standard library, not the Rust language. (and one chosen because Linux's default overcommit behaviour is to lie that malloc succeeded and then kill you later) You don't use C's libc in kernel-mode code because it assumes it runs in user mode and can delegate work to a kernel, and you don't use Rust's `std` for the same reason. (However, Rust actually splits its standard library for exactly this sort of reason and `core` IS usable in kernel or bare-metal contexts.)

[@m4rt_]

I think having extra measures for ensuring memory safety in the kernel drivers is a really good thing, and rust is helping provide that. And by doing that we can try to avoid issues like the crowdstrike issue where a faulty driver took down a lot of the Windows machines in the world.

[@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.

[@GuzikPL4]

Recently i saw a quote: Rust will do the same thing to C that Linux did to Unix. I dont have opinion on that, just think it's interesting.

[@_TheDudeAbides_]

It is possible, but a oneliner sounding cool is not more true than a regular paragraph.

[@jeffspaulding9834]

Meh, if it happens it won't be for a long, long while. C and UNIX grew up together. The only way for Linux to get completely away from C is to abandon POSIX. I know there's some people out there that wouldn't mind that, but there's a whole lot of us that would put up a fight.

[@hopperstreams4487]

Good lord didn't realize Torvalds was finally showing his age

[@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.

[@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.

[@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.

[@orlovskyconsultinggbr2849]

Rust community is toxic, recently they even tried to swat one of the Linux developers.

[@RustIsWinning]

Who? Cares. Is this yours? --> ♿️

[@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.

[@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.

[@GureiFokkusu84]

Cant have the whole pie without the CRust 😉

[@h4ndle_yt]

When I think of Rust community I always remember that scene from Succession's last season where Logan has that conversation with his children and he says to them: "I love you all, but you are not serious people.."

[@RustIsWinning]

Sounds like a TV series for boomers 😂

[@yoiyoikokon]

That bottle with cap holder triggers me.

[@fungjungkung]

I just wish fanatic Rust developers would stop setting google alerts and building bots to respond to any and all criticism of their language on the internet. I can criticize C, C++, Java, etc. all day long, and a lot of the developers in those languages will actually agree with me, but I can't criticize Rust without dealing with tons of trolls and bots. I predict that once the rust community grows up and starts acting like adults, a lot of the hatred of rust will die down

[@RustIsWinning]

My bot just detected this as a 🤡comment rofl lmao 😂

[@ITSecNEO]

That people like this bs comment is the real troll here 😂 There are idiots in every language community, especially in the C and C++ area. Your point is literally just nonsense and hating on Rust for no reason

[@bytefu]

So far the only Rust-related post of yours I've seen is this, and it's about how you cannot criticize Rust. There is your opportunity, go constructively criticize it, and we'll see how it goes.

[@johndoe2-ns6tf]

@@bytefu thank you all, vegans of the woke church of rust for proving the OP point.

[@complexity5545]

Just wrap all the Rust code with "unsafe."

[@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 😂

[@ryman1]

Is Linus morphing in to Saul Goodman?

[@PixelOutlaw]

Rust is still too young and is changing too fast while lacking a spec. It's totally possible they could pull a Python 3 compatibility wise. The amount of 'unsafe' they have to do shows that the inherent nature of Rust diverges from how C is used. I'm not saying C is a great language either - but you need to pick something closer to that. Maybe it has better expressiveness, Rust has some expressiveness but it's undone by its own memory model in some cases. There's quite a few languages that could probably be used on the kernel but everybody's fixated in ones with little mascots because they only know about 10 years of programming history.

[@anonymousalexander6005]

C is an ABI, Rust is not. Rust can use the C ABI. unsafe is a marker and fence, it significantly improves (memory-related) debugging by an order of magnitude. The memory model and type system is strict and well-defined, something more important than ABI specification for many, and admittedly inconvenient for those who wish for prompt iteration While full HO expressions and effects can improve expressibility, I for one am grateful it’s not as bad as Odin or Go 😂

[@jackthatmonkey8994]

I dont think I understand your argument about 'unsafe' The way I understand 'unsafe' is that the whole 'mut' thing really just makes finding bugs and fixing them easier. I find the word 'unsafe' to be a weird choice by the Rust Foundation, it sounds like you're being irresponsible by just allowing a variable to be changed.

[@oserodal2702]

@@jackthatmonkey8994 The Rust Foundation has never directly controlled the Rust Project, they just exist alongside the project to complement. Matter of fact, there have been documented cases where the project and the foundation butted heads with each other.

[@username7763]

It also troubles me to standardize on using a language that isn't, itself, standardized. While many languages get by with the whole, our language is whatever our compiler / interpreter accepts approach, the moving target and lack of multiple vendors is a large risk. I've moved codebases between compilers in C++ and that's hard in a standardized language. I couldn't imagine doing that with something that isn't standardized.

[@experimentalcyborg]

Honestly i'm rooting for a python 3 esque major version break once they've figured out the last kinks. A couple of things are overly complex and unintuitive, when those are ironed out and integrated in a proper spec, Rust can run with the big boys.

[@seth8141]

I'll be ending my first year with Rust and I have to say, I like it.

[@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.

[@prosiescoteau2152]

Oh hey, it's a clip I've already seen but with some guy who isn't Linus Torvalds talking too. Why would I want to watch this?

[@StephanusTavilrond]

I don't have any problems with Rust as a programming language.... My main problem with Rust is the programmers who use it: hardcore progressive types who have zero tolerance for alternative political views. The hardcore LGBTQP+, BLM, etc. types, who are offended at the very idea of keeping programming apolitical. The Rust Foundation is entirely made up of such people. This is precisely why I'm not touching Rust, not even with a ten-foot pole, and will oppose its inclusion into anything.

[@RustIsWinning]

Imagine caring what a foundation does lmao 😂

[@Doctom91]

Spot on.

[@StephanusTavilrond]

@@RustIsWinning It's not just the foundation, but also a significant portion (if not the majority) of Rust-users.

[@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.

[@santitabnavascues8673]

I think is simpler to fix a memory leak in C than making Rust to be as performant. Also, C, Unix and Linux are really two sides of a single coin, so, if any, i think it is simpler to create a kernel for Rust, just not a Linux kernel so you don't have to fight "C"

[@TheOnlyJura]

Is it simpler to fix a memory leak, if it has already been abused by someone? You can't fix what has already been abused.

[@santitabnavascues8673]

@@TheOnlyJura it becomes a feature, but that's why it is beyond the point. It would be asking Rust to do something it hasn't been designed to do.

[@TheOnlyJura]

@@santitabnavascues8673 So abusing a memory bug that allows the attacker to transfer money from your bank account becomes a feature? Thats a great feature to have for sure

[@santitabnavascues8673]

@@TheOnlyJura still besides the point.

[@savagepro9060]

Linus is correct. Rust is for a new operating system . . . perhaps WD-40 OS?

[@NinjaRunningWild]

Rust is just kicking the can down the road. You're just trading current problems for problems down the way.. No one reads "The Mythical Man Month".

[@RustIsWinning]

Found another boomer 🤣

[@_iao_]

@@RustIsWinning Nice argument.

[@RustIsWinning]

​@@_iao_I win even without arguments.

[@_iao_]

@@RustIsWinning kek if you're trying to make Rust and its community look bad, you're doing a great job!

[@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.

[@maaifoediedelarey4335]

So, go build a Rust based kernel to be tested in parallel, until it's proven to be less than, on par with, or superior to the C based kernel systems. That's always the preferable path, rather than infuse a fully functioning entity with new experimental promising tech changes. Over time, the superior tech will win out, and the lesser will be left with no clothes.

[@Sierra410]

Rust is just a tool that expands on old ideas to, essentially, automate a lot of manual work and sanity checking. Saying that they should re-write everything from scratch just because they're introducing a new tool; just because it's something new, is like saying that you should build a new house, if you want to start using a vacuum cleaner instead of a broom. It's there's to be used when you want or need it, not to replace everything "just because".

[@maaifoediedelarey4335]

@@Sierra410 Point taken. Then just use it and run the changes made by it in a parallel test version, before incorporating it permanently. New ideas are good, but must be tested first.

[@Sierra410]

@@maaifoediedelarey4335 that's not too far from how linux actually works. Pretty much every part of the Kernel is developed in parallel by its respective developer team and all the efforts are only occasionally combined together. With the way Linux works, you're always able to just... not include some parts in your builds. They how they get tiny builds of Linux for things like routers and IoT devices: they simply don't include the parts they don't need.

[@fedfer]

It has been repeated multiple times in the video that the Linux kernel is over three decades old, I hope you realize building a kernel of such complexity from scratch is not a feasible task.

[@isodoubIet]

@@Sierra410 In principle that could work but in practice the incremental approach just isn't working and it's very unlikely to start working.

[@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++

[@krunkle5136]

A complex language gets in the way of system design. What is needed is more people to use debuggers and follow best practices with the handful of dangerous things you can do with c code.

[@freedomgoddess]

this is the one take i've had in my head. if there was a right take, this is it.

[@fedfer]

Sometimes ( a lot of times ) the best practices are just not enough to prevent bugs. Also, a "complex" language does not get in the way of system design, if used correctly it can help a lot imo, what does get in the way of system design is people making uninformed choices purely out of spite, fear.

[@username7763]

I've found complex languages allowed for writing code in such a way that it is easier to verify. Sometimes this means automated tests but the best code is something you can look at and clearly see that it is correct and all scenarios are properly handled. C is too simplistic of a language to allow that other than at a very microscopic level. Of course there is the problem of people writing unnecessarily complex code in a complex language which is sadly more common.

[@Leonhart_93]

Rust is just complexity for complexity's sake. Rotten design philosophy. I don't need the clutter and hardcore compilers.

[@experimentalcyborg]

The philosophy behind Rust is to make incorrect designs fail compilation. That definitely makes system design harder, because you can't get away with things that "work as long as you're careful with it". Unfortunately at this stage it also fails on a few rare technically correct structures unless you manually annotate lifetimes for them, but it's actively being worked on (better compile-time lifetime inference is on the road map for the next major release)

[@gamertechkid1490]

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

[@AndrewKelley]

thank you for the editing

[@satrac75]

I wonder if Linus has looked at Zig? I think it's a good option.

[@pierreollivier1]

I think it's too soon, I love Zig it's by favorite language, but the language is still young and although I'm a firm believer it's the best language for a kernel, (I'm in the process of writing a Unix kernel in Zig for my master degree). I can also see why it's not ready yet. The language is not stable enough, and it needs some polish to be linux kernel grade. But I think it's worth waiting for. The reason the language breaks so often is that the maintainers explicitly said they don't care about breaking code, and that they would gladly break backward compatibility if this simplifies the language, or aligns it better to it's core philosophy. I think this is the reason why in the end it's going to be a better language for kernel development than Rust. Rust is an amazing language but it's designed by committee, which means it's bound to become yet another C++ level of mess.

[@Mariuspersem]

@@pierreollivier1 agreed, it will probably be a long while until we see a 1.0 release. I have really enjoyed the comptime elements of the language, especially for game development, easily embedding textures and models into the binary, precompiling all sorts of stuff is amazing.

[@mmstick]

Zig is not memory safe, so it will never be suitable. The purpose of Rust is to achieve memory safety in the kernel.

[@JonitoFischer]

​@@mmstickunsafe rust is not memory safe, probably you will never get memory safety in the whole kernel.

[@anonymousalexander6005]

⁠@@JonitoFischerunsafe Rust is an order of magnitude more memory safe than C (even with static analysis), it’s equivalent (in regards to safety) to C with dynamic analysis tools and strict coding standards. The _unsafety_ (pun intended) comes when you haphazardly shoehorn safe abstractions onto unsafe implementations without proper consideration for the extra guarantees you make by doing so.

[@parlor3115]

Yeah man, ever since this Rust thing came to light, Linus split into two even pieces (he has a genetic condition where his heart is dead center).

[@kintustis]

the fact that rust fans are so cult-ish about it kinda proves that there's nothing really behind the tech. if it was truly better, you wouldn't need a bunch of missionaries saying so. It's just another language in a sea of languages.

[@DaBoomDude]

Bro. Wat? I agree rust isn't perfect, but I think it has its place. But the argument you used is the same argument people use to justify "Windows or Mac good, Linux bad" It's stupid, unreasonable and makes no damn sense. It's essentially saying "anything marketed is bad" - because marketing is essentially that, it's telling people about the product and its benefits in hopes of spreading it. How many good products are you using because it was marketed to you at some point during or before your lifetime? Let me tell you It's definitely not zero. If it wasn't good for at least some applications, people wouldn't use it. I'm not saying it's good for everything, I'm not saying it doesn't have its flaws and learning curves. It totally does. But that does not make it bad. It doesn't make it good either. Like you said in your last sentence It IS just another language with a unique set of benefits and flaws. It's up to the developers of a project to work out those flaws and benefits and weigh the pros and cons, and put out clear and succinct arguments for why you should or shouldn't use rust in the project and not just spew stupid blind ideals like you just did as if everything new and different is bad.

[@kintustis]

@@DaBoomDude 🛀so you agree? cool thankx.

[@RustIsWinning]

Not a cult 🦀

[@MarcCastellsBallesta]

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

[@jstormclouds]

rust came first, but zig is arguably better designed + in terms of simplicity. . C kernel coders, may find it easier to transition to zig since it is based on C, if safety is something they want to pursue in a new lang

[@RustIsWinning]

It's not even close lmao

[@jstormclouds]

rust may win the popularity war for a good number of cycles, but will they win the battle for humility and being humble. . . Pride has a funny way of making things more complex than they need to be. Gatekeepers like to make things complex to maintain their elevated status. History & long term horizon. . . Of course i am happy for the elevated status of the rust church and their OS products. Zig and Mojo have learned some lessons thanx to rust, including how to make things more simple & safe imho

[@jheregreign]

Yeah, Rust has had a bit too much momentum behind it. Really excited about Zig personally. Though I'm mostly interested in embedded'ish level things.

[@RustIsWinning]

@@jstormclouds Zig is not memory safe and MoJoeMama is not even open source LOL

[@jstormclouds]

@@RustIsWinning I'll mojo your mama's rusty open source w my zig any day

[@H33t3Speaks]

C wins. We’ll be coding warp drives with it. It’s just that robust and powerful.

[@_-martin-_]

Git was created by Torvalds because the kernel needed a better open source version control system. We need a similar undertaking but to create a modern programming language that fits the future needs of the Linux kernel. I do not believe Rust is that language - we can do better.

[@lolilollolilol7773]

Zig is pretty good. It's a (much) better C.

[@defalur]

​@@lolilollolilol7773 seeing what people are capable of writing in C and C++, I am very scared of what horrors await when Zig becomes more mainstream and people start abusing comptime. It is a nice feature, and solves issues very elegantly, and the language itself is pretty good (I especially like the error handling), but I am not convinced that it is really that much better than C in all aspects.

[@guest7329]

what you didn't like about it?

[@defeqel6537]

Not sure we can do better than Rust, but we can probably do a more incremental, more easily adapted, language. Whether it will offer enough benefits for inclusion in the kernel will then be the next contention. Hylo also seems interesting in this regard.

[@bytefu]

Rust is certainly not perfect. But if you think we can do better than that, I am afraid that you have to assemble a team of the best language designers and compiler experts in the world, then wait for at least 5 years before they produce anything even remotely useful. Maybe in 10 years, they can produce something very useful, and in 15 a better language than Rust that is better suited for Linux development. I believe my estimates are quite generous, considering how good Rust is and how hard it was to implement it.

[@gsestream]

so why split any project between two languages

[@paleopteryx]

I think this obsession about using Rust in the linux kernel is weird and suspicious to say the least. Rust fans could go play with their stupid language everywhere else, but no, they insist on using it in the linux kernel. So far there's no major piece of software written in that language yet some dubious individuals aggressively insist in pushing it into the kernel. I bet this is secretly financed by bad actors, like micro$oft, in order to sabotage Linux.

[@Marshall1914]

Not to mention that even the US government has endorsed Rust and that made me even more suspicious of the whole thing.

[@Edge10]

Probably compromised runtime in some manner. You can see the influencers (bad actors) trying to shoehorn it into literally every project. The whole `memory safety` is jut a meme at this point, especially when it's easy to check array bounds, check whether a pointer is null, or create memory arenas to avoid polluting the program with malloc/free's. I'm sure there are syntactical niceties in rust but nobody ever mentions these, it's always, always solutions to `memory` problems that I don't have.

[@RustIsWinning]

​@@Edge10Hilarious claims LOL 😂

[@RustIsWinning]

True. This is why M$ is also going all in with Rust to sabotage their own OS rofl lmao 😂

[@TotallyURGrandpa]

Lmfao the conspiracy theorists are already here 😂

[@rsgilbert6152]

That last part was really good and inspiring

[@UltimatePerfection]

You wouldn't drink from rusty pipes. You wouldn't drive a rusty car over a rusty bridge. So why would you want rust at the very heart of your operating system?

[@Sierra410]

"You wouldn't drink C water. You would drive your car into the C. Why would you want C at the very heart of your operating system?" What fucking kind of an argument is _that?_

[@TheErtagon15]

@@Sierra410 it's almost like it's a joke you spaz

[@insiderich7372]

​@@Sierra410To C in life is a gift from divinity, and watching the same corrode away due to Rust is a trait of life 😂😂😂

[@RustIsWinning]

Another boomer who cannot accept that Rust is better haha

[@UltimatePerfection]

@@RustIsWinning Of course it's not. Free Pascal is what is really the best.

[@greycell2442]

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.

[@jim0_o]

I want to see this anger build, but only to the point where 2 more Kernel Open source projects are started one in pure Rust and one in Pure C, just language warriors anger-coding up a Kernel for their side to "prove a point"... [insert laugh of madness]

[@stefanalecu9532]

So... Redox and... um... any BSD kernel?

[@jim0_o]

@@stefanalecu9532 Were they made in anger by hubris?

[@RustIsWinning]

I'm an angry crab. Is that going to help me build a kernel?

[@jim0_o]

@@RustIsWinning You'll need to open a undefined editor and start typing and we'll see.

[@ssokolow]

You're more likely to just see a downstream fork crop up like Android was doing for years and years and then any distros that want to support the hardware with Rust drivers going for it instead of upstream.

[@AndrewRoberts11]

Failed to answer the big one, why after three decades does Linus prohibit drivers being added in the Emacs flavour of LISP?

[@bytefu]

More serious answer: because it is much easier to write Lisp code than to read it, let alone understand (e.g. what's that - macro or function; have to read the source). Also, dynamic typing sucks. Less serious answer: because nobody uses Emacs and knows what Lisp even is.

[@AndrewRoberts11]

@@bytefu I'm fairly sure a Richard Stallman might know a thing or two, let alone a well know Linus, who had little choice other than use Stallman's LISP based Emacs editor, with macro sets defined to bind keys to periodically invoke Stallman's make, to call Stallman's gcc, and Stallman's gdb, to build, run, and debug the code he was dependent on a few Stallman flavoured Lisp Macro's to format, color, if not highlight the location of the odd seg fault, or step through, and obviously check in on save.

[@jeffspaulding9834]

There's already an operating system written in elisp - it's called Emacs :) Seriously though, you can write kernels in Common Lisp. There's a project called mezzano that implements an OS and some basic applications in Common Lisp. Unfortunately I think the creator's abandoned it, but maybe someone will pick it up.

[@DeeaA.-qu2bn]

In the coming years Rust will prove to be the cancer that kills Linux. It needs to happen anyway and we need to move on to a new OS

[@gregandark8571]

Haiku OS

[@KoopstaKlicca]

​@@gregandark8571HaikuOS is not designed to replace Linux lol

[@gregandark8571]

@@KoopstaKlicca Haiku OS for ever!

[@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.

[@virtualinfinity6280]

This so called "divide" is just completely blown out of proportion by youtubers and the like. Rust - or something alike - is clearly the future, while C will eventually be abandoned. Make no mistake, I spend the last 40+ years writing C code and only "got my feet wet" in Rust over the last few years. But I am convinced, Rust is a significant step up from C and I'd love to see things like Rust in Linux evolve.

[@NinjaRunningWild]

Kool-aid drinking.

[@Leonhart_93]

More like it's something that fails to get adoption in anything even to this day. If it didn't made its way into the Linux kernel somehow, it would barely have anything to do in the enterprise world.

[@The_Real_Grand_Nagus]

I see that no one is fighting FORTRAN in the kernel code base.