The Linux project seems to be treating those as the same as any C extensions they use, that is, they're just using them, even though they aren't yet stable. Folks are of course working on getting those things to be stable someday, but it's not considered a blocker for this stuff to have landed.
Another is the build infrastructure. Right now, you can only use Rust on platforms that the official Rust compiler compiles for, which is a lot narrower set than where Linux runs. The long-term solution for this are the various GCC Rust projects, but those are still ways out. Correspondingly, there are a lot of kernel subsystems where Rust is not welcome until those projects mature.
One tangential I've been wondering about for around a year is the implications of the autocxx problem for libraries.
Let's say I write a wrapper around a large, complex c/cpp codebase. It's far far beyond my ability to read the code and understand when UB could occur. It's beyond anybody to read through the whole codebase start to finish absent a serious budget. The maintainers have documented some soundness invariants, but from the tone you infer they're only interested in calling out what they see as likely significant unsoundness.
For some use cases it still makes sense to use this library from Rust. Nobody could write a wrapper and promise it sound without an infeasible amount of work.
It's useful if the wrapper signals the difference between "this is unsafe because you need to uphold this documented soundness invariant" and "this is unsafe because I can't promise there isn't an undocumented soundness variant the wrapper could violate".
But but but! That kind of distinction makes sense to people integrating large codebases from memory-unsafe languages. People who write different kinds of Rust rightly think "WTF are you talking about, a chance of unsound is unsound is unsound, and you can't be unsound without the user invoking unsafe".
Right now I think the best compromise is to have the entrypoint of the whole library be unsafe (i.e. the constructor of every type), but all the fns you subsequently use be safe. The safety docs of that fn says that you the caller is promising the soundness docs of the underlying c/cpp library are complete and accurate, and that's probably not true.
This
- Technically complies with the informal unsafe spec: You can't have unsoundness as a user without writing unsafe
- Is practically useful in cases where the benefit of a large existing c/cpp codebase means you want to accept a little unsoundness
- Let's people who think this whole thing sounds crazy because the point of Rust is memory safety sleep sound at night because they couldn't accidentally end up using this.
I think that spinning up a separate process is the only real way to properly contain a large C++ library wrt memory (un)safety. It can still be useful to wrap in Rust though, since it is more pleasant to write IPC code in Rust compared to C++.
Agree. I'm planning to run in wasm a few thousand line rust driver linked to the massive c lib and allow that code to draw to a framebuffer but not otherwise access anything.
At the same time, medium companies run this cpp lib in production in important contexts without that kind of protection. And I'm not that motivated to try and write marginally more reliable software than them for my hobby project.
True on the outset but you can partially control for it by e.g. implementing Future or Stream from the async runtime and have the implementor interact with the external resources. Then you can reshape unexpected or erroneous external state into Rust async errors, do retries, timeouts and whatnot.
I tried it, it helped. Doesn't solve everything for sure but I'll take any entropy decrease.
Agreed, however that kind of effort is already quite different from how it gets usually sold, and on distributed computing world and multi-processes scenarios for security isolation purposes, what I care about are mostly external resources.
Well, I suspect that for that to work properly we need an entirely new class of computing software, OS and maybe even hardware stack.
Everything we do nowadays with distributed computing is, at best, writing a good networked app and then praying that it works and that it doesn't hit its 50 potential error states.
12 comments
[ 3.1 ms ] story [ 42.5 ms ] threadLet's say I write a wrapper around a large, complex c/cpp codebase. It's far far beyond my ability to read the code and understand when UB could occur. It's beyond anybody to read through the whole codebase start to finish absent a serious budget. The maintainers have documented some soundness invariants, but from the tone you infer they're only interested in calling out what they see as likely significant unsoundness.
For some use cases it still makes sense to use this library from Rust. Nobody could write a wrapper and promise it sound without an infeasible amount of work.
It's useful if the wrapper signals the difference between "this is unsafe because you need to uphold this documented soundness invariant" and "this is unsafe because I can't promise there isn't an undocumented soundness variant the wrapper could violate".
But but but! That kind of distinction makes sense to people integrating large codebases from memory-unsafe languages. People who write different kinds of Rust rightly think "WTF are you talking about, a chance of unsound is unsound is unsound, and you can't be unsound without the user invoking unsafe".
Right now I think the best compromise is to have the entrypoint of the whole library be unsafe (i.e. the constructor of every type), but all the fns you subsequently use be safe. The safety docs of that fn says that you the caller is promising the soundness docs of the underlying c/cpp library are complete and accurate, and that's probably not true.
This
- Technically complies with the informal unsafe spec: You can't have unsoundness as a user without writing unsafe
- Is practically useful in cases where the benefit of a large existing c/cpp codebase means you want to accept a little unsoundness
- Let's people who think this whole thing sounds crazy because the point of Rust is memory safety sleep sound at night because they couldn't accidentally end up using this.
At the same time, medium companies run this cpp lib in production in important contexts without that kind of protection. And I'm not that motivated to try and write marginally more reliable software than them for my hobby project.
I tried it, it helped. Doesn't solve everything for sure but I'll take any entropy decrease.
Everything we do nowadays with distributed computing is, at best, writing a good networked app and then praying that it works and that it doesn't hit its 50 potential error states.