Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming Rust language features for kernel development

lwn.net

Post reply on HN
Print view View original

171–180 of 240 posts

Re: Upcoming Rust language features for kernel development

#171

Post by ameliaquining »

misnome wrote: post #164
ameliaquining wrote: post #145

Earlier quoted context omitted.

Note that the community has somewhat soured on that particular proposal and it's probably not going to be enacted in its current form, precisely because it's so complicated. ( https://rust-lang.github.io/rust-project-goals/2025h2/ergono... ) Complexity is not necessarily an automatic dealbreaker for a Rust language proposal—lots of Rust features are complicated because they solve problems that don't admit simple solu…

I wonder if the block-level `clone(var_a, var_b)` was considered. It’s a bit verbose but very explicit and much better than the current situation.

Do you mean something like this? https://github.com/rust-lang/rfcs/issues/2407

Re: Upcoming Rust language features for kernel development

#172

Post by School-Cotton »

GeorgeTirebiter wrote: post #166
School-Cotton wrote: post #129

Earlier quoted context omitted.

Rust is more complex than C, yes, but as someone who has used both professionally, it is not even close to being as complex as C++. In fact it is closer in complexity to C than to C++.

Perhaps you can help guide a C expert but C++ avoider (and super-avoider of Rust, so far): If C is 1 in complexity, where does C++ and Rust fall. By 'complexity' here I mean: the ability to keep the Entire Language in your head at the same time. C, although it does have complex corners, is -- mostly -- not overly complicated. (As you can probably tell, I prefer assembly, because it is the least complicated. You can b…

If C is 1 and C++ is 100 I would say Rust is like 25.

If your favorite language is assembly and C is too high-level for you then you are probably going to dislike Rust (and Java, Python, and every other modern language).

Re: Upcoming Rust language features for kernel development

#173

Post by School-Cotton »

William_BB wrote: post #149
School-Cotton wrote: post #130

Earlier quoted context omitted.

> What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me? Well, pretty close to that, actually! Rust will statically prevent you from accessing the same data from different threads concurrently without using a lock or atomic. > what's preventing me from using C++ atomics to achieve the same thing You might forget?

The first comment is the definition of a data race, not preventing race conditions. And data races are trivial (sure, no static prevention in C++)

> data races are trivial

Imagine this C++ code:

  class Foo {
  // ...
  public:
    void frobFoo();
  };
Now, is it okay to call `frobFoo` from multiple threads at once? Maybe, maybe not -- if it's not documented (or if you don't trust the documentation), you will have to read the entire implementation to answer that.

Now imagine this Rust code:

  struct Foo {
  // ...
  }

  impl Foo {
    fn frobFoo(&mut self) {
      // ...
    }
  }
Now, is `frobFoo` okay to call from multiple threads at once? No, and the language will automatically make it impossible to do so.

If we had `&self` instead of `&mut self`, then it might be okay, you can discover whether it's okay by pure local reasoning (looking at the traits implemented by Foo, not the implementation), and if it's not then the language will again automatically prevent you from doing so (and also prevent the function from doing anything that would make it unsafe).

Re: Upcoming Rust language features for kernel development

#174

Post by jstimpfle »

meisel wrote: post #119
bobajeff wrote: post #100

Looking at the rust rfc for the lightweight clones feature [1]. It took me a while to sort of understand it. Once I did I was excited for the feature but after awhile I was once again struck by the observation that rust is a very complex language to learn. To me as someone who's not learned either it looks like all the concepts and features of 'true' modern C++ (as opposed to C + a few extra features) spliced with th…

In my experience, C++ is a much more complicated language. The 8 ways to initialize something, the 5 types of values (xvalues etc.), inconsistent formatting conventions, inconsistent naming conventions, the rule of 5, exceptions, always remembering to check `this != other` when doing a move assignment operator, perfect forwarding, SFINAE, workarounds for not having a great equivalent to traits, etc. . Part of knowing…

Why check this != other? I've seen this once before in a codebase and concluded it was unnecessary.

Asking as someone whose life became much easier after opting not do anything of the above and just write C in C++ ;-)

Re: Upcoming Rust language features for kernel development

#175

Post by jstimpfle »

kstrauser wrote: post #162
ameliaquining wrote: post #145

Earlier quoted context omitted.

Note that the community has somewhat soured on that particular proposal and it's probably not going to be enacted in its current form, precisely because it's so complicated. ( https://rust-lang.github.io/rust-project-goals/2025h2/ergono... ) Complexity is not necessarily an automatic dealbreaker for a Rust language proposal—lots of Rust features are complicated because they solve problems that don't admit simple solu…

As a side note, this might just be a me thing, but I distinguish between "complex" and "complicated". Certain things have an inherently complexity. Stripped to their essence, they're still going to have a lot of moving parts. It's just their nature. However, you can also add complication on top of something that makes it more complex than it needs to be to perform its function. Think "complication" in the watchmaker'…

> Complexity is fine. Sometimes we're working on complex problems without simple, straightforward, correct solutions.

Often the best way to proceed is to just solve a simpler problem :)

Re: Upcoming Rust language features for kernel development

#176

Post by Anonbrit »

a-dub wrote: post #66
dmm wrote: post #49

Earlier quoted context omitted.

The gpu driver for Apple silicon is Rust and the author stated it would have been much more difficult to implement in C. It isn't upstreamed yet. """ Normally, when you write a brand new kernel driver as complicated as this one, trying to go from simple demo apps to a full desktop with multiple apps using the GPU concurrently ends up triggering all sorts of race conditions, memory leaks, use-after-free issues, and al…

> Torvalds seems to disagree with you. i don't really care for mindless appeals to authority. make your own arguments and defend them or don't bother. this gpu driver looks pretty cool though. looks like there's much more to the rust compatibility layer in the asahi tree and it is pretty cool that they were able to ship so quickly. i'd be curious how kernel rust compares to user space rust with respect to bloat. (use…

So rather than pointing to experts who're in the best position to know, you'd prefer bad rephrasing and airchair experts? Do you 'do your own research' too?

Re: Upcoming Rust language features for kernel development

#177

Post by 0x457 »

mamcx wrote: post #112
pjmlp wrote: post #10

Earlier quoted context omitted.

Only if those userspace applications are headless, Rust exceling at GUIs is a bit of a strech.

> Rust exceling at GUIs is a bit of a strech. BTW, this happens to almost all languages. Which ACTUAL good GUIs toolkits exist ? And which ACTUAL languages HAVE good integration or implementation of them? A good GUI kit AND integration is a bigger task than do a Os or a RDBMS. (And neither are many good languages for RDBMS)

Depends on your definition of good.

I think Swift (and even ObjC) is perfect for AppKit & UIKit. I think those frameworks are pretty good and I like using them. Languages have great integration, Swift literally made around them. Those toolkits have great integrations with the macOS.

I find C# a pretty nice language for GUI, I assume it has good (maybe not great) integration with at least one of MS GUI toolkits.

I find Rust good for GUI, but right now story is meh. Wrapper style frameworks always suffer from Rust not being whatever it wraps. Pure Rust framework miss a lot of features compared to wrapper frameworks.

Re: Upcoming Rust language features for kernel development

#178

Post by foota »

bobajeff wrote: post #100

Looking at the rust rfc for the lightweight clones feature [1]. It took me a while to sort of understand it. Once I did I was excited for the feature but after awhile I was once again struck by the observation that rust is a very complex language to learn. To me as someone who's not learned either it looks like all the concepts and features of 'true' modern C++ (as opposed to C + a few extra features) spliced with th…

Fwiw C++ has the exact same problem with moving/referencing into closures, see "Lambda capture" in https://en.cppreference.com/w/cpp/language/lambda.html.

Re: Upcoming Rust language features for kernel development

#179

Post by jaggederest »

tialaramex wrote: post #114
gpm wrote: post #101

Earlier quoted context omitted.

> rustlang mutability is also a type system construct? Yes > I.e. it assumes that all other code is Rust for the purpose of those checks? Not exactly, it merely assumes that you upheld the documented invariants when you wrote code to call/be-called-from other languages. For example that if I have a `extern "C" fn foo(x: &mut i32)` that - x points to a properly aligned properly allocated i32 (not to null, not to the m…

Also we can (in 2024 Edition) say we're vouching for an FFI function as safe to call, avoiding the need for a thin safe Rust wrapper which just passes through. We do still need the unsafe keyword to introduce the FFI function name, but by marking it safe all the actual callers don't care it wasn't written in Rust. This is fairly narrow, often C functions for example aren't actually safe, for example they take a point…

Also "safe" and "unsafe" have very specific meanings, not the more widely used meanings. It's not inherently dangerous to call unsafe code that is well written, it's really more a statement about who is taking responsibility for the behavior, the writer or the compiler.

I like the term "checked" and "unchecked" better but not enough to actually lobby to change them, and as a term of art they're fine.

Re: Upcoming Rust language features for kernel development

#180

Post by DaanDeMeyer »

aw1621107 wrote: post #85
Foxboron wrote: post #46

Earlier quoted context omitted.

> C interop is excellent and has been for years. Only if you primarily work with `cargo` and want to interact with C from Rust. The other way around has far less support and `rustc` does not standardize the object generation. This is actively preventing projects like `systemd` to adopt Rust into their project as an example. https://github.com/systemd/systemd/pull/19598

> Only if you primarily work with `cargo` and want to interact with C from Rust. In what way(s) does Rust's C interop depend on cargo? > The other way around has far less support and `rustc` does not standardize the object generation. I believe in this context the understanding is that you're going to be using `extern "C"` and/or `#[repr(C)]` in your Rust code, which gives you a plain C interface. I think attempting…

https://github.com/rust-lang/rust/issues/73632 needs to be addressed and then integrated into meson before systemd could consider adopting rust.
Post reply on HN