5 ms·

> C++ is long in the tooth C++ is mature, there's a difference. It's definitely not "long in the tooth" as it still has plenty of modern features & niceties an

> C++ is long in the tooth C++ is mature, there's a difference. It's definitely not "long in the tooth" as it still has plenty of modern features & niceties and is getting more all the time. > C++ is really struggling with its identity now that Rust is on the scene C++'s identity struggles have nothing to do with Rust whatsoever. It's struggling to balance ABI & historical compatibility with moving the language forward, that's about it. And that's just something many mature languages face at some point (see Python3 for example). Beyond that struggle of supporting legacy code, there's no identity crisis with C++ at all. > the best argument for C++ is just that it has a larger ecosystem (which says more about how old C++ is than how good it is as a language). That argument becomes less convincing with each passing day. It's still an incredibly convincing argument. Rust has decent C interop, but it's not especially seamless to do safely. But Rust's interop with C++ is rather complicated. So if you have any C++ dependencies, you're almost certainly far better off to just go with C++. Even if you just have C dependencies and someone else hasn't yet made a crate for it, you might still be better of with C++. Particularly since many of the Rust crates that bind to popular C & C++ libraries are not owned or maintained by the library in question. So you're entering into a bit of a sketchy maintenance world. And there's already been churn & abandonware here, for example the various projects (including one from Mozilla/Servo!) to bind to libpng that were then later all abandoned, and you're supposed to migrate to rewrites of PNG support in Rust like LodePNG. This is not ignorable churn & risk. It can be fun, and if it's a hobby project absolutely go for it. But if you're on the clock to ship & maintain something, it's a risk you must consider quite seriously.

zahllos 5y ago
I mostly agree. C++ is mature, has standards and a whole array of production ready libraries. If I wanted to build a production cross platform GUI app today and not use electron (vomit) I would likely use Qt for it. Rust has nothing that is quite ready yet to offer there. However, my overall view is that Rust is the right direction. If I had to improve C++, it would look a lot like Rust: move bounds checking and ownership to the compiler not the template compiler, remove classes, introduce traits and make C++ have concepts that don't require me to type every punctuation symbol on my keyboard to use, const by default. Getting the compiler to do some of this checking by default is exactly what I want. If we can have an Ada/Spark style subset via Kani, also done at compile time to check correctness, even better. > It's still an incredibly convincing argument. Rust has decent C interop, but it's not especially seamless to do safely. I would make this statement slightly stronger. If you interop with C code and there are bugs in C code, all bets are off. You don't get any magical protection because your main routine is written in Rust. Cross-language safety, e.g. C++/Javascript, for example, is a very difficult problem. Here's a discussion of C++ and Rust https://dl.acm.org/doi/fullHtml/10.1145/3485832.3485903 https://dl.acm.org/doi/fullHtml/10.1145/3485832.3485903 If you want a tl;dr of that paper, it is that memory corruptions in C or C++ code sharing the address space of safe Rust code can make safe Rust code unsafe too. There have been plenty of attempts to study for example the interactions between browser C++ and the various runtimes a browser hosts. The compact you are making with the Rust compiler when you type 'unsafe' is that you are saying you have verified the correctness of that code: that it is in fact already safe and the compiler should not (probably because it cannot) check it. The same is true of any FFI code you use. However, this is not how many people actually _use_ Rust. Here for example is a 2 year old unfixed segfault in a Rust crate caused by interfacing with non-Rust code: https://rustsec.org/advisories/RUSTSEC-2020-0159 https://rustsec.org/advisories/RUSTSEC-2020-0159. This a) demonstrates the issue and b) demonstrates that random crates pulled off crates.io can contain safety issues for 2+ years with no fix.
- hulitu 5y ago
  > I mostly agree. C++ is mature, has standards and a whole array of production ready libraries. If I wanted to build a production cross platform GUI app today and not use electron (vomit) I would likely use Qt for it. C++ is mature ? Every couple of years a new C++ standard emerges which breakes old programs. Qt ? Which version ? 3 ? 4 ? 5 ? 6 ?
  - ncmncm 5y ago
    Each is more mature than the previous one. But, they do not break old code. Some old code, though, started out broken, and C++ is not called upon to fix it.
andrewaylett 5y ago
An "unsafe" set of calls from Rust to C are still no less unsafe than calling C from other C or from C++. The biggest difference is in programmer expectation, which is why it's so unfortunate when a "safe" wrapper has bugs. Rust can't fix bugs in the underlying C library either, of course. That's one place where Mozilla's recent foray into FFI via compiling to WASM then compiling the WASM to native code is very interesting to me.
- kllrnohj 5y ago
  But making that unsafe Rust block safe to call from safe Rust isn't the most trivial of things to do. Conforming to all the safety requirements is still a thing to deal with, otherwise you contaminate all your safe Rust code. It's not an unreasonable burden for what you get in return, but it is still a burden.
  - stouset 5y ago
    That burden exists if you're calling into it from C, it's just implicit. At least Rust gives you the tools to write safe wrappers. Once you've done that consumers of your library don't have to tiptoe around the possibility of unsafe behavior.
    - adwn 5y ago
      > That burden exists if you're calling into it from C, it's just implicit. That point is absolutely crucial. It's not just implicit, it's also often undocumented. Recently, I tried to call LLVM's ORC2 JIT functions from two threads concurrently – an interface which was designed to be thread-safe [1]. And yet, actually doing that resulted in non-deterministic crashes and failed assertions. Guess it wasn't thread-safe after all... None of the types or function prototypes gave any indication that they weren't thread-safe, not to mention the documentation. And that's an extremely popular open-source project! The reality for most other C++ code looks even worse. [1] https://llvm.org/docs/ORCv2.html#features https://llvm.org/docs/ORCv2.html#features
      - 5y ago
boznz 5y ago
> C++ is long in the tooth Welcome to the world of any language that the cool guys dont use anymore :-)
notriddle 5y ago
> C++ is mature, there's a difference. It's definitely not "long in the tooth" as it still has plenty of modern features & niceties and is getting more all the time. C is mature. C++ drinks and sleeps around, but that hardly makes it mature.

zahllos 5y ago

I mostly agree. C++ is mature, has standards and a whole array of production ready libraries. If I wanted to build a production cross platform GUI app today and not use electron (vomit) I would likely use Qt for it. Rust has nothing that is quite ready yet to offer there. However, my overall view is that Rust is the right direction. If I had to improve C++, it would look a lot like Rust: move bounds checking and ownership to the compiler not the template compiler, remove classes, introduce traits and make C++ have concepts that don't require me to type every punctuation symbol on my keyboard to use, const by default. Getting the compiler to do some of this checking by default is exactly what I want. If we can have an Ada/Spark style subset via Kani, also done at compile time to check correctness, even better. > It's still an incredibly convincing argument. Rust has decent C interop, but it's not especially seamless to do safely. I would make this statement slightly stronger. If you interop with C code and there are bugs in C code, all bets are off. You don't get any magical protection because your main routine is written in Rust. Cross-language safety, e.g. C++/Javascript, for example, is a very difficult problem. Here's a discussion of C++ and Rust https://dl.acm.org/doi/fullHtml/10.1145/3485832.3485903 https://dl.acm.org/doi/fullHtml/10.1145/3485832.3485903 If you want a tl;dr of that paper, it is that memory corruptions in C or C++ code sharing the address space of safe Rust code can make safe Rust code unsafe too. There have been plenty of attempts to study for example the interactions between browser C++ and the various runtimes a browser hosts. The compact you are making with the Rust compiler when you type 'unsafe' is that you are saying you have verified the correctness of that code: that it is in fact already safe and the compiler should not (probably because it cannot) check it. The same is true of any FFI code you use. However, this is not how many people actually _use_ Rust. Here for example is a 2 year old unfixed segfault in a Rust crate caused by interfacing with non-Rust code: https://rustsec.org/advisories/RUSTSEC-2020-0159 https://rustsec.org/advisories/RUSTSEC-2020-0159. This a) demonstrates the issue and b) demonstrates that random crates pulled off crates.io can contain safety issues for 2+ years with no fix.

hulitu 5y ago
> I mostly agree. C++ is mature, has standards and a whole array of production ready libraries. If I wanted to build a production cross platform GUI app today and not use electron (vomit) I would likely use Qt for it. C++ is mature ? Every couple of years a new C++ standard emerges which breakes old programs. Qt ? Which version ? 3 ? 4 ? 5 ? 6 ?
- ncmncm 5y ago
  Each is more mature than the previous one. But, they do not break old code. Some old code, though, started out broken, and C++ is not called upon to fix it.

andrewaylett 5y ago

An "unsafe" set of calls from Rust to C are still no less unsafe than calling C from other C or from C++. The biggest difference is in programmer expectation, which is why it's so unfortunate when a "safe" wrapper has bugs. Rust can't fix bugs in the underlying C library either, of course. That's one place where Mozilla's recent foray into FFI via compiling to WASM then compiling the WASM to native code is very interesting to me.

kllrnohj 5y ago
But making that unsafe Rust block safe to call from safe Rust isn't the most trivial of things to do. Conforming to all the safety requirements is still a thing to deal with, otherwise you contaminate all your safe Rust code. It's not an unreasonable burden for what you get in return, but it is still a burden.
- stouset 5y ago
  That burden exists if you're calling into it from C, it's just implicit. At least Rust gives you the tools to write safe wrappers. Once you've done that consumers of your library don't have to tiptoe around the possibility of unsafe behavior.
  - adwn 5y ago
    > That burden exists if you're calling into it from C, it's just implicit. That point is absolutely crucial. It's not just implicit, it's also often undocumented. Recently, I tried to call LLVM's ORC2 JIT functions from two threads concurrently – an interface which was designed to be thread-safe [1]. And yet, actually doing that resulted in non-deterministic crashes and failed assertions. Guess it wasn't thread-safe after all... None of the types or function prototypes gave any indication that they weren't thread-safe, not to mention the documentation. And that's an extremely popular open-source project! The reality for most other C++ code looks even worse. [1] https://llvm.org/docs/ORCv2.html#features https://llvm.org/docs/ORCv2.html#features
    - 5y ago

boznz 5y ago

> C++ is long in the tooth Welcome to the world of any language that the cool guys dont use anymore :-)

notriddle 5y ago

> C++ is mature, there's a difference. It's definitely not "long in the tooth" as it still has plenty of modern features & niceties and is getting more all the time. C is mature. C++ drinks and sleeps around, but that hardly makes it mature.