|
>In fact, that's basically the underlying argument surrounding R4L right now: the Rust people want to write nice Rust bindings that let the borrow checker do the work, while the C people[0] want Rust to just call C directly. But the bindings still require expertise in both languages to write, don't they? And knowledge of both codebases? And I haven't followed the specifics of the mailing list debate closely, but couldn't the nice bindings be copied or vendored into each Rust driver or something? I could be wrong, and it wouldn't be neat at all, and be a lot of bloat, but would enable having bindings. Some people argued the Rust code could be maintained out-of-tree, like some other projects were, even though it would take extra effort and also probably require tooling and processes. >In other words, it doesn't matter unless you're trying to make Rust code link with, say, stuff compiled by ancient C compilers like Metrowerks CodeWarrior[1] or something; and that stuff makes use of varargs. I did mention that it might not be an issue in practice, given some assumptions. However, if LLVM changes, or if for instance the Rust standard library is reused or copied over to GCC Rust, then the code would need to be changed. For GCC Rust, I wonder if part or all of the standard library could be forked, to have a GCC specific Rust standard library implementation, similar to what happens with C++'s standard library. >As for Zig, I haven't used it. I trust that it also has good interop facilities. But that doesn't matter since we're talking about Rust for Linux, not Zig for Linux. Sorry, but it does matter, since claiming that a language like Rust has good C interop of course leads to relative comparisons with other languages in similar spaces and how well they do relative to Rust. And if the promises by Zig holds, and the experience people talk about with Zig holds, then Zig appears to have a substantially better track record in regards to C interop than Rust. Which isn't surprising, since Zig is a less advanced and more primitive language than Rust, and while that has drawbacks, it can also have benefits, possibly like in this case with having much better C interop than Rust. In the same vein that the interop between Rust and C is likely way better than (unless confined to the C subset) the interop between Rust and C++. |