5 ms·

> Sources requested. I don't even know why you'd claim this. I think the original quote is most favorably interpreted in comparison to other languages with a r

> Sources requested. I don't even know why you'd claim this. I think the original quote is most favorably interpreted in comparison to other languages with a runtime that require external C code to know its calling into another language (for example, Python with manual calls to increment/decrement refcounts). One of the reasons Rust dropped its original runtime was specifically to allow it to "pretend" to be regular C code - if you build it to be consumed as a C library external C code can use it and be none the wiser that it is calling into another language. There's also other affordances for playing well with C (extern "C", no_mangle, #[repr(C)], etc.) In that sense, Rust is indeed specifically designed to play well in C codebases as the rest of the C code can basically pretend it's only working with C code. > Another C project has not had good experiences with all interop attempts, pulling the plug on interop with one Rust library, while keeping support for two other Rust libraries. I'm not sure that example is particularly relevant. At least at a high level it seems the primary reason the hyper backend was removed was because of a lack of interest rather than some innate issue with Rust interop. If anything, the continued existence of the other two Rust backends would seem to hint that Rust interop is not really that much of an issue.

gauntletstricky 2y ago
>In that sense, Rust is indeed specifically designed to play well in C codebases as the rest of the C code can basically pretend it's only working with C code. Do the semantics of the borrow checker play nicely with C projects, depending on architectures? And the other semantics of Rust? https://www.reddit.com/r/rust/comments/90s2no/rust_c_interop/ https://www.reddit.com/r/rust/comments/90s2no/rust_c_interop... >When we started this, even rust itself was not ready and over this time rust has improved and it is today a better language and it is better prepared to offer something like this. For us or for other projects. >It takes someone who is interested and good at both languages to dig in, understand the architectures, the challenges and the protocols to drive this all the way through. >I am not against revisiting the topic and the idea of providing alternative backends for HTTP/1 in the future, but I think we should proceed a little different next time. We also have a better internal architecture now to build on than what we had in 2020 when this attempt started. If the above quotes are accurate, how would it be consistent with what you wrote? >In that sense, Rust is indeed specifically designed to play well in C codebases as the rest of the C code can basically pretend it's only working with C code. This quote especially: >It takes someone who is interested and good at both languages to dig in, (...) As for being designed for interop with C, I found this blog: https://ludwigabap.bearblog.dev/zig-vs-rust-at-work-the-choice-we-made/ https://ludwigabap.bearblog.dev/zig-vs-rust-at-work-the-choi... Where they chose Zig instead of Rust, and mentioned the importance of interop, and that Zig also is a C compiler. Something that is claimed on Zig's website as well: >Incrementally improve your C/C++/Zig codebase. > >Use Zig as a zero-dependency, drop-in C/C++ compiler that supports cross-compilation out-of-the-box. I know barely anything about Zig, so I don't know the veracity of this, however. Rust's FFI also relies on undefined behavior if this comment isn't outdated https://github.com/rust-lang/rust/pull/59625#issuecomment-482906628 https://github.com/rust-lang/rust/pull/59625#issuecomment-48... https://github.com/rust-lang/rust/blob/master/library/core/src/ffi/va_list.rs#L290 https://github.com/rust-lang/rust/blob/master/library/core/s... . Might not be an issue as long as the implementation is only used with LLVM and LLVM doesn't change.
- kmeisthax 2y ago
  Borrow checker semantics only apply to Rust, not C. When you write the bindings you're also responsible for mapping the C code's preconditions and postconditions to something the borrow checker can understand. For example, the semi-common pattern of reference-counted objects sitting behind opaque pointers would call for a transparent wrapper type around a bare pointer, with appropriate implementations of Drop and Clone to decrement and increment the reference count, and inlined wrapper methods to call any C methods associated with the object. You can, of course, call C directly without worrying about writing any of those types; but now you have to write a bunch of unsafe blocks to call those functions all over your non-binding code. This isn't great. 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. To be clear, both approaches have the same runtime performance, the only implication is on whether or not Rust will be able to verify correctness of the code. The unsoundness you mentioned specifically refers to taking variadic arguments when called from C, which are a bit of a hack even before you talk about Rust interop. In ISO C, you have to call va_end in the current function, with the current stack frame. Rust's compiler doesn't guarantee that Drop implementations are inlined, so your code might wind up calling something else that calls va_end, which isn't good enough. However, this is a moot point, because LLVM/clang treat va_end as a no-op and thus can't get screwed up by Rust not following ISO C spec. I doubt LLVM is going to add optimizer passes specifically to break code that uses va_end wrong if they aren't even using it themselves. If they did, rustc could be modified specifically to support forcibly inlined Drop, just for std::ffi, if needs be. It wouldn't break any code to add this. 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. 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. [0] Or at least the ones willing to entertain a multi-language Linux [1] I have no clue if that compiler ships a va_end that depends on being called in the current stack frame or not.
  - gauntletstricky 2y ago
    >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++.

gauntletstricky 2y ago

>In that sense, Rust is indeed specifically designed to play well in C codebases as the rest of the C code can basically pretend it's only working with C code. Do the semantics of the borrow checker play nicely with C projects, depending on architectures? And the other semantics of Rust? https://www.reddit.com/r/rust/comments/90s2no/rust_c_interop/ https://www.reddit.com/r/rust/comments/90s2no/rust_c_interop... >When we started this, even rust itself was not ready and over this time rust has improved and it is today a better language and it is better prepared to offer something like this. For us or for other projects. >It takes someone who is interested and good at both languages to dig in, understand the architectures, the challenges and the protocols to drive this all the way through. >I am not against revisiting the topic and the idea of providing alternative backends for HTTP/1 in the future, but I think we should proceed a little different next time. We also have a better internal architecture now to build on than what we had in 2020 when this attempt started. If the above quotes are accurate, how would it be consistent with what you wrote? >In that sense, Rust is indeed specifically designed to play well in C codebases as the rest of the C code can basically pretend it's only working with C code. This quote especially: >It takes someone who is interested and good at both languages to dig in, (...) As for being designed for interop with C, I found this blog: https://ludwigabap.bearblog.dev/zig-vs-rust-at-work-the-choice-we-made/ https://ludwigabap.bearblog.dev/zig-vs-rust-at-work-the-choi... Where they chose Zig instead of Rust, and mentioned the importance of interop, and that Zig also is a C compiler. Something that is claimed on Zig's website as well: >Incrementally improve your C/C++/Zig codebase. > >Use Zig as a zero-dependency, drop-in C/C++ compiler that supports cross-compilation out-of-the-box. I know barely anything about Zig, so I don't know the veracity of this, however. Rust's FFI also relies on undefined behavior if this comment isn't outdated https://github.com/rust-lang/rust/pull/59625#issuecomment-482906628 https://github.com/rust-lang/rust/pull/59625#issuecomment-48... https://github.com/rust-lang/rust/blob/master/library/core/src/ffi/va_list.rs#L290 https://github.com/rust-lang/rust/blob/master/library/core/s... . Might not be an issue as long as the implementation is only used with LLVM and LLVM doesn't change.

kmeisthax 2y ago
Borrow checker semantics only apply to Rust, not C. When you write the bindings you're also responsible for mapping the C code's preconditions and postconditions to something the borrow checker can understand. For example, the semi-common pattern of reference-counted objects sitting behind opaque pointers would call for a transparent wrapper type around a bare pointer, with appropriate implementations of Drop and Clone to decrement and increment the reference count, and inlined wrapper methods to call any C methods associated with the object. You can, of course, call C directly without worrying about writing any of those types; but now you have to write a bunch of unsafe blocks to call those functions all over your non-binding code. This isn't great. 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. To be clear, both approaches have the same runtime performance, the only implication is on whether or not Rust will be able to verify correctness of the code. The unsoundness you mentioned specifically refers to taking variadic arguments when called from C, which are a bit of a hack even before you talk about Rust interop. In ISO C, you have to call va_end in the current function, with the current stack frame. Rust's compiler doesn't guarantee that Drop implementations are inlined, so your code might wind up calling something else that calls va_end, which isn't good enough. However, this is a moot point, because LLVM/clang treat va_end as a no-op and thus can't get screwed up by Rust not following ISO C spec. I doubt LLVM is going to add optimizer passes specifically to break code that uses va_end wrong if they aren't even using it themselves. If they did, rustc could be modified specifically to support forcibly inlined Drop, just for std::ffi, if needs be. It wouldn't break any code to add this. 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. 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. [0] Or at least the ones willing to entertain a multi-language Linux [1] I have no clue if that compiler ships a va_end that depends on being called in the current stack frame or not.
- gauntletstricky 2y ago
  >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++.