She mentions some challenges with Rust here:
>She mentions some challenges with Rust here:
Did not expect a 100 line macro to hack on placement new onto Rust.
I'm no C++ god, but I use placement new regularly. It's a standard, normal, typical feature in C++ development.
Also note that Rust's approach is to have many things that would be core/stdlib features in other languages implemented in community supported packages, where a consensus can form safely without risking shipping a language feature that might not serve the needs of the community, and the package can evolve on it's own schedule & not be tied to a compiler release schedule. On a cursory glance, there are numerous libraries providing this functionality: https://crates.io/search?q=placement%20new
I'm curious, are you a game developer or something? I've written less than 1k lines of C++, so I really don't know much about it, but I was under the impression this was a fairly niche feature.
(ETA: I peaked at your profile & saw it looks like you work at a brokerage - yeah, that makes sense why you'd care deeply about avoiding allocations, fair enough.)
I write C++ as my day job and while I wouldn't say I have to write placement new code often (I don't think I've used it once in the past year), it's definitely an essential tool for writing certain abstractions.
Skimming the source code for Arc<T>, it looks like T will likely be on the stack & copied to the heap, adding a copy C++ is probably able to avoid with it's strategy, but I'm not sure if the compiler is able to optimize that out or not.
Object lifetimes certainly play a role. The data structure used by the shared pointer can be kept alive by a weak pointer, but you want to call the destructor of the embedded object when no more shared pointers point to it. If you just used a templated member the auto generated cleanup code would try to call the destructor when the data structure itself is disposed. That is too late if weak_ptrs where involved and you can't call the destructor manually before that without causing loads of FUN as the automated cleanup will try to destroy the object again later. With placement new the member object can be created and destroyed as needed without the language imposing any assumptions on the objects lifetime.
The proposal has received a lot of new discussion in the past few days, as in addition to being wanted by kernel developers, it's a potential path to support dynamic dispatch in `async` code.
In practice Rust usually gets away with not having placement new and letting LLVM eliminate copies.
It might be a bit different across the community, but it's usually considered polite not to "dox" (however obvious in some cases) VTubers who have public personas under a different name. There are only so many Asahi developers though.
It shouldn't be a problem anyway, because someone else can contribute it, it's not like it's that one guy sending the pull requests who writes all of AMD's giant blob of GPU code.
At any rate, it's kind of their problem to worry about, if they even choose to worry about it. I think the work stands on its own merits.
I'd like to read more about what the Rust people are working on to help this effort, and if there's any particular nightly feature the kernel requires that will soon reach stable for everybody's benefit.
I don't believe there is a "Special interest group" but since the only comparable team to Rust for Linux would be a hypothetical "NT kernel with Rust" group, to some extent it's hard to argue with what they say they need when they come to Rust teams, e.g. library. Of course just because Rust for Linux wants X doesn't magically mean X is the top priority for the people working in that area, or even in some cases that Rust is going to ever do X. Sometimes the answer will be, as it has been for alloc, well, too bad then, make your own.
Linus really doesn't like implicit allocation, this is one thing he didn't like about C++. But Rust's own alloc has lots of implicit allocation. For example its String can be appended to, even using an operator like in Java or C++ which means the heap allocation just grows. But what if there's no more RAM? So, in Rust for Linux such features don't exist.
In both your desktop Rust and Rust for Linux, we can have a variable of type String, like &str it's UTF-8 encoded text, but unlike &str we can have mutable Strings. In desktop Rust you can just write my_string += " and then we ate a whole cake,"; and Rust will grow the String if necessary to fit on this extra text. But that's an implied allocation, so in Rust for Linux, this won't compile, the Rust for Linux String type doesn't have that += operator.
In any case, a Rust string is inherently a growable data structure. It has a capacity and a size. If the size exceeds the capacity, it is reallocated.
Does Rust for Linux have "mystring.push_str(" and then we ate a whole cake,")"? If yes, why is "+=" implicit and "push_str" is not?
Personally I would rather it didn't, but the use of + as a concatenate operator is widespread and I imagine if String didn't do this a popular BetterString would.
No, the Rust for Linux String doesn't have push_str(), see for yourself: https://rust-for-linux.github.io/docs/alloc/string/struct.St... that String also has no way to do infallible reserve(), and doesn't implement Write among other differences.