> Do the semantics of the borrow checker play nicely with C projects, depending on architectures? And the other semantics of Rust?

I don't see why the borrow checker and other Rust semantics are relevant in this context. As the sibling comment stated, if you're writing Rust code that is intended to be consumed by C code you're going to be writing a C API, which almost certainly entails mapping Rust semantics to C semantics and vice-versa so what you expose is what other C code can understand (i.e., you're not exposing anything Rust-specific). Sure, that might require the calling C code to do some work on their end to uphold invariants, but that is not exactly an uncommon requirement when writing C in general.

> If the above quotes are accurate, how would it be consistent with what you wrote?

Well, first of all you're stripping context from the bit you quoted from me. That statement was contrasting Rust's C interop with languages with runtimes which require the consuming C code to be aware of the fact that they're calling into a different language and require additional boilerplate to do so - messing with refcounts in Python, JVM-specific types in Java, so on and so forth. In this context, the quotes you picked out are basically irrelevant as they are about entirely different topics.

But in any case, let's try to look at those quotes from the article anyways:

>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.

"Rust was designed to play well in C codebases" is not inconsistent with "Rust's C interop can be improved".

Unfortunately it's been hard to find exactly what Rust changes have been driven by this work, but at least based on the initial announcement of the hyper backend experiment [0] it seems that the improvements to Rust are less about the language's C interop and more about dealing with error handling/OOM. An important issue indeed, and one that is still being worked on, but distinct from language-level C interop nevertheless.

Put another way, there would be similar issues if someone tried to add a C backend which aborted on OOM as well. It's not "Rust doesn't play well with C", it's "this development style doesn't match the one we want/use". That is language-agnostic.

>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 can't say I understand your focus on this quote. There's no inconsistency between this and what I said because this quote says nothing about how well (or not) the Rust code works with the rest of the curl codebase. The quote would apply basically verbatim to C++/Zig/D as well and those have nearly seamless C interop.

>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.

Similar thing here.

> As for being designed for interop with C, I found this blog: <link> 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:

Zig does indeed have very nice interop with C. However, that's irrelevant in the context of this conversation - the fact that Zig (or other languages like C++ and D, for example) is better at C interop than Rust has literally zero bearing on whether Rust was designed for interop with C.

> Rust's FFI also relies on undefined behavior if this comment isn't outdated

I'm not sure the comment isn't outdated, but in any case I think the sibling comment addresses this better than I could.

This is one of those things where I suspect the current behavior is good enough given current manpower/resource constraints and would be reprioritized if it ever becomes an issue.

[0]: https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyp...