Linux 6.9 To Upgrade Rust Toolchain - Making More Features Stable

[KernelCrasher]

I very much like Rust, I think it is very nice way to structure programs with Result<T, E> and Option<T> and enums with variants (including variants that are structs).

But...

• the compiler is slow

The Rust compiler does much more than the simple translator from C or Pascal to machine code.

[intelfx]

public traits cannot have any async functions

I think that's going to be solved with RPITIT, and there are more QoL improvements in the pipeline. But the general async story in Rust is less than perfect, agreed.

traits can only have functions but not fields (why? is this because I should define getter/setter functions instead?)

Well, that's what you get when language explicitly decides to not open the inheritance can of worms.

I don't like the double colon :: syntax because it is ugly, and not needed, I think just a normal dot should be used instead.

For any syntax desision there'll be someone who disagrees. Ultimately it's not that important.

the compiler is slow

That is true. Well, again, that's what you get when a language decides to rely heavily on monomorphisation for its generics. I'd wish they did a Swift, but oh well.

if the input parameter is a reference, i.e. &foo, then when I match I must do match &foo, I can't do match foo, why?

I believe you can, you'll have to put the reference into your match arms. No?

[Daktyl198]

Is the compiler slow? I find large rust projects to compile fast enough for me, and I run it on a crappy Intel N3050

The compiler is slower than, say, a C compiler. But in the grand scheme of modern processors, it's not like it makes it take 10 minutes longer, more like a minute at most for large projects to do the checking before it goes into standard LLVM compile time. I compiled the entire COSMIC desktop and all of it's applications in just a few minutes on an old 3700x and that was something like 1800 modules to compile.

[ssokolow]

[LIST][*]traits can only have functions but not fields (why? is this because I should define getter/setter functions instead?)

Like most details in Rust with non-obvious reasons, it's because of what that would entail under the hood.

In this case, it's that, at best, it'd make things much more complex to specify when also supporting dynamic dispatch, for a convenience improvement that hasn't been demonstrated to be worthwhile enough to merit it.

In C++, you can do that because:

• they cram the dynamic dispatch stuff into your class whether or not a given location is using it, resulting in everyone having to be concerned with whether a struct or class is POD (Plain Old Data) or not because C++ has just enough of that GCed language "just make it work"-ness that you have to worry about it slipping in hidden struct fields to power the dynamic features you didn't realize you were requesting.
• They're willing to accept inefficiencies in how they implement inheritance that the Rust team don't want.

In GCed languages, you're already paying for a ton of Run-Time Type Information, so they just hang it off that infrastructure.

In Rust:

• A statically dispatched struct is just data, and its methods are just syntactic sugar for bare functions taking it as the first argument. Something like my_struct.foo() compiles to roughly the same thing as something like my_struct_foo(my_stuct_ptr) would in C.
• A trait object (dynamic dispatch) is a fat pointer that's basically an (object_instance, trait_vtable) tuple. The object_instance pointer is literally just the address of an opaque blob of data, identical to the data blob used in static dispatch, while the trait_vtable is the same memory address for every instance that resolves to that impl Trait for Struct. This ensures you only pay for dynamic dispatch when you ask for it. (i.e. In C++, dynamic dispatch is a property of the class/struct. In Rust, dynamic dispatch is a property of the reference to it.)
• The Rust philosophy is "make costs explicit", so Rust isn't exactly eager to implement trait fields via something like Python's @property decorator which hides function calls behind the member access (i.e. period) operator.

[Vorpal]

Michael ptr_metadata isnt stable (
https://github.com/rust-lang/rust/issues/81513), maybe something else allowed them to stop depending on that feature?

EDIT: Says further down: "Stop using the unstable 'ptr_metadata' feature by employing the now stable 'byte_sub' method to implement 'Arc::from_raw()'.". So that explains it.

[uid313]

I believe you can, you'll have to put the reference into your match arms. No?

I saw what I tried to do was match foo.kind, then it seems I have to do match &foo.kind with the ampersand.

[uid313]

• Public traits *can* have async functions, there's just caveats that are still being worked on: https://blog.rust-lang.org/2023/12/2...in-traits.html ... Think of async support in traits kinda like const generic support - it's something that takes *years* to fully implement and stabilize because it needs to be done very, very carefully.
• Why would traits need fields? In that case you use a struct. Analogy: Java interfaces (which are sorta like traits) can't have fields. Golang interfaces cannot have fields.
• The normal dot means something different in Rust syntax. Sounds like you're confusing two very different things.
• Libraries that use async are absolutely *not* tied to a specific runtime. If they are, they're not designed properly. It might be that they pull in tokio to use supporting functions to better compose and control async flow.
• All of the questions/concerns you've raised are already addressed in the Rust book and Rust async books: https://doc.rust-lang.org/book/ + https://rust-lang.github.io/async-book/

I want fields in traits because I have a dozen structs representing different message types which all need to have a "id" field. So I wanted all the structs to implement a trait to get the id field. I can have a get_id() function in the trait, but I cannot create a default implementation for it. I like Rust but sometimes it is tricky without inheritance. Maybe inheritance is overused and isn't always the best solution, but maybe sometimes inheritance isn't all that bad.

The dot is used to reach the functions on the struct, but to reach the associated functions I have to use the double-colon syntax. I would like to use the dot for both like in C#, Java and Python.

[oleid]

I want fields in traits because I have a dozen structs representing different message types which all need to have a "id" field. So I wanted all the structs to implement a trait to get the id field. I can have a get_id() function in the trait, but I cannot create a default implementation for it. .

In that case I'd write a simple macro to implement the trait for the fields that are common for all your structs.
It might be necessary to work with two traits here, one for the ID and one for the rest. The 2nd trait for the rest would require your type to implement the ID trait.

[AnAccount]

Problem with async runtime is library-specific, has nothing to do with the language. There are many runtime-independent crates. I am the author of one of them so I know.

Huge rust fan, will never touch C/C++ again if possible, since Rust is so much nicer. But with that said, I still think the Async runtime situation leaves a bit to desire. You write that it is possible to write runtime independent async libraries, but that is the same argument we laugh at regarding that it is possible to write safe C++ code. It is possible to do both these things, but does the language prevent you from doing the wrong thing? And I think that timers are one of these things that are incompatible between runtimes, but for me as a user there is nothing that really tells me that when I try to use a library. For me as a use, it is very difficult to know if a library is independent or not, unless they state it clearly in the README. Now, in practise this is not a very big problem, since most libraries are quite clear with what they support.

But the runtime situation is probably not a very big issue for kernel development. I don't expect them to do much async, and if so I assume they will use their own custom kernel runtime, and on top of that I also assume they will not pull in random libraries from crates.io but most likely write their own.

[mdedetrich]

Is the compiler slow? I find large rust projects to compile fast enough for me, and I run it on a crappy Intel N3050

Compared to mature C compilers it most definitely is but its also doing a lot more than C can do (i.e. verifying parts of your program) and considering how powerful computers are nowadays the tradeoff is definitely worth it.

C++ is also comparatively slow (maybe even moreso due to templating being a crazy beast)