Most reasonable people say c is good, rust is better

C is crap for anything where security matters. I'll happily take that debate with anyone who thinks differently.

fn uhoh() {
    let val = 9;
    let val_ptr: *const usize = &val;
    do_some_things(val_ptr);
    println!("{}", val);
}

fn do_some_things(val: *const usize) {
    let valref = unsafe { val.as_ref().unwrap() };
    let mut_ptr: *mut usize = val as *mut usize;
    do_some_other_things(mut_ptr, valref);
}

fn do_some_other_things(val: *mut usize, normalref: &usize) {
    let mutref = unsafe 

This sounds exactly like the type of nontechnical nonsense they’re complaining about: attacking a strawman (“they’re trying to prevent people from refactoring C code and making them rewrite everything in the current fancy language”) even after explicitly calling out that that was not going to happen (“and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code”).

at every chance they get, sell it as C is crap, this is better

For ‘sendmail’ values of $C, this resembles another argument. Also, of course for $C=sysvinit.

Better in what ways? Rust’s strong points are not to just make a program more stable, but more secure from a memory standpoint and I don’t think Linux keeps improving on that

From other discussions I’ve seen, the guy stepping down was frustrated by having C code rejected that made lifetime guarantees more explicit. No rust involved. The patch was in service of rust bindings, but there was 0 rust code being reviewed by maintainers.

Some next level deaf going on. That’s not what was being discussed.

The defensiveness proves just how out of touch and unqualified to comment some people are.

It’s always been this way. Except that it was kernel developers arguing with kernel developers over C code. Now it’s relative newcomers arguing with kernel developers over Rust code that the kernel devs don’t necessarily care about. Of course it’s going to be a mess.

A fork is of course possible, but operating systems are huge and very complex, you really don’t want to alienate these folks that have been doing exclusively this for 30 years. It would be hard to keep the OS commercially viable with a smaller group and having to do both the day to day maintenance, plus the rewrite. It’s already difficult as it is currently.

Rust will be a huge success in time, long after the current names have lost their impetus. This is not a “grind for 4 years and it’s done” project.

That person in the audience was really grinding my gears. Just let the folks you’re talking to answer you; no need to keep going on your diatribe when it’s based on a false assumption and waste the whole room’s time.

There is a fully Rust based Unix-like OS out there, it’s called Redox and it’s very cool

I wonder how plausible a complete Rust fork of the kernel would be.

It sounds highly impractical, and it would probably introduce more issues than Rust solves, even if there were enough people with enough free time to do it. Any change must be evolutionary if it’s going to be achievable.

That’s pretty well answered here: vger.kernel.org/lkml/#s15-3

NOT a fork of Linux, but Redox is aiming for a Unix-like OS based on Rust – but even with “source compatibility” with Linux/BSD and drivers being in userspace, my guess would be hardware drivers are still going to be a big speed bump

There’s certainly a history of Unix and Unix-like forks; which is rather simple compared to the Linux distro forks (go right to the big pic).

Just fork and port Ext4 to Rust and let the little shit sit in his leaking kiddy pool out back.

You should do it. The Linux kernel is a C project. You can’t change a 30-year project on a dime. Make your own project with Rust and hookers.

Why not React?

Compilers follow specs and in some cases you can have undefined behavior. You can and should use compiler flags but should complement that with good programming practices (e.g. TDD) and other tools in your pipeline (such as valgrind).

the semantics of C make that virtually impossible. the compiler would have to make some semantics of the language invalid, invalidating patterns that are more than likely highly utilized in existing code, thus we have Rust, which built its semantics around those safety concepts from the beginning. there’s just no way for the compiler to know the lifetime of some variables without some semantic indication

At the cost of sounding naive and stupid

It may be a naive question, but it’s a very important naive question. Naive doesn’t mean bad.

The answer is that that is not possible, because the compiler is supposed to translate the very specific language of C into mostly very specific machine instructions. The programmers who wrote the code, did so because they usually expect a very specific behavior. So, that would be broken.

But also, the “unsafety” is in the behavior of the system and built into the language and the compiler.

It’s a bit of a flawed comparison, but you can’t build a house on a foundation of wooden poles, because of the advantages that wood offers, and then complain that they are flammable. You can build it in steel, but you have to replace all of the poles. Just the poles on the left side won’t do.

And you can’t automatically detect the unsafe parts and just patch those either. If we could, we could just fix them directly or we could automatically transpile them. Darpa is trying that at the moment.

.

Modern C compilers have a lot of features you can use to check for example for memory errors. Rusts borrow-checker is much stricter as it’s designed to be part of the language, but for low-level code like the Linux kernel you’ll end up having to use Rust’s unsafe feature on a lot of code to do things from talking to actual hardware to just implementing certain data structures and then Rust is about as good as C.

The problem is that C is a prehistoric language and don’t have any of the complex types for example. So, in a modern language you create a String. That string will have a length, and some well defined properties (like encoding and such). With C you have a char * , which is just a pointer to the memory that contains bytes, and hopefully is null terminated. The null termination is defined, but not enforced. Any encoding is whatever the developer had in mind. So the compiler just don’t have the information to make any decisions. In rust you know exactly how long something lives, if something try to use it after that, the compiler can tell you. With C, all lifetimes lives in the developers head, and the compiler have no way of knowing. So, all these typing and properties of modern languages, are basically the implementation of your suggestion.

If you write unsafe code then how should it compile?

This has been done to a limited extent. Some compilers can check for common cases and you can enforce these warnings as errors. However, this is generally not possible as others have described because the language itself has behaviors that are not safe, and too much code relies on those properties that are fundamentally unsafe.

It’s Ted Ts’o, the maintainer of the ext4 filesystem amongst other things.

little shit

Though you’re still accurate despite his seniority.

Agreed. His experience might be useful if he were there to engage, but he’s clearly not. It seems like he just wanted to shout down the project and it seems like he was somewhat successful.

I understand his experience is hard to match, we all have something in our lives we’re that good at

At some point, that mix of experience and ego becomes a significant liability. He’s directly hurting the adoption of Rust in the kernel, while the C code he’s responsible for is full of problems that would have been impossible if written in safe Rust.

CVE-2024-42304 — crash from undocumented function parameter invariants
CVE-2024-40955 — out of bounds read
CVE-2024-0775 — use-after-free
CVE-2023-2513 — use-after-free
CVE-2023-1252 — use-after-free
CVE-2022-1184 — use-after-free
CVE-2020-14314 — out of bounds read
CVE-2019-19447 — use-after-free
CVE-2018-10879 — use-after-free
CVE-2018-10878 — out of bounds write
CVE-2018-10881 — out of bounds read
CVE-2015-8324 — null pointer dereference
CVE-2014-8086 — race condition
CVE-2011-2493 — call function pointer in uninitialized struct
CVE-2009-0748 — null pointer dereference

typedef struct {
    Foo validated
} ValidFoo;

ValidFoo trustMeBro;
trustMeBro.validated = someFoo;
otherFunction(trustMeBro);

Foo* someFoo;
otherFunction((ValidFoo*) someFoo);

fn get_or_create_inode(
    &self,
    ino: Ino
) -> Result<Either<ARef<Inode<T>>, inode::New<T>>>

No intention of validating that behavior, it’s uncalled for and childish, but I think there is another bit of “nontechnical nonsense” on the opposite side of this silly religious war: the RIIR crowd. Longstanding C projects (sometimes even projects written in dynamic languages…?) get people that know very little about the project, or at least have never contributed, asking for it to be rewritten or refactored in Rust, and that’s likely just as tiring as the defensive C people when you want to include Rust in the kernel.

People need to chill out on both sides of this weird religious war. A programming language is just a tool: its merits in a given situation should be discussed logically.

Who is Ted Ts’ in this context?

Phoronix comments were always dumb, like, infuriating bad, I don’t even read them anymore, the moderation on that site don’t give a fuck about toxicity in there

Phoronix comments are a special place on the internet. Don’t go there for a good discussion.

You actually can. And it’s not that hard. I had a 14 year old German shepherd mix, who learned several new tricks before her death. I taught a partially blind 79 year old to use a computer, general internet, and email, and was communicating with her [via email] for a number of years before she lost the rest of her vision.

Old dogs, as it were, absolutely can learn new tricks.

Sorry, I just don’t like this idiom, because it puts people in a box in which they do not belong.

You can, but you can’t turn a 30 year project on a dime. They’re understandably frustrated that newcomers keep coming and screaming RUST RUST RUST RUST RUST

My grandpa taught himself to text when he was 89. He just wrote a translation table:
A = 2
B = 22
C = 222
D = 3
…

At rhe beginning, I did hate it. Now I slowly embrace it as it seems like a feature to be mkre verbose.

But maybe it will never change and I will just gaslight myself liking it. Whatever… you cant take my fun away learning rust for half a year

Well, I’ve been a C/C++ dev for half of my career, I didn’t find Rust syntax ugly. Some things are better than others, but not a major departure from C/C++. ObjC is where ugly is at. And I even think swift is more ugly. In fact, I can’t find too many that are as close to C/C++ as Rust. As for logic… Well, I want to say you’ll get used to it, but for some things, it’s not true. Rust is a struggle. Whether it’s worth it, is your choice. I personally would take it over C++ any day.

I just don’t understand this. You get used to the syntax and borrow checker in a day or two. It’s a non-issue.

use crate::List::{Cons, Nil};
use std::ops::Deref;

enum List {
    Cons(i32, Box<List>),
    Nil,
}

struct MyBox<T>(T);

impl<T> Deref for MyBox<T> {
    type Target = T;
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

impl<T> MyBox<T> {
    fn new(x: T) -> MyBox<T> {
        MyBox(x)
    }
}

#[derive(Debug)]
struct CustomSmartPointer {
    data: String,
}

impl Drop for CustomSmartPointer {
    fn drop(&mut self) {
        println!("Dropping CustomSmartPointer with data `{}`!", self.data);
    }
}

fn main() {
    let b = Box::new(5);
    println!("b = {}", b);

    let _list = Cons(1, Box::new(Cons(2, Box::new(Cons(3,Box::new(Nil))))));

    let x = 5;
    let y = MyBox::new(x);

    assert_eq!(5,x);
    assert_eq!(5, *y);

    let m = MyBox::new(String::from("Rust"));
    hello(&m);
    hello(m.deref());
    hello(m.deref().deref());
    hello(&(*m)[..]);
    hello(&(m.deref())[..]);
    hello(&(*(m.deref()))[..]);
    hello(&(*(m.deref())));
    hello((*(m.deref())).deref());

    // so many equivalent ways. I think I'm understanding what happens
    // at various stages though, and why deref coercion was added to
    // the language. Would cut down on arguing over which of these myriad
    // cases is "idomatic." Instead, let the compiler figure out if there's
    // a path to the desired end state (&str).

    // drop stuff below ...
    let _c = CustomSmartPointer {
        data: String::from("my stuff"),
    };
    let _d = CustomSmartPointer {

That doesn’t really excuse its behavior in the video though.

You’ve been blue pilled by null. Once over the hurdle, it’s very eloquent.

Null is ugly. Tony Hoare apology for inventing it should be enough reason to learn to do better.

.

Unix -> Linux -> Ferrix?

It’s people who know they will be irrelevant because they spent decades producing shit software

So the Linux kernel is shit software now? Just because it’s not written in the newest programming language? Kind of a hot take.

This is such a dumb take. For as much as I’d like to have a safer language in the kernel you need the current developers, the “big heads” at least because they have a lot of niche knowledge about their domains and how they implementation works (regardless of language) People shouldn’t take shit like this from the ext4 developer, but it doesn’t mean we should start vilifying all of them.

This guy’s concerns are real and valid but were expressed with the maturity of a lunatic child, but they are not all like this.

Nobody can maintan a fork of the linux kernel on their own or even with a team. It’s a HUGE task.

There already is rust in part of the linux kernel. It’s not a fork.

But I agree with your first statement, people are dumb as hell, me included lol

The sad thing is, there are other languages better at replacing C/C++ due to closer resemblance, except they’re rarely used due to lack of trendy technology that is being hyped in Rust. D lost a lot of ground due to its maintainers didn’t make it an “immutable by default” language at the time when functional programming paradigm was the next big thing in programming (which D can still do, as long as you’re not too fussy about using const everywhere).

Arch people tell you “I use arch BTW”

Rust people make PRs rewriting your code in rust.

Rust people are worse.

If Linux gets rewritten in Rust it will be a new kernel, not Linux. You can make new kernels, even in Rust but they aren’t Linux. You can advertise them at Linux conferences but you can’t force every Linux dev to work on your new Rust kernel.

Lemmy comment not mentioning the race of someone challenge (IMPOSSIBLE)

the guy speaking off camera in the linked 3min 30s of the video is Ted Ts’o, according to this report about the session.

Losing their jobs? Uh what?

Totally

I apologize if this is more nontechnical nonsense as Im not a coder, but if the projects are open source, cant he just read and translate the code?

From a developer standpoint you’re taking someone’s baby, cloning it into a language they don’t understand and deprecating the original. Worse, if you’re not actually interested in taking over the project you’ve now made it abandonware because the original developer lost heart and the person looking for commit counts on GitHub has moved on.

Obviously these extremes don’t always apply, but a lot of open source relies on people taking a personal interest. If you destroy that, you might just destroy the project.

They will write kernel in Ada

GNU isn’t punchy though; as soon as any punchy word get’s associated with them, people will use that word instead, and we’ll just get GNU/Thermite or GNU/Abson or something.

Maybe a pipe dream, but I would love to see RedoxOS get some traction. A rust based microkernel is a promising concept.

Its mainly a matter of stabilizing existing features in the language - there are rust modules in the linux kernel as of 6.1 but they have to be compiled with the nightly compiler.

Rust is a very slow moving , get it right the first time esque, project. Important and relatively fundamental stuff is currently and has been useable and 99% unchanging for years but hasnt been included in the mainline compiler.

Also certain libraries would be fantastic to have integrated into the standard library, like tokio, anyhow, thiserror, crossbeam, rayon, and serde. If that ever happens though itll be in like a decade.