Linux Creator Torvalds Says Rust Adoption in Kernel Lags Expectations

[-]

sjepsa@reddit

Who would have guessed that a language that impairs you and makes almost impossible to do any meaningful low level stuff would have slowed the progression down?

[-]

Ok, why do you people always post comments like this and never elaborate. As someone learning rust I am interested, please explain what you are referring to as I'd like to learn something. What isn't possible, how does the language impairs you, what low level stuff is impossible etc?

[-]

sjepsa@reddit

OMG you tried to modify an object that you passed to another function by reference... YOU. MONSTER.

Read the official take on Concurrency from Rust:

https://doc.rust-lang.org/1.8.0/book/concurrency.html

It's hilarious

You can't do something simple like this:

std::vector<int> vec {1, 2, 3};
for(int i = 0; i < vec.size(); ++i) {
    std::jthread t([&vec, i] { vec[i] += 1; })
}

And say that it is a feature of the language.

Complicating simple stuff, because of 'safety'. It's like walking down the street with two blocks of concrete around your legs, to not fall

[-]

uss_wstar@reddit

You can't do something simple like this:

Yes you can, who told you that?

let mut nums = vec![1, 2, 3];
thread::scope(|s| {
    for i in nums.chunks_mut(1) {
        s.spawn(|| i[0] = i[0] + 1);
    }
});

[-]

OMG you were for real.... Just read this now.

The scope doesn't end... it's just a snippet. I can put a sleep after or do other code or it could be in main or whatever... if i wanted RAII i would just have used jthread...

The official Rust documentation https://doc.rust-lang.org/1.8.0/book/concurrency.html 'solution' lol:

fn main() {
    let data = Arc::new(Mutex::new(vec![1, 2, 3]));

    for i in 0..3 {
        let data = data.clone();
        thread::spawn(move || {
            let mut data = data.lock().unwrap();
            data[i] += 1;
        });
    }

    thread::sleep(Duration::from_millis(50));
}

Talk about overcomplicating simple stuff

[-]

eugay@reddit

Clown

[-]

KrisstopherP@reddit

Trash code, skill issue.

[-]

sjepsa@reddit

Implement a double linked list

[-]

Ok-Entertainer-8612@reddit

Honestly, not even joking, you never need to use a double linked list. You can write every piece of software without this data structure. No one needs it. And its performance is worse than the alternatives.

Anyway, you can implement it nonetheless, even in Rust.

[-]

warmwaffles@reddit

I don't think the double linked list is necessarily a heavily used data-structure. But a graph structure is and a double linked list is a hyper focused directed graph. So I think the challenge should be to "Implement a directed graph with BF search and DF search."

[-]

sjepsa@reddit

You can implement everything without Rust too

There's a way to improve C++: improve C++

You can't undo bad decisions in the language, only monkeypatch and advise against using broken things.

Rust isn't just another basic language with a slightly different syntax to C, it actually brings new things to the table that C++ literally cannot without breaking changes or splitting the ecosystem completely. It brings real, tangible new concepts that enforce strict standards and improves overall code quality and safety.

It's slower

Citation needed. I'd argue that given the time to implement more optimizations in LLVM catered towards noalias, it could genuinely end up being faster in many benchmarks. In real world programs it's generally on par with C or C++.

doesn't have libraries

I've never been left wanting when searching for libraries to use

You're free to like and prefer C++. Go nuts, that's your prerogative, and I won't try to change your mind on that. My only point is that you're bashing another language you've never used for no other reason than that a group of people believe it's superior to C++.

I personally don't see the hype for Zig, but I'm not going to diss the language and push people to use Rust instead.

[-]

sjepsa@reddit

Citation needed for speed?

What about, mandatory mutexes and locks everywhere?

Bound checks for EVERY array dereference in the kernel....

[-]

stumblinbear@reddit

Mandatory mutexes? The things you also need in multithreaded C and C++?

Bounds checks which you can get rid of by guaranteeing to the compiler that it can never go out of bounds? The bounds checks that prevent the security vulnerabilities that exist in pretty much every C/++ program in existence at one point or another?

In many benchmarks and actual real world usage, it is on par with C and C++, if not faster in multithreaded workloads due to developers being less defensive when programming leading to fewer locks and slower code overall.

[-]

sjepsa@reddit

There are mutexes in C++, of course. There is everything in C++. BUT you are not forced to use them. C++ gives you power

I could write, or someone more smart than me could, a lock free multithreaded data structure (and they did) in C++

We were talking speed and you asked for example. Bound checks in every call are slower. Period

[-]

coderstephen@reddit

C++ gives you power

The power to have data races in your software? I'm OK to pass on that power, thanks.

[-]

sjepsa@reddit

Power to implement a double linked list

[-]

sqlphilosopher@reddit

I don't know why the downvotes tho... anyhow meaningful low level requires unsafe because hardware is inherently unsafe. Yes, you can make a wrapper around the unsafe code, but you can do that in C as well (see, NASA or any other dev work in critical areas). So, it is really pointless, I'm not sure what benefit Linus is seeing here. Not to mention the complications of working with two languages, and the fact that Rust's leadership is full of nut jobs, and that the language doesn't even have a standard.

[-]

SV-97@reddit

I don't know why the downvotes tho... anything meaningful low level requires unsafe Rust because hardware is inherently unsafe

Because that's nonsense. Low level code is not unsafe every step of the way and doesn't prod at hardware in every last line. Even in embedded the fraction of code that actually has to be unsafe is comparatively small.

Yes, you can make a safe wrapper around the unsafe code, but you can do that in C as well (see, NASA or any other dev work in critical areas).

Most people are not NASA. And some of NASA's projects are literally writing Haskell and compiling to C. Is that really what you want to argue for?

[-]

sjepsa@reddit

Most people shouldn't write time critical stuff in the linux kernel

If you do I hope you know what you're doing and don't need somebody to hold your hand

[-]

SV-97@reddit

We're discussion a situation where the prior is that people write stuff in the kernel though

And if you're seriously still using the "the only issue with C is your skill issue"-argument in 2024 there's no point in discussing this at all honestly. We have decades of data showing that this is bs and anyone that ever used C in a critical context can tell you as much.

No you don't. Most of your comment is flat out wrong and you just make it clear over and over again that you don't know the language at all (which is fine but then you shouldn't talk like you do). Rust doesn't "just protect against ownership bugs" and it can give very strong guarantees in concurrent code (always data race freedom, for some things also the absence of deadlocks as well as strong realtime guarantees).

C++ is irrelevant here. C++ in the kernel isn't going to happen.

[-]

TheLivingFlannel@reddit

You don't see how a language which is safe by default, and only requires opting into unsafe constructs when necessary, has no benefit over a language that is unsafe by default and requires a lot of work to opt into safety features?

[-]

sjepsa@reddit

That has a price, in program performance and in expressiveness of code.

"If writing the same kernel code in Rust requires eight times the amount of code, they will stick with C."

And that's EXACTLY what's happening

What you call 'safe', is just avoiding a SMALL set of problems, that you avoid at the price of being coerced in a very rigid programming paradigm

And that just vanishes in multithreaded applications

[-]

sjepsa@reddit

Lol @ safe by default

[-]

ThomasWinwood@reddit

but you can do that in C as well

How do you tell during code review which APIs are safe and which are unsafe in C? In Rust it's easy, the unsafe ones have the word unsafe written next to them.

[-]

sjepsa@reddit

So rust code can't throw infinite exceptions?

Can't deadlock? Can't run out of memory?

They can't crash.

They are safe by definition

[-]

Maykey@reddit

EZ. Just use Coq as seL4 does. it even protects from compiler bugs as verification is done on binary.

Anyone who think rust is complicated will be relieved to write

lemma rf_sr_ksCurThread:
  "(s, s') \<in> rf_sr \<Longrightarrow> ksCurThread_' (globals s')
                   = tcb_ptr_to_ctcb_ptr (ksCurThread s)"
  by (clarsimp simp: rf_sr_def cstate_relation_def Let_def)

Rust the game was released in 2013, and Rust the language didn't have its 1.0 until 2015...

[-]

andrerav@reddit

Can't the devs just rewrite the game in Rust? So sad

u/vondpickle, probably

One quote from the Discord:

Yup! I do it a lot in DLLs at work for example in fields of mistria, all the dialogue keys for all the characters are read in from a giant blob o data, and i just box leak em and i got &'static strs for days it's not like i was going to deallocate them anyway

hello all, i'm cosmo! i used to make gamemaker tutorials and now work as a gamedev on fields of mistria, though i'm currently in talks with ferris to sell my soul to them as more and more rust bleeds into our project

[-]

eenum@reddit

I do think it will make console ports more tricky for them but what do I know

[-]

eenum@reddit

Cool!

[-]

_Unity-@reddit

These examples are specifically made in Bevy. It has to be noted, Bevy just turned 4 yo and is not production ready, yet it's api is now considered mostly stable and according to the lead dev birthday post the official editor plugin and scene file format is expected to be released soon which would be a huge step towards production readiness. In my opinion bevy provides the best game architecture on the market aside the fact that it's free and open source plus the usual range of advantages of rust.

Anyway here are some notable games done in Bevy:

https://store.steampowered.com/app/2198150/Tiny_Glade/ (This one is really impressive, at least judging its trailer)
https://store.steampowered.com/app/2628450/Times_of_Progress/
https://puzzled-squid.itch.io/tunnet

[-]

Mythique@reddit

Tiny Glade isn't made with Bevy, it's a custom engine. They use the ECS system from Bevy though. Information from their FAQ.

❔ What engine did you build it in?

We’re using our own home-made engine written in the Rust language. At some point, we were wondering - are we crazy? Well, yes! But the game uses so much custom technology that we concluded it was actually a pretty sane choice :) We also benefit from a lot of open source software, including Bevy's Entity Component System (ECS).

Typst is such a game changer. It's still early days, do it doesn't yet cover the entire breadth of LaTeX's options. But if you can use it, it's so much better.

[-]

simonask_@reddit

Most of those are hobby projects that people really shouldn't use, but one wildly successful example that comes to mind is ripgrep.

[-]

Delicious_Ease2595@reddit

Lemmy is also written in Rust.

[-]

Turtvaiz@reddit

And some I can think of that I use: hyperfine, eza, bat, oxipng, alacritty, ruff (on web pages), inferno (flamegraph).

Lol, there's nothing for C devs to be sorry about.

For C long-timers, the gulf between C and Rust (and C++ for that matter, despite the syntactic familiarity) may be wider than GC langs to RAII. And there's the borrow checker, traits, pointer wrappers etc that simply don't exist in pure C.

Give motivated long-timers a choice between an old lang they're highly familiar and productive with, vs something completely new that puts hurdles with the old ways... I think the result is entirely predictable

[-]

SV-97@reddit

And there's the borrow checker, traits, pointer wrappers etc that simply don't exist in pure C.

[-]

Lex098@reddit

Maybe I didn't understand your problem, but you can do it in at least 2 ways: in stable rust and more ergonomic, but unstable version.

There is work to be done to make Rust better, but your example has already been solved.

[-]

camilo16@reddit

This is just an example. The point is not that this specific problem cannot be solved. It's to show how the conservative nature of the borrow checker leads to situations where the programmer is certain everything is fine, but the BC can't prove it.

This forces the programmer to become sidetracked in making the BC happy rather than focusing on whatever pragmatic problem needs to be solved.

[-]

Lex098@reddit

programmer is certain everything is fine

I've seen too many "everything is fine" code that breaks after some changes in the completely different part of the code. Borrow checker allows you to make sure that it's not only fine now, but it'll be fine in the future. I'm so tired of fixing bugs that could have been prevented with BC.

[-]

camilo16@reddit

I've seen too many "everything is fine" code that breaks after some changes in the completely different part of the code

I hate this line, it's such an obtuse response. The standard library for rust uses unsafe in many, many places. The entire point of unsafe is that many times the programmer DOES KNOW BETTER than the BC.

The language has a mechanism to bypass the BC precisely because it is aware that many situations call for things that are sound but that the BC cannot prove.

ffs, I really want the rust community to stop repeating this line like if it was a religious mantra. The BC helps, the BC also gets in the way.

[-]

juhotuho10@reddit

Unsafe doesn't disable the borrowchecker, it just gives the developer a couple of extra powers like dereference a raw pointer

https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#unsafe-superpowers

[-]

Lex098@reddit

many times the programmer DOES KNOW BETTER than the BC

For regular code it's not true for 99% of the time. Most of the times people don't know enough to understand that they, in fact, do not "KNOW BETTER", e.g. Rust std bug. Two completely separated parts of the code, but if you use them together - they explode.

[-]

Glacia@reddit

From purely academic standpoint your idea of what strong typing is 100% correct. Honestly, the only reason i called it strong typing is because i dont know any alternative term that suits it better. Someone should probably make one.

[-]

pattheaux@reddit

Sorry, the hive mind does not currently allow this opinion.

[-]

Glacia@reddit

Most of the reddit is webdev kids who use python, js etc. For them having typed arguments is the enlightenment of their life and peek of strong typing.

[-]

Connect_Swim_9177@reddit

As someone who's currently dealing with what used to be a completely untyped Python project at work, sorry but hard disagree here. The benefits of types are obvious and numerous, and the errors they prevent are real. Don't take it personally, but I'm honestly at a point where I can't help but question the professional experience of anyone who doesn't see the utility in static analysis.

[-]

Glacia@reddit

You're missing the point i was making. We're talking in the context of compiled languages, so C is my bare minimum weakly typed language. I didn't talk about dynamic typing, that's just plain dumb.

I'm honestly at a point where I can't help but question the professional experience of anyone who doesn't see the utility in static analysis

First sentence in my post was "I'm not against strong typing", so how come you came to this conclusion? I understand the utility. I've used strong typed languages before Rust even existed.

[-]

Connect_Swim_9177@reddit

First sentence in my post was "I'm not against strong typing"

Are we just going to gloss over the fact that the rest of your comment talks about how types are "neatively affecting productivity" and "wasting your time for nothing"? I don't see what other possible interpretation I was supposed to pick up from that.

[-]

Zig takes "no hidden control flow" seriously, which means that "x + y" doesn't implicitly cast unless it's trivial to do so.

You can't event divide an integer by another integer in zig. https://www.reddit.com/r/Zig/comments/12kg2up/signed_integer_division_why/

Because 2 / 3 could be 1 or 1.5, so you need to use @ divTrunc (space because Reddit makes it an user link), which isn't a normal function, but a compiler function.

The syntax to cast things is ridiculously long. You need to use as(type, value). But as doesn't cast, it just sets the target for the compiler. So you would need as(i32, floor(value)) for example.

This can get so ridiculous and verbose that when I tried to make a game with SDL, I could barely read the formulas that I was writing because 90% of the line was casts. It's really not readable at all, and I don't think they'll ever want to fix that.

Also note that part of Zig's design is that the AST can parse any line without looking at other lines. Which means there are no multi-line comments or multi-line strings. The official suggestion seems to be just surrounding a block with if(false) which makes the compiler ignore it, but that doesn't help with any syntax errors you may have in the code. That sucks, to be honest.

But it compiles REALLY fast, so you just ignore these minor inconveniences like these because whatever time you waste with it you would have wasted waiting for other low-level languages to compile. So it's worth it.

[-]

sad_bug_killer@reddit

(space because Reddit makes it an user link)

anacrolix@reddit

Linux kernel will be very good for Rust. It will benefit immensely from fitting into the space.

[-]

yawaramin@reddit

Linus will chew you out and call you names your mother would be offended by on a public forum.

If you end up writing it in Rust, would you mind give an update just to show what was the process and how did you ended feeling throughout the development process VS what you did in C? 😄

[-]

fondle_my_tendies@reddit

The Rust community is also toxic IMHO.

Woah, be careful talking about the rust community, you might get tens of downvotes.

[-]

bwainfweeze@reddit

Heaven forbid we make r/programming mad by stating an opinion that they don’t understand. That would be terrible. We’d have to quit our jobs and become hermits.

[-]

nekokattt@reddit

You mean like what happened with Actix?

https://github.com/fafhrd91/actix-web-postmortem

Not Reddit related, but related to the comment you are responding to.

[-]

bwainfweeze@reddit

There’s a tendency among programmer to value the intellectual above all else. But any therapist can tell you that trying to intellectualize everything is a coping mechanism with quite dire consequences on the rest of your life.

There’s a tendency here to downvote ideas that are backed by experience/empiricism if they are counterintuitive, because they don’t sound truthy enough and they challenge “reason”.

Last time I bothered to care, my biggest downvotes weren’t from saying something rude (though there are a couple cults of personality I enjoy poking occasionally). They’re from saying something peripherally about cognitive load that any cognitive scientist would agree with.

But there’s this toxic macho (Calvinist) ethos in programming where some of us clearly wish we were computers and any talk of us being frail humans is the highest of heresies.

At this point I just call it job security.

[-]

erythro@reddit

But there’s this toxic macho (Calvinist) ethos in programming where some of us clearly wish we were computers and any talk of us being frail humans is the highest of heresies.

*Jean Calvin stumbles onto this thread* wtf is a computer

Seriously though I'm pretty sure humans being frail is like the single core Calvinist belief lol

[-]

bwainfweeze@reddit

Calvinists believe suffering leads to an eternal reward. As someone once put it to me: It underpins most of US culture the way Shintoism is the undercurrent in Japanese culture - even if you aren’t a member, you’re still practicing a subset of the beliefs.

[-]

erythro@reddit

Calvinists believe suffering leads to an eternal reward

this is literally the opposite of what Calvinists believe as I understand it. Calvinists believe nothing you can do leads to eternal reward, that it's literally about being chosen by God and nothing else. They believe people are weak and aren't capable of believing in God, they believe and are saved only because God specifically enables them to do so.

If I try to join up what you are saying with my understanding with a shot in the dark: there's the "how do I know I'm one of the chosen?" problem with Calvinism, which one response I guess could be something like "I know I'm chosen because my life is one characterised by perseverance through suffering", which might be where you are coming from?

As someone once put it to me: It underpins most of US culture the way Shintoism is the undercurrent in Japanese culture - even if you aren’t a member, you’re still practicing a subset of the beliefs.

This is true! But I would argue it's bigger than Calvinism. Your critiques of Calvinism will also be rooted in the historic debates about the reformation and Christianity going back from there.

[-]

avbrodie@reddit

Very well said. Downvoting ideas based on experience and upvoting based on the community zeitgeist.

fixed

[-]

LuckyHedgehog@reddit

Here is all that is mentioned about Rust

Switching to a more modern topic, the introduction of the Rust language into Linux, Torvalds is disappointed that its adoption isn't going faster. "I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust."

On top of that, Torvalds commented, "Another reason has been the Rust infrastructure itself has not been super stable."

[-]

celalith@reddit

On top of that, Torvalds commented, "Another reason has been the Rust infrastructure itself has not been super stable."

What does he mean by this?

[-]

YeetCompleet@reddit

I saw a GitHub issue somewhere before which listed all of the nightly rust features that Linux uses, so probably that

[-]

Localghost385@reddit

I'm no expert, but this doesn't seem like a situation to be using nightly features?

[-]

Tony_Bar@reddit

A lot of the replies seem to not understand that for certain things they need unstable features to get Rust to work at all for what they want to do.

Here's a talk from RustNL from a few months ago that examines one case of needing to use unstable features to get the job done: https://www.youtube.com/watch?v=gr9v0FFXaZ8

[-]

NMe84@reddit

A lot of the replies seem to not understand that for certain things they need unstable features to get Rust to work at all for what they want to do as varen0k also pointed out.

If you need unstable features in your usually stable software product, maybe it's too early to start using the tech you're looking at...

Nothing to be done about it, allocator_api, new_uninit, get_mut_unchecked and so forth are going to be required. A lot of things have to be invented, like support for the memory model and ways of performing practical things like pinned initialization (placement new...), because a lot of what you need to do in low level code like operating systems is antithetical to the way the Rust core team thinks code should be structured, so things like receiving a resource that is already constructed in heap memory and never moves for example is just not in the working model of what Rust wants programs to deal with. In Rust by default you don't create objects in heap memory, you create things on the stack and they immediately start being moved around, even simple things like initializing a Vec without copying it from the stack on initialization is arcane. That type of thing isn't what you want for kernel code. A lot of things coming out of the Rust for Linux work will eventually be in core Rust, but for now the project will have to crawl before it walks.

[-]

josefx@reddit

so things like receiving a resource that is already constructed in heap memory and never moves for example is just not in the working model of what Rust wants programs to deal with.

How do Rust programs deal with shared memory and OpenGL or CUDA buffers? Mapping existing structures into a process seems like it should be a basic requirement.

[-]

dontyougetsoupedyet@reddit

You get a ‘&mut’ and do your best to avoid undefined behavior.

[-]

FamiliarSoftware@reddit

Pretty much the exact same way C or C++ do. You get a pointer and a size to the buffer and cast it to an appropriate slice. This step must of course be done in an unsafe block in Rust, but once you have your slice, it's just an array you can read from or write to.

If the CPU and GPU can read/write at the same time and it's not just being handed back and forth, you'll need to use atomic operations to avoid UB. Rust just copied the C++ atomics model because that's what LLVM expects, so the UB semantics and required atomics are also the same.

[-]

kiwidog@reddit

Curious about this too, because the last time I used Rust for those years ago, it was just C++ bindings for RS. (aka you couldn't at this time)

[-]

Kok_Nikol@reddit

The title literally has "needed" in it...

[-]

the "major ones" but I'd expect a bunch of them lingering in the nightly for longer

[-]

bascule@reddit

They have a specific list of things which would be nice to get done this year for Linux but may be stretch goals, as it were: https://rust-lang.github.io/rust-project-goals/2024h2/rfl_stable.html#the-shiny-future-we-are-working-towards

They also say:

The primary goal is to offer stable support for the particular use cases that the Linux kernel requires. Wherever possible we aim to stabilize features completely, but if necessary, we can try to stabilize a subset of functionality that meets the kernel developers' needs while leaving other aspects unstable.

Also they want to get RFL into the Rust project's CI which could spot breakages to RFL when changes are made to rustc.

[-]

rebbsitor@reddit

If features you need are only implemented in a language in nightlies, you really shouldn't be using that language yet.

[-]

ridicalis@reddit

It's not entirely uncommon for Rust-based projects to depend on nightly features. That said, there's usually a strong push to either stabilize those features or migrate away at the earliest opportunity.

[-]

jl2352@reddit

Linux cannot use stable Rust currently. Work needs to be done to enable that, and any work in progress will be available via nightly. Hence why nightly is used.

In particular the Rust compiler has a lot of magic, hacks, and special code, that enables many bits across the standard library. Part of the work is to replace that magic code with standard stuff for all to utilise.

chickenporkbeefmeat@reddit

Well that's... how code and compilers work.

[-]

tonymurray@reddit

He means it changes, not that it crashes.

[-]

matthieum@reddit

After some digging, he seems to be referring to infrastructure (for Rust) in the kernel.

It's unclear whether this means build-system or APIs, however. Both are reportedly unstable.

In terms of build-system, for a long time the Rust For Linux branch was using the nightly compiler, pinned to a particular version. There was no attempt at being compatible with any other version, so contributors may have been finding it hard to keep-up. The situation is better now, the latest Linux release is based on the stable compiler release (1.78) though compiled in bootstrap mode to use the unstable features still.

In terms of API, it is my understanding that they've been in flux, which is not unexpected as there's a LOT to do, and to get right, but does mean that any attempt at building on top of those may be frustrating. Building on shifting sands is never easy. I'm not sure if it's gotten better. I would expect it'll take them to shake them out.

[-]

Mognakor@reddit

Languages like C and C++ have a clear standard that is discussed in working groups of industry giants then can be implemented by compiler vendors and programmed against by programmers. Projects like Linux also may commit to a certain version of the standard and only switch when there is no (major) impact by a switch and the relevant compiler(s) fully supports your new version. Also deprecations, removals or breaking changes of existing language feature are a huge topic and only done when there is a lot of buy in and no major stakeholder is opposing it.

Afaik Rust on the other hand is more like a living standard and whatever the Rust compiler deems correct. There are ongoing efforts to create an official spec but idk what the state of that is.

[-]

ExeusV@reddit

Languages like C and C++ have a clear standard that is discussed in working groups of industry giants then can be implemented by compiler vendors and programmed against by programmers. Projects like Linux also may commit to a certain version of the standard and only switch when there is no (major) impact by a switch and the relevant compiler(s) fully supports your new version. Also deprecations, removals or breaking changes of existing language feature are a huge topic and only done when there is a lot of buy in and no major stakeholder is opposing it. (e.g. there are proposals to C++ that may require a change to the ABI and being blocked because of that)

And yet, the final result is giant mess of developer-hostile programming environment.

[-]

moltonel@reddit

The Linux kernel doesn't care about language standards though, only about what compilers actually implement. Linux notoriously used many nonstandard gcc extensions, which slowed down enabling the use of clang. AFAIK there are still a handful of extensions used (different ones for each compiler).

Yes, things like community rifts related to async and other feature designs wasted tons of time for the language. I use Rust probably more than most people commenting on it, I feel comfortable asserting that the language ecosystem itself "lags expectations."

[-]

Wonderful-Habit-139@reddit

Could I get an explanation for why placement new matters? Afaik this is a concept that exists in C++ but not C, yet the linux kernel is written in C. I think I saw your other comment where you mentioned things like get_mut_unchecked, however later on you mention features that need memory allocation to have been already implemented.

You also mentioned heap allocation (which again, needs memory allocation to have been implemented) needing to move data from the stack into the heap, which is something that happens only in debug mode not release mode (which is not ideal but doesn't mean it's impossible at all).

Other people have answered a bit about what this is. Thankfully, improving this is one of the few official project goals for the rest of 2024. (And probably beyond.)

That official post should also help clarify this specific issue about Rust for Linux stability.

Or I can just copy the paragraph.

Rust for Linux. The experimental support for Rust development in the Linux kernel is a watershed moment for Rust, demonstrating to the world that Rust is indeed capable of targeting all manner of low-level systems applications. And yet today that support rests on a number of unstable features, blocking the effort from ever going beyond experimental status. For 2024H2 we will work to close the largest gaps that block support.

Those links provide more detail about what needs to be improved.

[-]

brintoul@reddit

VIP-like comment right here.

[-]

CrazyKilla15@reddit

I seem to be the minority here, but I interpreted this to mean the kernels Rust infrastructure, the kernel-specific crates and wrappers they're writing and all the infrastructure around it, as being unstable. Its all new, in flux, what the APIs should look like in question, etc.

To me this also makes the most practical sense, because the kernel pins their nightly version, nothing is changing that they dont want to change, and the "unstable"(as in not in Rust stable, not necessarily as in buggy or constantly changing APIs) features it depends on are, I would think, either pretty solid at this point, or changing at their own request to better fit their needs.

If this quote is really the entirety of what he said during the whole talk, i dont think theres enough detail to know what he actually means and itd be nice to get clarification sometime

[-]

moltonel@reddit

Note that they've always used stable rustc versions. The recent improvement (which involved work both in Linux and in Rust and rustc's CI) is that they can use a range of versions instead of a single pined one.

[-]

CrazyKilla15@reddit

Huh.. That raises more questions

So if I understand it right, before they were using a single pinned one? And now they're more free to use any newer ones since every Rust change is tested against what the kernel needs in CI now?? But they're still using stable?(oh god.. they must also be using RUSTC_BOOTSTRAP then huh)

But if it was pinned before then what "extra version checks and things like that" did they need and now remove??

[-]

moltonel@reddit

Yes, they use RUSTC_BOOTSTRAP. It's better than choosing a particular nightly and forcing it on users.

They removed the "is rustc/bindgen too new ?" checks and kept the "is it new enough" ones. This is essentially a documentation/process change, no actual kernel code changed. But arriving at that point required adding RFL to rustc's build-check CI (so that if a change to an unstable breaks RFL, it can be either reverted from rustc or handled in RFL), and improvements in the alloc crate and corresponding RFL code so that RFL no longer needs to copy-fork it inside RFL (and therefore be tied to the rustc version it's copied from).

[-]

CrazyKilla15@reddit

Yes, they use RUSTC_BOOTSTRAP. It's better than choosing a particular nightly and forcing it on users.

[-]

epage@reddit

I remember a discussions that predates any rust in linux talk about the difficulty of on-boarding C kernel developers. A lot of the world / education syrtem has shifted to higher level programming. Rust offers the ability to on-board people more easily because of the extra by-default guard rails. When I was at a company doing kernel programming, we had a similar problem with hiring and that was a big reason I got excited about Rust.

[-]

LordoftheSynth@reddit

People hate the borrow checker? I'm shocked.

[-]

CrazyHardFit@reddit

No one knows how to use it, it's less powerful, and it's buggy?

[-]

shevy-java@reddit

The Rust infrastructure has not been super stable!!!

[-]

aystatic@reddit

CyberDumb@reddit

I am not that old and I started programming by coming from a digital and analog design background. C is the most simple language. Syntax is literally tiny and if you understand how memory works and the c memory model you are basically done.

Young people seem to be extremely unaware of hardware and want to just write code that works. Languages seem to target this and it is kind of disappointing. You certainly should not write performance programs if you do not understand computer hardware and concurrency.

I have worked professionally in large c and c++ projects and I am learning Rust now. To be honest I have not yet understood the fuss and the noise around safety. My experience taught me that the most difficult part is architecture and design. Which are language irrelevant.

[-]

chucker23n@reddit

if you understand how memory works and the c memory model you are basically done.

Young people seem to be extremely unaware of hardware and want to just write code that works.

It has nothing to do with “young people”. You can look at smart programmers, average programmers, young programmers, old programmers, programmers in academia, programmers at startups, programmers at Google or NVIDIA.

Across the board, when writing C, they make memory mistakes, with potentially catastrophic consequences for production software. Those mistakes responsible for the majority of security issues in recent decades. The solution is not a Sufficiently Hardcore Programner; it is a better language.

[-]

CyberDumb@reddit

C is pretty plain and needs high level features. C++ is kinda this but is horrible in a lot of respects and huge. Also the c++ committee has ignored embedded for a long time making it tricky for embedded. I will keep studying rust and use it for a multi-core project of mine however I am not sold on it yet. Rust is one of many c killers around the years but nothing has killed c or c++ and nothing wil for many reasons.l

[-]

chucker23n@reddit

Rust is one of many c killers around the years but nothing has killed c or c++ and nothing will for many reasons.

chucker23n@reddit

Instead of making such tooling better and faster and cheaper

We did. We made compilers smarter. We added more static analysis like clang-sa. And then we realized: what would be even better is a new language.

we get distracted coming up with new languages

always fun when you think your ye olde Java is portable and you try to test windows on ARM and find out there is x86 hiding in there somehow. At least JS has a lot less of those grenades laying around. And we have the awkward middleground of asm.js and wasm. Its never going to be super power efficient but just changing the programming language wont fix it. You can spinlock in C++ or Rust so its really about wanting to design power conserving software, even if its only about powerbills or advertisable battery life of a device you are selling. If its not of value to the dev/corp people will find ways to write unperformant code regardless of the underlying tech.

[-]

urmyheartBeatStopR@reddit

so that isn't even a real downside.

Coding in Javascript isn't a downside?

I mean it's fun for front end, but JS for everything is not every body cup of tea.

The JS equivalent is pretty fucked. Just google wtf javascript.

[-]

Interest-Desk@reddit

Every language has stupid features that stupid developers can use to achieve stupid things. JS is just notable because it has a unique number of stupid developers.

[-]

neveler310@reddit

That is a real downside with talks about carbon footprint

[-]

Turtvaiz@reddit

Never thought anyone would say carbon footprint as the reason why electron/js is bad lol

[-]

gummo89@reddit

Ah yes, but if you can decrease the processing on your servers and the number of computers running each day (fire developers) suddenly it's easy!

Then use the saved money from firing developers and cutting feature development to pay carbon offset corporations. Success!

[-]

Narishma@reddit

More like reusable (cheap) developers.

[-]

gnulynnux@reddit

https://blog.fishsoup.net/2008/10/22/implementing-the-next-gnome-shell/

Assuming you mean Gnome, it's really not a bad choice. You need a scripting language, you want it to be low dependency, and you want it to be something a lot of people know.

They were also looking at Mono/C# and Vala at the time. Other choices would've been Python or Lua. I think JavaScript was the right choice.

[-]

monkeynator@reddit

It probably was, although I kinda like the larger scale you can muster with languages like C#/Dart.

[-]

gnulynnux@reddit

My big issue with C# is the dev tooling is pretty abysmal, even in 2024, unless you're using Visual Studio on Windows. (Even the C# plugin for VSC breaks regularly!)

I can't imagine being a Linux dev in 2008 using C#, pre-Roslyn, pre-LSP. etc.

[-]

monkeynator@reddit

Oh sure, I wouldn't touch C# with a ten feet pole these days (when Dart exists) it's in a very chaotic state of affairs (archaic old standard along side modern ones).

[-]

QuackSomeEmma@reddit

Qt QML uses JavaScript as well. It's a widely used language with a choice of several fast, secure, and well tested interpreters. Perfectly reasonable choice when used in low doses.

[-]

gnulynnux@reddit

Exactly!!

anyhow's

result.context("reticulating splines failed")?;

is cleaner and creates a nice chain of causes when printing the error.

[-]

glitchvid@reddit

Anyhow is very nice and solves a specific but common use case, however inspect_err is a much simpler "building block" for a huge swath of error handling, and doesn't require pulling in another dependency.

A example for the latter case is calling a fallible function, you may then want to emit a tracing event if it fails but then return a default value.

let viewer = User::from_id(id)
.inspect_err(|_| event!(Level::INFO, format!("Invalid User: {}", id)))
.unwrap_or(USER_GUEST);

[-]

Green0Photon@reddit

With links

Rust for Linux. The experimental support for Rust development in the Linux kernel is a watershed moment for Rust, demonstrating to the world that Rust is indeed capable of targeting all manner of low-level systems applications. And yet today that support rests on a number of unstable features, blocking the effort from ever going beyond experimental status. For 2024H2 we will work to close the largest gaps that block support.

[-]

aboukirev@reddit

Zig is more C-like than Rust and has pluggable memory allocators, more natural for use with the kernel. But the language is not ready yet and by the time it matures Rust would have taken the spot. Life is unfair.

[-]

Isogash@reddit

Zig doesn't have the same strictness that Rust provides though. Really, the point of Rust is to allow high level abstractions, safety and performance that is simply not possible for C or C++ due to fundamental constraints with the language design. In theory, it's ideal for an operating system.

The downside is, as always, an accrued level of complexity that results in a fairly steep learning curve. Rust is a mix of ideas, some of which have worked great and others not so well. It's far from a perfect language but it does represent a significant evolutionary step in programming languages.

In the far future, we'll all be using functional/declarative languages anyway.

[-]

oursland@reddit

Rust includes operator overloading and overloading of functions. While these items may be convenient for developers, it makes reasoning about code nearly impossible.

For example c = a + b in C is a simple addition without any surprises. There's rules about type promotion such as int to float, but the compiler will warn about these. A developer can reason about the CPU and memory demands of this line of code that can aid in guaranteeing deadlines and constraints are met.

In Rust (and C++), c = a + b involves knowing which operator+ is being called and understanding the costs of performing this operation. If it incurs extra memory usage, it may not be used in some contexts such as interrupt handlers or some drivers. If the operation is time costly, it could result in missing critical deadlines.

Memory safety isn't the only thing that matters when selecting a language, critical time and space constraints must also be considered. A simpler language that is multithread-aware would be a better fit.

[-]

GameGod@reddit

I hate this argument - In any IDE, you can easily see the types of c, a, and b, and if they're not POD, then they're using an operator overload for sure. You can just.... read the code! This is basic C++ literacy, it's not a pitfall.

[-]

oursland@reddit

When it comes to writing operating systems code, if it isn't obviously correct, then it is obviously wrong. Overloading eliminates the "obviousness" of a given operation, making it hard to reason about and resulting in many errors and bugs.

[-]

r1veRRR@reddit

It's crazy that operator overloading is a problem, but the memory unsafety Rust takes care of and that has killed people in C/C++ based systems is not.

[-]

oursland@reddit

Those are different classes of bugs. Rust addressed memory ownership, C addresses correctness and analysis.

The thing is that many aspects within kernel development prohibit the allocation and sharing of memory altogether, so focusing on addressing ownership of memory isn't even a concern. Ensuring correctness (obviousness) and deadlines is typically a greater concern than sharing pools of memory between threads.

[-]

GameGod@reddit

Man, you must be fun to work with. This kind of preachy idealism would make me quit if I had to work with you.

[-]

oursland@reddit

You don't work in operating systems, do you? Did you ever ask why all of the ones in common use are written in C? I'm not talking about old OSes either, take a look at new ones such as Zephyr.

[-]

NotUniqueOrSpecial@reddit

it makes reasoning about code nearly impossible.

It makes reasoning about code literally no less possible than any other function call.

If you are using a type, you must understand the contracts of its functions; whether those are named functions or operator overloads is beside the point.

If it were possible for external code to modify the behavior of operators for other types (especially primitives), like, say in Python or Forth, your argument would make sense.

But that's not the case in C++; if you've got code that's foo + bar , you know their types and as a developer it's your responsibility to know what that operation does.

Forcing that operation to be, say, AddScalarVectors(Vector a, Vector b) doesn't inherently make it easier to understand, and in the cases where operator overloading is generally used in practice (as opposed to the boogeyman people claim exists), it's universally because it makes the code more readable and generally more idiomatic to the domain/types in question.

[-]

DentistNo659@reddit

But it does not provide most of the memory safety rust provides, which is the main reason to switch away from C.

[-]

AlienRobotMk2@reddit

With defer and explicit pointer nullability, Zig is already far safer than C and practically almost every programming language with reference types, including Java, C#, Python, Javascript, etc.

I don't have a lot of experience with C, but in my limited experience with C, it was so bad it scared me. If I remember correctly, you can just pass a pointer to any structure to any function that takes a pointer, and the compiler won't even issue a warning about it by default. C++ won't let you do this, you must cast.

I'm pretty sure there are already countless improvements that Zig provides over C. It's not that Rust is good, it's that C is really bad, it's a thin layer over assembly, and it doesn't even have the compilation speed of pascal. I think it's pretty much a miracle anyone can program whole things in it, to be honest.

[-]

m_zwolin@reddit

In your limited experience with C you didn't learn why you advocate Zig definitely

[-]

DentistNo659@reddit

Its not hard being safer than C, but where Zig falls short is that none of the safety is really enforced. Defer is optional and is really more about convenience than safety, and a lot of the other memory safety options are checked at runtime, and only in debug builds. Zig does not prevent use-after-free, use of uninitialized data, pointers to data on the stack being returned, multiple threads accessing the same data at the same time, etc. This is all stuff that (safe) rust guarantees.

[-]

AlienRobotMk2@reddit

I'm honestly not sure the "safety" of Rust is worth it. Like I said, Zig is safer than C. Zig compiles faster than C. Zig provides conveniences that C doesn't offer. This frees time for programmers to work on improving the software, making the code safer.

I would understand if Rust created perfectly safe programs, unexploitable software. Then it would always be worth it. But that isn't a guarantee the language can provide. It "only" provides memory-safety.

I wonder if this memory-safety is really worth the trouble. Maybe I'm just not smart enough to see its benefits?

If user-after-free is such an immense problem, why not just implement a garbage collector in the kernel? If there is no GC in the kernel, it can't be that much of a problem. In fact, you wouldn't even need that. Just use C++'s shared pointers. Why is the kernel not using C++? It's been around for decades.

It's just really strange to me. Maybe I should try Rust again, see if I can program something in it to get a feeling of the pros and cons of memory safety, because as it stands I can't say I really understand what we're talking about.

[-]

ConvenientOcelot@reddit

I'm honestly not sure the "safety" of Rust is worth it.

It is in the kernel which has full access to your system.

It "only" provides memory-safety.

You're missing how many vulnerabilities are directly a result of memory unsafe languages.

If user-after-free is such an immense problem, why not just implement a garbage collector in the kernel?

GCs do not prevent use after free. The borrow checker, however, does.

Linux already provides GC in the form of manual refcounting in some structures, but being manual it's subject to memory bugs too. Rust can make that automatic with RAII.

You said C isn't bad, just low-level, so what is low-level and bad for you?

[-]

s33d5@reddit

I wouldn't say any are bad, just criticisms. Zig and Rust, for example, are still young with an undeveloped ecosystem with ELEMENTS that shouldn't be used in mission critical systems yet.

However, all languages have their place and are here to solve a problem. Rust is a great alternative to C where memory safety is more important than limiting esoteric engineering knowledge.

Fanboy/fangirling languages is just silly. They are tools that we should just use when we need them for their designed task.

[-]

nerd4code@reddit

C at what optimization level? What compiler? What host? Pascal at what optimization level? What compiler? What host?

Because you’re saying fuck-all of meaning without that info. C and performance in C are vast universes, and there is no singular default point to pick at here.

Zig, of course, there’s only the one impl of, which is cute I guess. That shows how very popular it is, and therefore a very good choice for a preexisting global programming effort.

[-]

uss_wstar@reddit

With defer and explicit pointer nullability, Zig is already far safer than C and practically almost every programming language with reference types, including Java, C#, Python, Javascript, etc.

Zig most definitely is not safer than any of those except C. Those languages have garbage collectors which ensure that resources live as long as there are references to them. Zig will catch memory leaks and out of bounds accesses, and it willl catch some lifetime bugs at runtime in debug mode, but it is not memory safe.

[-]

AlienRobotMk2@reddit

Being "memory safe" is an arbitrary benchmark that favors Rust. Memory safe doesn't even mean the program is safe. A memory safe program can cause data loss, can be exploited. So it's a weird benchmark to have, when you consider that a program in C can be memory safe just by not having any memory-related bugs in its code.

If there is a null access in C, or None in Python, the program halts. If there is data loaded in the program, you lose data. That is a real problem which Zig helps address. It's not as bad as a buffer overflow, but most of the time this is the problem you'll be having, not buffer overflows, just null access. Any time you can do null access, and the program can halt, and you can lose data, that is an unsafe program. And this is basically every function.

If every pointer can be null do you have to write a null/None/undefined check for every single pointer in every single function and return the appropriate error in this case, or do you just let it run until it breaks? I don't want to waste time thinking about it. This single feature would make programming so much easier it's ridiculous it's not implemented everywhere. So I really think Zig is safer than even Python.

[-]

uss_wstar@reddit

Being "memory safe" is an arbitrary benchmark that favors Rust.

Uhh, no. Memory safety is a property nearly all garbage collected languages have barring escape hatches like unsafe {} in C# or ctypes in Python.

Memory safe doesn't even mean the program is safe. A memory safe program can cause data loss, can be exploited.

It's not a weird benchmark at all, it is well known that in large C and C++ code bases, most bugs are related to memory safety and memory safety can often lead to exploits. Eliminating 70% of bugs seem like a big deal to me, and already a good reason to use a GC language let alone Rust.

So it's a weird benchmark to have, when you consider that a program in C can be memory safe just by not having any memory-related bugs in its code.

When we say a language is memory safe, we mean we can either statically prove that it can't cause memory unsafety or can safely crash if it detects an operation that would cause memory unsafety. The point is to reduce the impact of human error.

If there is a null access in C, or None in Python, the program halts. If there is data loaded in the program, you lose data.

This is not true. Dereferencing a null pointer is undefined in C. The program may crash but it also may not and since the compiler performs optimizations assuming undefined behavior won't happen, this might open the system to vulnerabilities. In Python, None is just a value and depending on what you're doing with it, you may get a type error, which you can catch, but you cannot cause memory unsafety with it.

hat is a real problem which Zig helps address. It's not as bad as a buffer overflow, but most of the time this is the problem you'll be having, not buffer overflows, just null access. Any time you can do null access, and the program can halt, and you can lose data, that is an unsafe program.

I won't defend Java's decision of essentially making every value an Optional without strict typechecking but you have to understand that this cannot cause memory unsafety in Java. And Optionals is not something that is unique to Zig. Rust has it, so does nearly every FP language, C#, Typescript and so on.

[-]

AlienRobotMk2@reddit

I meant the benchmark is arbitrary compared to non-GC languages (C, C++, Zig).

I'm not saying Zig is safer than Rust. But memory-safety isn't the only kind of safety. You said 70% of bugs are memory-related, so you still have 30% of the bugs even if you rewrote the entire Chromium project to Rust.

I see Chromium doesn't even consider null dereference a security bug, even though it could crash the browser and lead to data loss. Fine, that makes sense. You can't breach the sandbox with a null dereference.

But how much time is wasted fixing null dereference bugs? There are 900 high security bugs. How many because someone forgot a null check?

Zig isn't "memory-safe" but it doesn't to be to be an improvement over C and many other languages used today.

[-]

yawaramin@reddit

Yes, Zig can be an improvement over C. But can it be enough of an improvement that it beats out Rust's improvements for Linux kernel development? Clearly, no.

[-]

pron98@reddit

It actually provides most of the memory safety features Rust does. It has sound spatial safety and type safety, and its temporal safety -- while certainly not sound -- is better than C's.

[-]

DentistNo659@reddit

Sure, it has a better type safety, but other than that, afaik most of the safety features it has are checked at runtime and only in debug builds or using a special heap implementation. Even with those, it still allows use-after-free, use of uninitialized data, pointers to data on the stack being returned, multiple threads accessing the same data at the same time, etc. This is all stuff that (safe) rust guarantees.

[-]

pron98@reddit

afaik most of the safety features it has are checked at runtime and only in debug builds or using a special heap implementation

Spatial safety is done the same as in Rust and is sound. Temporal safety is, indeed, unsound, but still better than C.

This is all stuff that (safe) rust guarantees.

There is no doubt Rust guarantees more but 1. what Zig guarantees is closer to Rust than to C, and 2. Rust's guarantees do come at a significant cost.

[-]

yawaramin@reddit

Rust's guarantees do come at a significant cost.

You mean like the complexity of programming in Rust? Every programming language has complexity. Fortunately, people are able to learn how to do complex things. For the Linux kernel, there should be a higher bar for safety and security than for Tom Dick and Harry's project.

[-]

pron98@reddit

Even if what you're saying is accurate, it doesn't matter if people don't believe it, but it's not even certain that what you're saying is accurate. If the complexity reduces productivity, it's a constant tax that can also hurt correctness.

Memory safety is not a goal for software. It's a means to achieving correctness, which is the goal. Because both safety and correctness aren't binary, and because some combination of sound and unsound techniques must be used for correctness anyway (even in Rust), the conclusion that more marginal sound memory safety guarantees is always worth the marginal cost doesn't follow. I'm not saying it's not a reasonable hypothesis, but it's far from proven, which is the reason it's not easy to convince people to believe it even if it does happen to end up being true.

[-]

yawaramin@reddit

Sure, it's not 'proven' (whatever that means). But there is wide-ranging industry consensus based on pretty strong findings across different organizations that memory-safety issues are the vast majority. Why use a language that doesn't guarantee memory safety when we can use a language that does? Even assuming that Rust is about as complex as C++, people are still using the latter, and Rust guarantees more safety!

[-]

pron98@reddit

Why use a language that doesn't guarantee memory safety when we can use a language that does?

That's like asking why drive a Toyota when you could drive a Ferrari.

Also, the thing is that if you can reduce memory safety issues without eliminating all of them, they're no longer the majority. And at that point what matters more could be readability, velocity, etc.. The question in software correctness is always about balancing different kinds of costs.

[-]

dsffff22@reddit

Life is not unfair, a few devs started the Rust for Linux project on their own accord and then basically showed that Rust can easily life side by side with C in the Kernel without much invasive stuff. Go ahead and start Zig for Linux to show that you can implement It in a non-invasive way!

[-]

Ar-Curunir@reddit

Zig is also memory-unsafe, so does not have one of major benefits of using Rust in the kernel.

[-]

pron98@reddit

Memory safety is not binary. It's a matter of degree, and Zig's memory safety is much closer to Rust's than to C's. The question then becomes whether the pieces it lacks compared to Rust in memory safety are offset by its benefits.

[-]

pheonixblade9@reddit

sure, but "use after free is impossible at a fundamental level" being a feature of Rust is pretty amazing.

(yes, I know that there are ways to do it, but you have to try really hard)

[-]

pron98@reddit

Absolutely, but amazing doesn't necessarily mean "worth it".

[-]

Another relevant point from this report:

So, when AI people came in, that was wonderful, because it meant somebody at NVIDIA had got much more involved on the kernel side, and NVIDIA went from being on my list of companies who are not good to my list of people who are doing really good work.

My NVIDIA cards still have problems on Linux. Same card works fine on Windows (which is really such a crap operating system now; + 20 years of Linux totally spoiled me, I no longer understand why Microsoft writes such a lousy operating system. I also have a Win10 machine on my left side on another computer and it is surprising how trash it is. Copying files is sooooooooo slow, and I no longer care about the numerous excuses Windows developers use here. Linux copies quickly, why does Windows slow me down!).

[-]

ArdiMaster@reddit

Windows Defender does synchronous scans of files as they’re opened. (That is, the kernel will wait for Defender to okay a file before the open/NtCreateFile syscall returns.) Apps that touch a lot of files quickly can see a significant performance improvement when you add them as an exception in Defender.

Also, as others have already mentioned, Explorer is surprisingly inefficient at copying files.

[-]

NavinF@reddit

Copying files is sooooooooo slow

On what hardware? I pretty much never see the file copy dialog on my 2TB KC3000 which is not exactly top of the line

[-]

xADDBx@reddit

Windows Explorer being a bottleneck is actually pretty annoying.

Anyone with basic tech literacy should be able to add a Robocopy context option though.

[-]

The mouse cursor does not change color with the flux on 😖

[-]

So multithreaded code is verifiably safe in rust?

Can't i write a deadlock in rust? Can't i write code that throws infonite exceptions in rust? Can't i run out of PC memory in rust?

Lol what the hell verifiably safe even mean? Even assembly is verifiably safe if you read all the code and understand it

[-]

coderstephen@reddit

Lol what the hell verifiably safe even mean?

Usually it means memory safe, so no data races or invalid or unexpected memory accesses. So safe code might suck and crash, get stuck, or use all the memory. But it won't accidentally modify its own code or corrupt memory, that sort of thing.

[-]

sjepsa@reddit

Then this 'guarantee' doesn't look very attactive to me, if as a side effect it complicates writing normal code, and maybe has worse performance

[-]

eugay@reddit

then you should be barred from engineering. Imagine if architects had this dumbass approach to safety.

[-]

sjepsa@reddit

Tomorrow, when you walk down the streets, cover your legs with 10 cm of concrete

That way you will have a not fall guarantee

[-]

duneroadrunner@reddit

C++ does not have that guarantee and isn't a significant improvement safety wise over C.

Well, there's scpptool (my project), a static analyzer that enforces an essentially memory safe subset of C++. It's not going to be adopted as part of the language standard anytime soon, but that issue is not a technical one.

It also has some technical advantages compared to Rust. For example, the act of dereferencing (raw) pointers is part of the safe subset. And for example, self/mutual/cyclic references are supported in the safe subset.

[-]

noboruma@reddit

sans unsafe blocks

We are entering the whole problem of having rust inside the kernel. Unsafe is unavoidable and therefore makes things more complicated for no benefit. Happy to be proven wrong, but from my experience working on the kernel, it was a waste of time.

might as write the new code in Rust anyways.

Not when the whole kernel code is written in C. C++ has the advantage that you could reuse most of the C code and is easy to pick up for devs. Not saying C++ is the answer, but there is a huge cost using Rust that is not necessarily justifiable.

[-]

aystatic@reddit

Not when the whole kernel code is written in C. C++ has the advantage that you could reuse most of the C code and is easy to pick up for devs. Not saying C++ is the answer, but there is a huge cost using Rust that is not necessarily justifiable.

C <=> Rust ffi is nice and easy. you can reuse existing code just fine.

the majority of the work is in designing memory-safe abstractions around these interfaces, which is where rust excels imo. I don't know another memory-safe language that does it better

[-]

nekokattt@reddit

Are you suggesting C <=> Rust FFI is simpler than C and C++ being used together (arguably not even needing FFI in the first place).

The major benefit is it would allow a much smoother transition for C devs.

[-]

LurkDog@reddit

The major benefit is it would allow a much smoother transition for C devs.

I'm starting the process of integrating C++ to my C codebase at work, and my main hangup so far is just how big C++ is.

Right now I am basically writing my code as C with classes, but it would be nice to have some sort of list of C++ features that I should use over my normal C paradigm. I am hesitant to start using features without fully understanding them and common pitfalls.

[-]

_teslaTrooper@reddit

I agree the amount of features is daunting, I'm still learning modern features myself as I started on an embedded platform with only a C++03 compiler. Here are some of the things I've found most useful:

basic classes, inheritance, templates
everything compile time: constexpr, consteval, static_assert
references, like Bob Marley said "no pointer no cry"
if you want to use a templated class like ringbuffer<size_t> but also pass it to generalised functions, make a base class and pass a reference to the base class, added benefit is function definitions can go in baseclass.cpp.
enum classes and types, might just be me but I like knowing the type of my enums

Maybe these are too basic but those stand out to me so far. I'm still trying to fully grasp lvalue/rvalue/*value and move semantics, but I wouldn't want to go back to C at this point.

[-]

LurkDog@reddit

Thanks a lot for this. It's they type of list I am looking for as a C guy trying to move to C++.

Regarding references and enum class types, those were some initial things that I have learned which are obvious advantages compared to my normal C code (I am a big fan of types too)

I am very early into my move into C++ so this sort of "basic" stuff is what I am looking for. Not the "intro to programing" C++ lectures, but stuff aimed at professional C programmers.

[-]

sjepsa@reddit

C++ is strictly better than C.

The problem inside of C++ is basically the old C way of doing stuff (owning pointer, no RAII, raw loops, old libraries)

The only required thing is having good developers that know what they are doing, but of you are writing a kernel that's mandatory

[-]

coderstephen@reddit

C++ is strictly better than C.

Linus Torvalds wants to know your location.

But I've always assumed the number 1 reason Linux won't use C++ is because Linus hates it, whereas Linus appears to be more indifferent to Rust.

[-]

NoobyPants@reddit

Well, replacing everything with vectors is not a drop-in upgrade. For example when it comes to memory allocations they can be slower. That matters in the kernel. The safety gained is marginal at best.

[-]

sjepsa@reddit

I said replacing mallocs with std::vectors

Thay have the same performance, and much more safety (RAII,bounded loops, begin end iterators -> so you access all )

[-]

NoobyPants@reddit

I said replacing mallocs with std::vectors

And how do you suppose the std::vector gets memory to live in? It calls malloc, but for some cases figuring out how much to allocate is nontrivial and you will get suboptimal performance unless you write your own allocator function.

Thay have the same performance Compared to a C array? No they do not. They have a bigger memory footprint too.

[-]

sjepsa@reddit

kmalloc or vmalloc anyone?

std::vector memory footprint is one pointer and an integer (size)

(actually 2 integers (capacity) so you can realloc it in amortized constant time)

[-]

NoobyPants@reddit

malloc is problematic from a safety point of view

Meh, it's a rather well-known problem though. Especially if you're a kernel dev. This is why I say the benefits are marginal at best.

don't have to deal with owning raw pointers

Arguably this is one of the main jobs of the kernel.

So you wrap it around with a std::vector

Yes, in some cases losing performance in the process. If you still think it's better, you are free to propose your changes to any kernel maintainers that'll listen.

std::vector memory footprint is worse

FTFY.

[-]

uss_wstar@reddit

Kernel cannot use malloc, it's what provides support for malloc in the first place! Nearly the entire STL would be unusable since there is internal calls to malloc all over the place. I guess this is also the case for C headers but those reimplementing those for kernel use is relatively simpler. Rust separated its standard library functionality that have no dependencies, that need an allocator but no OS, and need need an OS from the start so this is far less of a problem.

[-]

sweetno@reddit

Actually, as others have mentioned here, kernel does use its equivalent of malloc and there is a concept of allocators in C++. So in principle it's possible, but for a long time was explicitly forbidden by Linus. The reason is that C++ has too many ways to shoot your foot than C.

[-]

kmalloc and vmalloc

[-]

noboruma@reddit

Nearly the entire STL would be unusable

How is Rust solving this problem? The whole std is using malloc under the hood.

The kernel has utilities to allocate dynamically, it's called kmalloc. So sure, malloc does not exist as provided, but the notion still exists in the kernel, with broader implications.

Now to answer the earlier question: Custom allocators. They are both available in C++ and Rust.

[-]

cdrt@reddit

How is Rust solving this problem? The whole std is using malloc under the hood. Vec, String, Box, Arc, and so on.

Everything in the core library is free of allocations. If you need those collections that do need to allocate, you can include the alloc library.

[-]

mallocs in kernel 🤣

[-]

noboruma@reddit

How is that funny and getting upvotes? In the kernel you can use kmalloc and vmalloc to do dynamic allocation. I am sure OP meant just that. If people seriously think we cannot do dynamic allocation in kernel space, those are the ones to be laughed at.

[-]

Shikadi297@reddit

C++ isn't great at these things without strict practices enforced. C++ abstracts some C footguns but creates new ones. Especially given its backwards compatibility that circumvents all its modern features

[-]

Supadoplex@reddit

I'm not sure, but I don't think kernel can use malloc in the first place.

Maybe they could use containers, but only with custom allocators.

[-]

MakeMath@reddit

Hating

[-]

InTodaysDollars@reddit

Assembly language and C; it's the only way.

[-]

green_tory@reddit

Rust isn't available everywhere Linux is, which is also a problem.

[-]

CJKay93@reddit

Rust isn't available everywhere Linux is

[-]

rrzibot@reddit

The articles lies about the video. This part is made up by the article and it is not in the video

Hohndel concluded the discussion by saying he’d used ChatGPT to come up with the top ten questions he should ask Torvalds. The first was, “How do you see the future of open-source software involved, especially with the rise of cloud services and proprietary software?”

Torvalds groaned and replied, “I never had a vision. I don’t want one. I see myself as a plodding engineer.” On that note, the interview ended to the crowd’s applause.

[-]

shevy-java@reddit

Torvalds commented, "Another reason has been the Rust infrastructure itself has not been super stable."

Rustees wake up!

This is the wake-up call. A life-or-death situation.

Read tomorrow's "Why Linus had to kick Rust out of the Kernel".

[-]

coderstephen@reddit

Not exactly which thing being unstable he is referring to, but there's some speculation on r/rust. But currently Linux is using unstable builds and unstable Rust features which may be what he is referring to. There's a push right now to get some of those features stabilized but it will take some time.

[-]

sjepsa@reddit

Imagine if we had a straight upgrade to C from 30+ years

Something that you could use the same compiler gcc

Something like... a C += 1

[-]

nekokattt@reddit

so your answer is RAII and templates?

Because most of the standard library in C++ is reliant on allocators and the kernel being present already.

[-]

FlyingRhenquest@reddit

How about constexpr and templates? Just make all your kernel code constexpr and working with consts. We've been talking about OOP and design patterns for slightly less long than I've been in the industry, it's sad we don't have kernel patterns and any fundamental idea of what an object oriented OS would look like. I feel like IBM tried to go down that road in the '90's and failed miserably.

[-]