There’s been plenty of interop options between C++ and just about anything for decades. If languages like D, that made it piss easy, weren’t gonna change people’s minds, nothing can. Ditching C++ is the only way forward.
I’m a bit surprised that it’s supposed to be this bad, given that Mozilla uses it in Firefox and there’s the whole CXX toolchain.
Granted, Rust was not designed from the ground up to be C+±like, but I’m really not sure that’s a good idea anyways.
Wanting bug-free programs without wanting functional programming paradigms is a bit like:
Of course, if we’re able to migrate a lot of old C++ codebases to a slightly better standard relatively easily, then that is still something…
Probably seems like a little thing but I found it quite annoying in practice, and there are other things like not being able to combine serde-derive and cxx FFI on the same struct.
Sounds like you’ll always have to do this little dance for any string you want to pass through, so I can definitely see how that could become quite annoying.
For not being able to combine serde-derive and cxx FFI on the same struct, there’s a simple trick that can be used for many such situations:
I gave C++ and D as an example. A language that for all intents and purposes is irrelevant despite being exactly what everyone wanted, something like Java/C#, but with no compromise and direct bindings to C/C++. And why I’m more apologetic to the idea of something more drastically different like Rust as opposed to another touched up clone of C.
Unfortunately, I don’t think D is good enough to prove your point. From your follow-up comment:
A language that for all intents and purposes is irrelevant despite being exactly what everyone wanted,
As someone who uses D, I can attest that it is not what everyone wanted; at least not yet. Despite all the great things in the language, the ergonomics around actually using it are mediocre at best: Several of its appealing features quickly turn it into a noisy language, error messages are often so obtuse as to be useless (especially with templates and contracts in play), and Phobos (the standard library) is practically made of paper cuts. Also, the only notable async support is a fragile mess, and garbage collection is too deeply embedded into both the stdlib and the ecosystem.
(To be fair, D could be vastly improved with better defaults and standard library. That might happen in time, as Walter and the other maintainers have shown interest, but it’s just wishful thinking for now.)
Also, D is an entirely different language from C++, and as such, would require code rewrites in order to bring safety to existing projects. It’s not really comparable to a C++ extension.
There’s been plenty of interop options between C++ and just about anything for decades. If languages like D, that made it piss easy, weren’t gonna change people’s minds, nothing can. Ditching C++ is the only way forward.
Interop between Rust and C++ is pretty bad actually - I can understand wanting to avoid that.
However I still agree. I can’t see opt-in mechanisms like this moving the needle.
I’m a bit surprised that it’s supposed to be this bad, given that Mozilla uses it in Firefox and there’s the whole CXX toolchain.
Granted, Rust was not designed from the ground up to be C+±like, but I’m really not sure that’s a good idea anyways.
Wanting bug-free programs without wanting functional programming paradigms is a bit like:
Of course, if we’re able to migrate a lot of old C++ codebases to a slightly better standard relatively easily, then that is still something…
The biggest issue is move constructors. Explanation here: https://cxx.rs/binding/cxxstring.html#restrictions
Probably seems like a little thing but I found it quite annoying in practice, and there are other things like not being able to combine serde-derive and cxx FFI on the same struct.
Sounds like you’ll always have to do this little dance for any string you want to pass through, so I can definitely see how that could become quite annoying.
For not being able to combine serde-derive and cxx FFI on the same struct, there’s a simple trick that can be used for many such situations:
struct CxxThingamabob { ... } #[derive(Serialize, Deserialize)] #[serde(transparent)] struct SerializableCxxThingamabob(CxxThingamabob);That just moves the Serde implementation to a different struct, so that you can choose which one you want by either wrapping or unwrapping it.
I gave C++ and D as an example. A language that for all intents and purposes is irrelevant despite being exactly what everyone wanted, something like Java/C#, but with no compromise and direct bindings to C/C++. And why I’m more apologetic to the idea of something more drastically different like Rust as opposed to another touched up clone of C.
Unfortunately, I don’t think D is good enough to prove your point. From your follow-up comment:
As someone who uses D, I can attest that it is not what everyone wanted; at least not yet. Despite all the great things in the language, the ergonomics around actually using it are mediocre at best: Several of its appealing features quickly turn it into a noisy language, error messages are often so obtuse as to be useless (especially with templates and contracts in play), and Phobos (the standard library) is practically made of paper cuts. Also, the only notable async support is a fragile mess, and garbage collection is too deeply embedded into both the stdlib and the ecosystem.
(To be fair, D could be vastly improved with better defaults and standard library. That might happen in time, as Walter and the other maintainers have shown interest, but it’s just wishful thinking for now.)
Also, D is an entirely different language from C++, and as such, would require code rewrites in order to bring safety to existing projects. It’s not really comparable to a C++ extension.