4 ms·

The alternative is to write new stuff in Rust and link as usual. And get the many other benefits beside lifetimes. Specially if, as you say "safe C++ is very ve

The alternative is to write new stuff in Rust and link as usual. And get the many other benefits beside lifetimes. Specially if, as you say "safe C++ is very very high on my list of \"important things\"". The safety Rust offers makes you a better programmer, because in C++ your focus is partially (mostly?) tied up to provide guarantees Rust provides for free. I presume you can't imagine the breath of fresh air that is. The only price to pay is give up objects, and that may be a good thing.

jjnoakes 8y ago
> 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.
pjmlp 8y ago
That works for CLI applications on desktop platforms, however there are many domains where C++ is used where the Rust tooling is not even available. Embedded, GPGPU, certified compilers, HPC, Fintech, OS drivers, hardware design,... So any improvement that brings more safety to C++ is welcome.
- bluejekyll 8y ago
  As an aside, Rust is making significant strides in many of those areas. It hasn’t had the longevity of C++ which already has all of that, but it is getting better. Things take time and energy.
  - pjmlp 8y ago
    Agreed, that is why I like Rust and still argue for C++ at the same time. It took decades for C++ to reach where it is, so any improvement to handle C++ caveats for current codebases is great. In the meantime Rust, or any other safer systems languages, can keep improving and slowly start replacing C++ on new projects. Same applies to some kind of Safe C, Checked C or whatever finally manages to win the hearts of UNIX kernel devs.
  - Koshkin 8y ago
    ... while C++ already has taken space and enjoys momentum.
blub 8y ago
You got it the wrong way around: C++ makes you a better programmer, in the same way that juggling chainsaws makes you a better juggler than merely juggling oranges.
- bluejekyll 8y ago
  That’s an extremely interesting analogy. But I think you have something wrong in it. You don’t become a better juggler by juggling chainsaws, you must be a very good juggler before you juggle with chainsaws. Otherwise you cut your hands off. C++ I guess is as close to juggling chainsaws as you can get in software, maybe C is even closer, but it means that you’re constantly doing the equivalent of cutting off your hands. Luckily that’s only allegorically.
  - pjmlp 8y ago
    C++ is chainsaws with grips, while C is double edged chainsaws. :) Ideally we would get chainsaws with protective cover, but it takes years to get there.
    - estebank 8y ago
      I believe this analogy works all too well: C is a chainsaw that has a smaller chainsaw coming out of the opposite side on a pseudo-deterministic basis (UB). You're "fine" as long as you know how to avoid it.
logicchains 8y ago
>The safety Rust offers makes you a better programmer, because in C++ your focus is partially (mostly?) tied up to provide guarantees Rust provides for free. Unfortunately there are still some very nice safety benefits that C++ provides but Rust doesn't: those relying on integer template parameters. C++ for instance allows checking at compile time that matrices with sizes known at compile time can be multiplied together, while in Rust this would be a runtime error. Even if Rust got integer template parameters, it's still a long way away from supporting variadic template parameters, which allow creating tensors of arbitrary dimension and for checking operations on them at compile time. This is not just a safety issue but also a performance issue, as libraries like xtensor(https://github.com/QuantStack/xtensor https://github.com/QuantStack/xtensor) allow stack-allocating such arrays, but (correct me if I'm wrong, this may be outdate) there's no way to implement a stack-allocated tensor of arbitrary dimensionality in Rust. Expression templates, an important technique for improving linear algebra performance by performing optimsation of computation graphs at compile time (kind of like Haskell rewrite rules, but implemented entirely as libraries) are also harder to use in Rust.
- steveklabnik 8y ago
  We've accepted an RFC for this, and hopefully will have an implementation on nightly by the end of the year, with stabilization sometime next year, incidentally.
  - pjmlp 8y ago
    So can we hope to see something like Eigen in Rust?
    - steveklabnik 8y ago
      Hopefully! The RFC I'm referring to[1] is the first step; this isn't my area of specialty, so I can't say if it alone is enough to replicate it. But if not, it's the first step towards it. The end goal is first-class support to allow people to build excellent libraries like Eigen. 1: https://github.com/rust-lang/rfcs/blob/master/text/2000-const-generics.md https://github.com/rust-lang/rfcs/blob/master/text/2000-cons...

jjnoakes 8y ago

> 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.

pjmlp 8y ago

That works for CLI applications on desktop platforms, however there are many domains where C++ is used where the Rust tooling is not even available. Embedded, GPGPU, certified compilers, HPC, Fintech, OS drivers, hardware design,... So any improvement that brings more safety to C++ is welcome.

bluejekyll 8y ago
As an aside, Rust is making significant strides in many of those areas. It hasn’t had the longevity of C++ which already has all of that, but it is getting better. Things take time and energy.
- pjmlp 8y ago
  Agreed, that is why I like Rust and still argue for C++ at the same time. It took decades for C++ to reach where it is, so any improvement to handle C++ caveats for current codebases is great. In the meantime Rust, or any other safer systems languages, can keep improving and slowly start replacing C++ on new projects. Same applies to some kind of Safe C, Checked C or whatever finally manages to win the hearts of UNIX kernel devs.
- Koshkin 8y ago
  ... while C++ already has taken space and enjoys momentum.

blub 8y ago

You got it the wrong way around: C++ makes you a better programmer, in the same way that juggling chainsaws makes you a better juggler than merely juggling oranges.

bluejekyll 8y ago
That’s an extremely interesting analogy. But I think you have something wrong in it. You don’t become a better juggler by juggling chainsaws, you must be a very good juggler before you juggle with chainsaws. Otherwise you cut your hands off. C++ I guess is as close to juggling chainsaws as you can get in software, maybe C is even closer, but it means that you’re constantly doing the equivalent of cutting off your hands. Luckily that’s only allegorically.
- pjmlp 8y ago
  C++ is chainsaws with grips, while C is double edged chainsaws. :) Ideally we would get chainsaws with protective cover, but it takes years to get there.
  - estebank 8y ago
    I believe this analogy works all too well: C is a chainsaw that has a smaller chainsaw coming out of the opposite side on a pseudo-deterministic basis (UB). You're "fine" as long as you know how to avoid it.

logicchains 8y ago

>The safety Rust offers makes you a better programmer, because in C++ your focus is partially (mostly?) tied up to provide guarantees Rust provides for free. Unfortunately there are still some very nice safety benefits that C++ provides but Rust doesn't: those relying on integer template parameters. C++ for instance allows checking at compile time that matrices with sizes known at compile time can be multiplied together, while in Rust this would be a runtime error. Even if Rust got integer template parameters, it's still a long way away from supporting variadic template parameters, which allow creating tensors of arbitrary dimension and for checking operations on them at compile time. This is not just a safety issue but also a performance issue, as libraries like xtensor(https://github.com/QuantStack/xtensor https://github.com/QuantStack/xtensor) allow stack-allocating such arrays, but (correct me if I'm wrong, this may be outdate) there's no way to implement a stack-allocated tensor of arbitrary dimensionality in Rust. Expression templates, an important technique for improving linear algebra performance by performing optimsation of computation graphs at compile time (kind of like Haskell rewrite rules, but implemented entirely as libraries) are also harder to use in Rust.

steveklabnik 8y ago
We've accepted an RFC for this, and hopefully will have an implementation on nightly by the end of the year, with stabilization sometime next year, incidentally.
- pjmlp 8y ago
  So can we hope to see something like Eigen in Rust?
  - steveklabnik 8y ago
    Hopefully! The RFC I'm referring to[1] is the first step; this isn't my area of specialty, so I can't say if it alone is enough to replicate it. But if not, it's the first step towards it. The end goal is first-class support to allow people to build excellent libraries like Eigen. 1: https://github.com/rust-lang/rfcs/blob/master/text/2000-const-generics.md https://github.com/rust-lang/rfcs/blob/master/text/2000-cons...