3 ms·

> The only price to pay is give up objects There's other prices to pay, of course. Rust doesn't target as many systems as C++, for example. Adding Rust to a

> The only price to pay is give up objects There's other prices to pay, of course. Rust doesn't target as many systems as C++, for example. Adding Rust to a project means someone has to update your build/ci/cd/etc infrastructure, your development machines need rust installed and kept up-to-date, and your developers have to become familiar with Rust. There will also probably be pain points when crossing the C++ <-> Rust boundary (since you have to do so at mostly the C level) - you lose lifetime information, you have to convert data types back and forth, etc. These may or may not be show-stoppers, but there's certainly more than near-zero friction in running and maintaining a C++ code base with incremental pieces rewritten in Rust. (I'm a huge Rust fan, btw).

blub 8y ago
What's a nice way to call Rust from C++? If the answer is through a C interface then I am (still) disappointed.
- pjmlp 8y ago
  It is. RustConf 2018 - Embedding Rust in C/C++ https://www.youtube.com/watch?v=x9acx2zgx4Q https://www.youtube.com/watch?v=x9acx2zgx4Q
- bluejekyll 8y ago
  You can make decent wrappers in both languages that provide a similar feeling so that you have a good C++ or Rust API over C. But yes, out of the box, there aren’t simple ways of exposing native interfaces across the language boundaries.
  - jerf 8y ago
    It's worth pointing out there really isn't a such thing anyhow. We spent many decades with all our "cool, exotic" languages like Python and Perl and PHP and such just giving up and tying themselves to C semantics, so the C ABI could serve as a de-facto interchange format. But in what I think is a sign that the C dominance is finally starting to fade, more languages are getting away from that, and while they still need a C bridge, it's getting more and more isolated from the rest of the languages. The core problem is that the cross-language interface isn't just about "calling a function"; there's semantics around who owns what, who's responsible for deallocation, garbage collection, degrees of thread safety and memory boundaries, and on and on and on it goes. It is a bit of an illusion from the last several decades that there is any way for there to be a "generic cross-language interface", because under the hood everything was designed to either be "C memory semantics" or "C memory semantics plus whatever other stuff we can stick on that doesn't conflict with that". By contrast (and as the major exceptions to "everything is just C"), observe how "easy" it is for JVM-based or .Net languages to share objects, because the runtime environment makes almost all the hard decisions for you.

blub 8y ago

What's a nice way to call Rust from C++? If the answer is through a C interface then I am (still) disappointed.

pjmlp 8y ago
It is. RustConf 2018 - Embedding Rust in C/C++ https://www.youtube.com/watch?v=x9acx2zgx4Q https://www.youtube.com/watch?v=x9acx2zgx4Q
bluejekyll 8y ago
You can make decent wrappers in both languages that provide a similar feeling so that you have a good C++ or Rust API over C. But yes, out of the box, there aren’t simple ways of exposing native interfaces across the language boundaries.
- jerf 8y ago
  It's worth pointing out there really isn't a such thing anyhow. We spent many decades with all our "cool, exotic" languages like Python and Perl and PHP and such just giving up and tying themselves to C semantics, so the C ABI could serve as a de-facto interchange format. But in what I think is a sign that the C dominance is finally starting to fade, more languages are getting away from that, and while they still need a C bridge, it's getting more and more isolated from the rest of the languages. The core problem is that the cross-language interface isn't just about "calling a function"; there's semantics around who owns what, who's responsible for deallocation, garbage collection, degrees of thread safety and memory boundaries, and on and on and on it goes. It is a bit of an illusion from the last several decades that there is any way for there to be a "generic cross-language interface", because under the hood everything was designed to either be "C memory semantics" or "C memory semantics plus whatever other stuff we can stick on that doesn't conflict with that". By contrast (and as the major exceptions to "everything is just C"), observe how "easy" it is for JVM-based or .Net languages to share objects, because the runtime environment makes almost all the hard decisions for you.