Linux 6.9 To Upgrade Rust Toolchain - Making More Features Stable

[phoronix]

Phoronix: Linux 6.9 To Upgrade Rust Toolchain - Making More Features Stable

All of the Rust feature patches have already been submitted in a pull request to Linus Torvalds ahead of the upcoming Linux 6.9 merge window...

https://www.phoronix.com/news/Linux-6.9-Rust-Upgrade

[uid313]

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

• public traits cannot have any async functions
• traits can only have functions but not fields (why? is this because I should define getter/setter functions instead?)
• 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.
• the compiler is slow
• 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?
• libraries that use async are dependent on a specific async runtime (like tokio) and are not interoperable with another async runtime.

[samcday]

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

• public traits cannot have any async functions
• traits can only have functions but not fields (why? is this because I should define getter/setter functions instead?)
• 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.
• the compiler is slow
• 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?
• libraries that use async are dependent on a specific async runtime (like tokio) and are not interoperable with another async runtime.

• 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/

[byteabit]

uid313 (lol there is someone with your name, but "sucks" added to it, it pops up when I @ your name)
They are working on async everywhere, with traits as well. So this public traits with async should be solved soon I hope (if I understand correctly). And yes, not having an official integrated async runtime has its highs and downsides, especially bad because not all runtimes are compatible to each others. I think its the design philosophy to not have data in the traits? Because these are not classes and makes composition of traits easier.

[bachchain]

• public traits cannot have any async functions
• 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?

Those two are just factually incorrect

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=350a57bd2bc34c1a71a3b00b79cf9f2f

[byteabit]

Those two are just factually incorrect

Ah, good to see async fn in traits is already implemented 2 month ago: https://blog.rust-lang.org/2023/12/2...in-traits.html

[deltragon]

Note that, as of 1.76, ptr_metadata is still unstable: https://doc.rust-lang.org/stable/std....metadata.html

However, what changed is that byte_sub got stabilized: https://doc.rust-lang.org/stable/std...hod.byte_sub-1 which allows the kernel to drop the dependency on ptr_metadata.

[Quackdoc]

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

• public traits cannot have any async functions
• traits can only have functions but not fields (why? is this because I should define getter/setter functions instead?)
• 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.
• the compiler is slow
• 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?
• libraries that use async are dependent on a specific async runtime (like tokio) and are not interoperable with another async runtime.

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

[dremon_nl]

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

• public traits cannot have any async functions
• traits can only have functions but not fields (why? is this because I should define getter/setter functions instead?)
• 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.
• the compiler is slow
• 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?
• libraries that use async are dependent on a specific async runtime (like tokio) and are not interoperable with another async runtime.

Async trait methods were added recently.

Trait fields aren't possible because they can't be implemented for enums for example.

Double colon makes the language syntax nonambiguous and simpler to understand in the code for humans.

Compiler is actually very fast, considering that it builds all dependent crates from sources.

The statement about matching reference is not true.

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.

[bug77]

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

• public traits cannot have any async functions
• traits can only have functions but not fields (why? is this because I should define getter/setter functions instead?)
• 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.
• the compiler is slow
• 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?
• libraries that use async are dependent on a specific async runtime (like tokio) and are not interoperable with another async runtime.

Compiler is slow because it needs to reason about your code. The whole point of Rust, you know.
As for the async runtime, this was discussed around the time async was implemented: you can't have that in the standard library, it would bloat executables too much. Maybe this will be revisited once std-aware-cargo is figured out. But I haven't heard of progress about that in a while...
That said, while the implementations are different, I highly doubt they're not compatible among them, considering they implement the same traits. (The traits themselves do live in the standard runtime.)