Linux 6.9 To Upgrade Rust Toolchain - Making More Features Stable

[bug77]

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.

You want field in traits because instead of understanding trait, you build a mental equivalent with what you know from other languages.

https://doc.rust-lang.org/book/ch10-02-traits.html

Traits: Defining Shared Behavior

This won't change no matter how much you complain.

[oleid]

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?

Well, usually it is just about "does the library depend on Tokio or not". If it does, it usually wants Tokio types and such. I guess in many cases it fails to compile, I presume?

[ssokolow]

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

I remember reading a blog post that laid out how, when you compare apples to apples, the Rust compiler is faster than the C++ compiler... Rust just makes it much easier and friendlier to do stuff at compile time rather than run time than C++ does, so you're normally not comparing apples to apples. (Rust's non-use of dynamic libraries is actually partly related to that. Nobody has figured out how to reconcile templates/generics with dynamic libraries, and Rust relies on generics for core things like Result<T, E> and Option<T>.)

[ssokolow]

Well, usually it is just about "does the library depend on Tokio or not". If it does, it usually wants Tokio types and such. I guess in many cases it fails to compile, I presume?

...and there are two things to keep in mind:

1. The alternative that you see in other languages like Go is "The same thing... but their Tokio equivalent is baked so deeply into the language that the state of things will never change"... in Rust, we actually can have situations like the kernel devs being interested in experimenting with writing a kernel-mode async executor so they can use async to reconcile mantainability and efficiency in places with a lot of potential for concurrency, like the NVMe driver.
2. Rust operates on a "release a minimum viable product" model. Rust's async support is incomplete and they've always intended to come back and extend the standard library API façades so things can depend on those rather than on tokio directly... they're just busier with more pressing concerns first, like completing async trait support while they collect data on what APIs the ecosystem actually uses.

[bug77]

...and there are two things to keep in mind:

1. The alternative that you see in other languages like Go is "The same thing... but their Tokio equivalent is baked so deeply into the language that the state of things will never change"... in Rust, we actually can have situations like the kernel devs being interested in experimenting with writing a kernel-mode async executor so they can use async to reconcile mantainability and efficiency in places with a lot of potential for concurrency, like the NVMe driver.
2. Rust operates on a "release a minimum viable product" model. Rust's async support is incomplete and they've always intended to come back and extend the standard library API façades so things can depend on those rather than on tokio directly... they're just busier with more pressing concerns first, like completing async trait support while they collect data on what APIs the ecosystem actually uses.

About #1: Go has a whole GC built into its runtime, adding an async runtime next to that is a no brainer. At the same time, Go isn't considering running on microcontrollers and such.
As usual, I say pick the right tool for the job and be thankful you have options.

[ssokolow]

About #1: Go has a whole GC built into its runtime, adding an async runtime next to that is a no brainer. At the same time, Go isn't considering running on microcontrollers and such.
As usual, I say pick the right tool for the job and be thankful you have options.

*nod* My point was more "At this point, you'd be getting Tokio for common-case userland use either way. Rust just gives you the option of using async in other contexts Tokio is unsuited for, like kernelspace or embedded."