I feel like some of the "what didn't go so well" sections were essentially because their rewrite was incomplete:
> 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.
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.
> I am talking about code that Miri cannot run, period: [some code that calls OpenSSL (mbedtls?) directly]
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.
> I am still chasing memory leaks. Our library offers a C API, something like this: [init()/release() C memory management pattern]
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.
The benefit of this rewrite in Rust would be about them not misusing memory internally inside the library. If that benefit isn't useful enough, then they shouldn't have done this rewrite.
> Cross-compilation does not always work
I've certainly run into issues with cross-compilation with Rust, but it is always so much easier than with C/C++.
> 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'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.
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.
> Unstable ABI
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?
And they actually can 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.
> 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.
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.
> I am talking about code that Miri cannot run, period: [some code that calls OpenSSL (mbedtls?) directly]
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.
> I am still chasing memory leaks. Our library offers a C API, something like this: [init()/release() C memory management pattern]
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.
The benefit of this rewrite in Rust would be about them not misusing memory internally inside the library. If that benefit isn't useful enough, then they shouldn't have done this rewrite.
> Cross-compilation does not always work
I've certainly run into issues with cross-compilation with Rust, but it is always so much easier than with C/C++.
> 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'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.
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.
> Unstable ABI
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?
And they actually can 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.