I feel like some of the "what didn't go so well" sections were essentially because their rewrite was incomplete:<p>> <i>I am still chasing Undefined Behavior. Doing an incremental rewrite from C/C++ to Rust, we had to use a lot of raw pointers and unsafe{} blocks. And even when segregating these to the entry point of the library, they proved to be a big pain in the neck.</i><p>These sound like an artifact of the rewrite itself, and I suspect many of these unsafe blocks can be rewritten safely now that there is no C++ code left.<p>> <i>I am talking about code that Miri cannot run, period: [some code that calls OpenSSL (mbedtls?) directly]</i><p>This should be replaced by a safe OpenSSL (mbedtls?) wrapper, or if it wouldn't change the behavior of their library in incompatible ways, rustls.<p>> <i>I am still chasing memory leaks. Our library offers a C API, something like this: [init()/release() C memory management pattern]</i><p>Not sure what this has to do with Rust, though. Yes, if you're going to test your library using the exposed C API interface, your tests may have memory leaks. And yes, if your users are expected to use the library using the C API, they will have to be just as careful about memory as they were before.<p>The benefit of this rewrite in Rust would be about them not misusing memory <i>internally</i> inside the library. If that benefit isn't useful enough, then they shouldn't have done this rewrite.<p>> <i>Cross-compilation does not always work</i><p>I've certainly run into issues with cross-compilation with Rust, but it is always <i>so</i> much easier than with C/C++.<p>> <i>Cbindgen does not always work. [...] Every time, I thought of dumping cbindgen and writing all of the C prototypes by hand. I think it would have been simpler in the end.</i><p>I'm skeptical of the idea that an automated tool is going to generate something that you'll want to use as your public API. I would probably use cbindgen to get a first draft of the API, modify and clean up the output, and use that as the first version, and then manually add/change things from there as the API changes.<p>I don't want to silently, accidentally change the API (or worse, ABI) of my library because a code generator changed behavior in a subtle way based on either me upgrading it, or me changing my code in a seemingly-innocuous way.<p>> <i>Unstable ABI</i><p>This is a bummer, but consider that they are not exposing a Rust API to their customers: they're exposing a C API. Why would the expect to be able to expose Rust types through the API?<p>And they actually <i>can</i> do this: while it is correct that standard Rust types could have a different layout depending on what version of rustc is used to build it, that doesn't actually matter for a pre-built, distributed binary, as long as access to those types from the outside code (that is, through the C API) is done only through accessors/functions and never through direct struct member access. Sure, that requires some overhead, but I would argue that you should never expose struct/object internals in your public API anyway.