Not really.

The semantics as you cross the boundary are ill-defined. And you will pay dearly if the C library wants to own any of the resources (like an event loop).

And "unsafe" programming in Rust is really difficult to get right--possibly harder than C.

To be fair, these problems are not inherent to Rust--any language which tries to interface with C will have them.

>To be fair, these problems are not inherent to Rust--any language which tries to interface with C will have them.

Yes, including C.

I guess in that case, at least it's done by a C developer...

Incorrect.

Two C libraries interface just fine if library 1 handles ownership and library 2 (or your program) simply operates on the resulting things being passed around.

Rust, on the other hand, will go bananas and your life will be miserable. See: http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...

That 2019 blog post explains how, having made a whole series of mistakes, they're now going to rewrite everything in C and it'll go much better. The next blog post says they've abandoned the project instead.

To me, it seems like they'd lost motivation years previously and were increasingly flailing around for something that would spark the same joy as initial work on an exciting new project, and Rust has little to do with that.

Lots of crates exist which wrap popular C libraries, and they don't seem to run into the sort of misery you describe.

So the author tried very hard to provide a safe interface for things that are inherently unsafe and found it to be too much work. That’s similar but different to just calling C from Rust and living with unsafe code like you normally do in C.