4 ms·

Thanks for the thorough details. That really helped my mental model of the topic. > ...some experimental features of Rust and its standard library that the cod

Thanks for the thorough details. That really helped my mental model of the topic. > ...some experimental features of Rust and its standard library that the code relies on. In my work I've experienced this, which can cause a sort of inversion where usage of experimental (or non-documented) features become so relied upon that I lose most control over how the experiment might resolve (ie. sorry, now it must find its way into main). Any concerns of the same kind of thing?

steveklabnik 2y ago
You're welcome. > Any concerns of the same kind of thing? Here's the canonical list: https://github.com/Rust-for-Linux/linux/issues/2 https://github.com/Rust-for-Linux/linux/issues/2 There's a lot, and I don't know the status of many of them, personally. But I don't see anything there that I know is not gonna work out, like for example, they aren't using specialization. Most of it feels like very nuts and bolts codegen options and similar things. That said, back in August, the Rust Project announced their goals for the second half of this year: https://blog.rust-lang.org/2024/08/12/Project-goals.html https://blog.rust-lang.org/2024/08/12/Project-goals.html They say that they're committed to getting this stuff done, and in particular: https://rust-lang.github.io/rust-project-goals/2024h2/rfl_stable.html#the-next-six-months https://rust-lang.github.io/rust-project-goals/2024h2/rfl_st... > Closing these issues gets us within striking distance of being able to build the RFL codebase on stable Rust. So, things sound good, in my mind.