12 ms·

Does the case for C++ in 2020 still exist? Rust and Go are much simpler to learn, can do everything that C++ can and have sane, simple and clean build systems/p

Does the case for C++ in 2020 still exist? Rust and Go are much simpler to learn, can do everything that C++ can and have sane, simple and clean build systems/package managers, not to mention async/await concurrency in the former and channels in the latter.

ur-whale 6y ago
> can do everything that C++ can Don't know about Rust, but for go: . can't match C++ on speed . doesn't (yet, AFAIK) have generics.
- ben-schaaf 6y ago
  Go also can't call any C libraries without massive overhead (at least not the reference implementation), nor run without a runtime. Go isn't really an alternative to C/C++/rust and it's not meant to be.
  - adrianN 6y ago
    Every programming language is, to different degrees, a replacement for every other programming language. Whether Go is a replacement for C++ or not depends on what you want to do. For a lot of use cases where you might choose C++, Go would be fine too.
    - stouset 6y ago
      I think GP’s point is that the overlap of domains that C++ is well-suited for and that go is well-suited for isn’t particularly large. Go was at least originally touted as a C++ replacement, but to be honest, that story hasn’t really panned out in practice.
      - pjmlp 6y ago
        Depends, https://www.f-secure.com/en/consulting/foundry https://www.f-secure.com/en/consulting/foundry
        stouset 6y ago
        With all due respect, I said the overlap wasn't particularly large. Not that it was entirely nonexistent.
  - pjmlp 6y ago
    Depends, while I am not big fan of Go, not everyone thinks that way, https://github.com/f-secure-foundry/tamago https://github.com/f-secure-foundry/tamago https://labs.f-secure.com/blog/tamago/ https://labs.f-secure.com/blog/tamago/ https://www.f-secure.com/en/consulting/foundry https://www.f-secure.com/en/consulting/foundry
dgellow 6y ago
Anything related to graphics or game programming has very few reasons to switch to something else than C++ (talking about the engines, not the scripting part).
- pjmlp 6y ago
  And for the scripting part something like .NET or Python rules, and will hardly change given current industry adoption.
turbinerneiter 6y ago
I think if you are on a green field and do not rely on specific i.e. libraries that are not there yet in Rust, I would have a hard time finding good reasons to use C++ over Rust. Mainly I guess if you have really good C++ programmers who are not interested in Rust. If you are not on a green field, stuff gets complicated. If you have a really good Rust programmer on the team, that is willing to take care of the language interop it can work well, if you have a bunch of Rust learners, you might blow up.
steerablesafe 6y ago
> can do everything that C++ can There are still areas where C++ is more expressive than both rust and go. AFAIK rust just recently got the capability to work with const generics and compile time evaluation. Lack of overloading (besides operators) in Rust is a double edged sword. Overloading allows for very expressive C++ code in the expense of awful error messages when it doesn't work out. C++'s concurrency story is continuously improving, but I'm not qualified to compare here. C++20's coroutines will be quite powerful. And there is one area where Rust and go can't compete: interacting with existing C++ code, including templates. There is a lot of that already. Having said that I keep a close eye on rust, it can certainly replace C++ in certain areas, possibly all areas in the future. But it can't replace it overnight, considering that there are millions of lines of _maintained_ C++ code out there. Not go though, that's like comparing apples to oranges.
- bluejekyll 6y ago
  I think this is probably the most important reason you list: interacting with existing C++ code, including templates. I wonder if we could ever get direct Rust to C++ FFI. There are ways around it of course, by dropping down to C FFI in both languages.
  - cptroot 6y ago
    It's important to remember that C++ doesn't define an ABI, so you'd have to focus on specific compilers' ABIs.
    - bluejekyll 6y ago
      For some reason I thought C++ had gotten a stable ABI? Not sure why (I’ve been out of C++ dev for years).
      - pornel 6y ago
        C++ has a policy of not making changes that would break anyone's ABI, but still doesn't have an official one. https://cor3ntin.github.io/posts/abi/ https://cor3ntin.github.io/posts/abi/
saurik 6y ago
FWIW, C++ has actually had stable async/await (I have been shipping a production product compiled to numerous platforms now for a year built with C++ coroutines) since before Rust finished theirs (and from what I so far know about Rust's, I like C++'s better, though I admit I don't know enough enough about what Rust did). C++ also frankly has a much better cross-platform build system story, with more extensible and hookable builds (the ability to do header injection on library dependencies with #include_next is epic)... I have so many bugs filed against cargo and rustc with respect to even basic cross-compile scenarios it isn't funny anymore :/. (I mean, cargo doesn't even get reproducible builds for cross-compiled binaries correct, though at least I was able to figure out a super awkward workaround for that where I give it a "rustc wrapper" and then run a filter on the command line arguments to strip the host-specific cargo metadata.) Some of us also think Rust made the wrong call on not supporting exceptions (if you want to use "monadic error handling" but you don't actually support defining monads, something seriously broken happened). C++ also has faster serial build times than Rust and fundamentally better support for parallel and incremental compilation than Rust (due to its support for prototypes and translation units; I ship my builds off to AWS lambda and expect to get linear speedup on -j1000 now that Amazon supports EFS mounts). <- So like, while I might agree that Rust's build system is "simple and clean", the reality is that computers aren't and so it is a fundamental mistake to make such a rigid build system :/. Rust is also still lacking in some key type system features, such as being able to template over values (which lets you create compile-time safe buffer types), which is a frustrating tradeoff against Rust's feature of lifetimes (which is absolutely a good thing, but isn't actually a source of issues in my code vs. buffer handling: what I really want is even dependent types... if Rust had at least gone for full linear types it would sell me much more quickly, as dealing with those situations is currently miserable in both languages and I know I could use such a facility to prevent the vast majority of the issues I actually run into in my code with respect to asynchronous cross-computer behavior). C++'s obviously-trivial compatibility with the massive ecosystem of C/C++ libraries is also useful. And like, while I totally appreciate the reasons object oriented programming can suck, for GUI programming it is still an incredibly common paradigm that C++ supports but is directly supported by neither Rust nor Go (which I haven't complained about at all in this comment, but mostly because I consider it a competitor to Python, not C++).
- 6y ago
cmrdporcupine 6y ago
You may have a team of experienced C++ developers and libraries of C++ code to interface with. I think one make a good argument for Rust, but you will also have a harder time sourcing developers and ramping up to speed. It's still novel, despite maturing rapidly. There are many many many high quality C++ libraries out there, and the modern C++ language is, for me, decently pleasant to work with, once you pick your style and set of constraints. Also, I really don't want to go around on this argument _again_, but I don't think Go is a serious competitor for C++ for the systems level programming where C++ dominates. Go is not the language for writing OS kernels, drivers, embedded code, etc. Nor do I think a garbage collected system is appropriate for hard real time systems of most kinds. I think what we have here in this discussion is another classic case of HN having a bit of a blindspot for anything that isn't web / web services or mobile app development. For many embedded systems developers for example it's a challenge just to get them to consider C++ over C, let alone something like Rust.
- yahyaheee 6y ago
  The c++ library argument is funny to me because it’s so incredibly difficult to import external projects in c++. This is where Rust is going to eat their lunch.
  - pjmlp 6y ago
    Had C++ standed still, yes. Except that now there is vcpkg, conan, prefab (on Android) and contrary to cargo,they support binary libraries, meaning I don't have to build the world every time I start a new project.
    - yahyaheee 6y ago
      C++ has had ages to solve this problem, vcpkg and conan are still a ways away from the simplicity of cargo. Doesn't support binary libraries? I don't really care considering everything else I get, I'm sure they'll support that in the future.
      - 6y ago
pjmlp 6y ago
Plenty, let me see. Although it is a polyglot target environment, CUDA hardware is designed for optimal support of C++ semantics. C++ is used for device drivers on Apple and Google's OSes. Swift and Rust depend on LLVM, written in C++. Unreal, Unity, CryEngine, Godot have C++ at their core. AUTOSAR safety standard for cars is based on C++14. UWP and DirectX are heavily based in C++. Tensorflow and PyTorch depend on C++. And plenty of other endless examples. Sure you can try to make do with Rust or Go, but be prepared to code like we used to program in C++ 30 years ago in regards of eco-system, IDE support and wealth of existing libraries.
- cmrdporcupine 6y ago
  Yep, and consider the chromium code base, or at least V8 which is embedded in all sorts of projects. C++. Yes, you could use a Rust wrapper, but it would not be pleasant. There's a bunch of other examples of this kind of thing. Additionally, if you work at one of the FAANGs (or many other large established companies) there's good chance you are working on an existing C++ base, with existing C++ build tools, with a good C++ style guide, and with plenty of other competent C++ engineers. Rust is not of the endorsed/established languages at Google. (And no, Go isn't frankly used as much at Google as people seem to think it is, though its use is increasing).
- nilkn 6y ago
  > be prepared to code like we used to program in C++ 30 years ago in regards of eco-system, IDE support and wealth of existing libraries. That's a bit of an extreme statement that needs some significant qualifications. This might be true if you are pushing for Rust or Go in one of the domains you mentioned, like professional game development. It would be fairly absurd for a studio to seriously try to switch to Rust in some of these areas. That said, if you're largely working on greenfield projects that don't rely on an existing C++ ecosystem, the situation almost gets inverted. For instance, C++ still doesn't have any kind of standardized package manager in 2020. There are a thousand little paper cuts in C++ that are hard to justify if you don't have to interface with an existing ecosystem or target a specialized environment that only it is well-suited for.
ganfortran 6y ago
The last few strongholds I see with C++ is probably game development. To crack into gaming industry, C++ is still a must-have skill. But TBH, I really don't want to use C++ if the circumstance allows. The language spec is just so overtly complex that feels self-defeating, it is harder and harder to justify use it in the first place.
fulafel 6y ago
That's a pretty low threshold to pass, obviously it's not doing to die overnight in 2020. C++ will continue its steady decline in mindshare but the user count will stay high, countered by the growth of the programmer population.
rvz 6y ago
Well I still can't create a mature cross-platform GUI app in either Go or Rust and Qt seems to be the first class option for that in the C++ world. Looking at some of the solutions for both Go and Rust, its either immature bindings to wrap around C or C++ for the same thing (the best you would get is GTK+) which are unmaintained and less stable / usable to what you would get with Qt5 with C++. I still keep seeing lots of cross-platform closed and open-source GUI apps still taking the Qt route.
jasode 6y ago
>Does the case for C++ in 2020 still exist? Rust and Go are much simpler to learn, can do everything that C++ can There are 2 levels of comparisons: - (1) language syntax : the "they're both Turing Complete" so whatever one can do, the other can do and because Rust is newer, it has nicer syntax. E.g. plain Rust syntax already has "ownership pointers" by default so doesn't require typing ugly verbose syntax such as "unique_ptr<T>". - (2) ecosystem and dependencies : In 2020, C++ and not Rust is still the primary API for things like NVIDIA CUDA, Unreal game engine, Qt GUI, and the ARM Allinea developer tools[1] for compiling code for the new Neoverse chips (e.g. latest AWS Graviton2 ARM servers). Sure, one could write wrappers in Rust for all those things but doing so will be going against the grain and now you're yak shaving your tools instead of building business value. If I had a brand new startup today, I'd use Rust as much as I could but there'd still be 25% to 50% new C++ code because deep learning (e.g. CUDA) is C++ not Rust. [1] https://www.arm.com/products/development-tools/server-and-hpc/allinea-studio https://www.arm.com/products/development-tools/server-and-hp...
Kenji 6y ago
> Does the case for C++ in 2020 still exist? No. Only if you are working with legacy code or large C++ libraries (like e.g. Qt). Rust is better than C++ in every single aspect.
rkangel 6y ago
We mostly use C rather than C++, but the same two big reasons get in the way of using Rust for everything: * Compiler support * Availability of suitable engineers Context - I work for the Wireless Division of Cambridge Consultants (Cambridge, UK). We build comms technology for our clients for basically anything you can think of - satphone, telecomms infrastructure, bluetooth headphones etc. This means that a lot of the software we right runs on an embedded target - that might be a microcontroller or it might be Linux. And importantly - often when we've designed something, our clients will carry on the maintenance and ongoing development. We have to take the long view - if we choose C/C++ we can guarantee that a compiler will exist for whatever hardware target they choose for the next generation of the product (or even the current generation - architecture swaps often happen at the cost reduction stage). Rust support is improving but can I guarantee that there will be a compiler available for some niche processor, or even the Xilinx Zynq target I'm using at the moment? And then when we hand over the code, we have to explain to the client that it's written in a language that none of their existing software engineers know, and if they advertise for people they may or may not be able to find them. All that said, we are pushing to use more suitable languages for our work. Using C/C++ for anything where security is important is beginning to look irresponsible, the above issues don't always apply and that combined with improved embedded support, more name recognition for Rust and ever more enlightened clients means that it's going to be an easier sell for more and more projects. But not all of them, not now. Actually it turns out that it's easier to sell Elixir as an alternative to some of our C development. My current project is a Linux target, microprocessor support is not important and the challenges it has are exactly what Erlang is designed to solve. I'd also suggest it's easier to incrementally teach the client Elixir than Rust. We'll keep pushing Rust though, and we'll get there eventually.
- thenewwazoo 6y ago
  I have experienced this horrible chicken-and-egg problem firsthand. I worked at Zipcar building the control boxes used for rentals and the fit for Rust was obvious and compelling, but was squashed by management because it was "too hard to hire" and "the language is underdeveloped". While those things are true, to fix them someone has to just do it. Instead, they fired me and now I make twice the money doing SRE work again at a FAANG.
quietbritishjim 6y ago
> Rust and Go are much simpler to learn I don't think this is true. I say that even though I would be deliriously happy if Rust replaced C++ in most situations it's currently used. Yes, learning the whole of Rust, including any/all dark corners (no doubt it has a few) is easier than learning the whole of C++ including all its dark corners (it certainly has many!). But getting a basic working knowledge of both is not too different... except for Rust's ownership system. I realise that the ownership system is one of Rust's main benefits, but that doesn't change the reality that it's a significant obstacle for many decent developers. I actually wish it were possible to use Rust in an "unsafe everywhere" mode where you could ignore the ownership stuff. (Maybe this is already possible with liberal use of the "unsafe" keyword, but it is at least socially unacceptable.) Of course it wouldn't be right for every project but it would still be a huge improvement over C++ while being much more accessible than fully safe Rust.
- steveklabnik 6y ago
  It's not possible, because unsafe does not turn anything off; unsafe is a superset of safe.
  - quietbritishjim 6y ago
    But if I use unsafe everywhere then couldn't I pass around raw pointers everywhere instead of references to avoid the lifetime checking? (Try to contain your horror! :-) )
    - steveklabnik 6y ago
      Only if you write the entire universe; you're going to want to call functions that accept references, and then you're stuck. > (Try to contain your horror! :-) ) Ha! Nah, no horror there. It is interesting to think about, for sure.
      - quietbritishjim 6y ago
        But I thought you could cast a raw pointer to a reference with "as" in an unsafe block? Obviously that makes it possible for you to create multiple mutable references, or a mutable reference at the same time as an immutable reference, which is undefined behaviour, but undefined behaviour was always going to be the risk of this idea. Also, even if you had a compiler switch to make "unsafe" implicit everywhere, your code is going to be littered with a lot of casts. (Obviously I'm not a Rust expert, which is why my comments are in the form of questions.)
dragontamer 6y ago
> Does the case for C++ in 2020 still exist? Are there C libraries you want to remain (nearly) source-compatible with while using classes, templates, and other more modern programming features?
Communitivity 6y ago
If you are supporting Windows or Linux, and are supporting the x86 platform, then for me the only reasons to use C++ over Rust are for compatibility with existing code/libraries, or lack of Rust expertise on the team and no time to learn Rust. If you are working in an embedded environment Rust is still very capable, but the tooling for Rust does not seem at the level of the embedded tooling for C and C++. You can still use Rust for embedded, and there are success stories to be found in the links below. [1] https://www.rust-lang.org/what/embedded https://www.rust-lang.org/what/embedded [2] https://rust-embedded.github.io/book/ https://rust-embedded.github.io/book/ [3] https://github.com/rust-embedded/awesome-embedded-rust https://github.com/rust-embedded/awesome-embedded-rust [4] https://github.com/rust-embedded/cortex-m-quickstart https://github.com/rust-embedded/cortex-m-quickstart
- pjmlp 6y ago
  So giving up on Visual Studio, C++ Builder, QtCreator, NVidia NSight productivity, and fast builds via UWP/COM tooling is compatibility with existing code/libraries?
  - cptroot 6y ago
    My dude, we get it, you like your IDEs. You don't have to mention it in every comment thread. If you find Visual Studio and CLion to be your desired work environments, both of them have support for Rust code via extensions. No it won't be as perfect as what you're used to, but it will be more than sufficient for most people.
    - pjmlp 6y ago
      Well, there are plenty of dudes like myself to convince to drop 50 years of mature tooling support.
  - Communitivity 6y ago
    I use Visual Studio Code for both my Rust and my C++ work, and love it. Tooling support comes from plugins there. I've also used QtCreator, and hated it because for me it was a resource hog, you had to do things its way, and the Qt APIs were horribly designed.
jfkebwjsbx 6y ago
> Does the case for C++ in 2020 still exist? The question is the opposite: you have to prove to managers the benefit overcomes the risk of using a new language. Rust is still not nearly stable nor popular enough for many fields. Go is a very different language with different goals and constraints, so the question does not really fit. > Rust and Go are much simpler to learn Go is a simple language, yes. Rust is a different beast with the same intrinsic complexity as C++. > can do everything that C++ Not exactly true (for the moment). Rust is lacking on const generics, HKTs and other details. > sane, simple and clean build systems/package managers That is not a big argument for the kind of projects is used for. And it is not true either, since nowadays there are several competing, modern package managers for C++ too (build2, Meson, Conan, modern CMake...). > not to mention async/await concurrency The async IO model has been available in many languages for many years, including C++. In the recent years several languages (including Rust and C++) are bringing syntax sugar to let the compiler create the state machines. But it is not the only way of doing async.
- deleted 6y ago
  [deleted]
- ncmncm 6y ago
  This from yesterday: https://news.ycombinator.com/item?id=24032305 https://news.ycombinator.com/item?id=24032305 Tl;dr: C++ is now and will remain the near-exclusive choice for essentially all of the highest-paid, most demanding work in medtech, fintech, CAE, HPC, telecom, and aerospace, for decades to come. Rust code will never be able to call into the very powerful libraries these applications depend on, because they are based on language features Rust will never have. No language other than C++ and Rust targets these applications. Very noisy Rust advocates here are inaudible elsewhere; many more people start using C++ in every week than the total who touch Rust in that week. That will not change soon. Rust is a much better language than C, Go, Java, C#, Visual Basic, Delphi, COBOL, Nim, and Dart, and much faster than Python, Ruby, and Perl. Advocates would better focus recruiting there than tilting at C++.
- mlindner 6y ago
  > The question is the opposite: you have to prove to managers the benefit overcomes the risk of using a new language. Rust is still not nearly stable nor popular enough for many fields. I'm not sure what you're saying. Rust 1.0 code compiles just fine in the most recent rust compiler. It's been stable since that 1.0 point and promises to continue being stable. C++ doesn't have a a stable ABI either.
mamcx 6y ago
> Does the case for C++ in 2020 still exist? Even if exist, is better to let it die. C/C++ is a costly mistake. VERY costly. Apart of interact with legacy code, both C/C++ have much better replacements (like pascal). Is only the stubborn "but what if I need to replace my heavily bug-ridding, unsafe, crash-prone, hard-to-mantain, harder-to-prove is good; source code, and need to retrain my developers that spend a lot of mental energy in workaround them in something, better?????" Our industry is weird. In any other, if the "engineers" insist in use a well-know unsafe tooling and refuse to learn safer tooling/practiques you will fire them as incompetents. By the way, I learn mechanical engineering (at trade level).
- hota_mazi 6y ago
  > Even if exist, is better to let it die. C/C++ is a costly mistake. VERY costly. Not sure what you are basing this on but it's probably not an exaggeration to say that C/C++ has generated hundreds of billions of dollars in revenue over decades, not mentioning employment, advancement in programming language theory, learning lessons, etc... I am really not a fan of C++ overall but its achievements cannot be understated. Saying it's a "VERY costly mistake" is baffling.
  - mamcx 6y ago
    > Not sure what you are basing this on but it's probably not an exaggeration to say that C/C++ has generated hundreds of billions of dollars in revenue over decades And PHP, Cobol, Perl, etc. Just because a tool is useful is not a reason to avoid point their problems. And C/C++ have very well know problems, since decades ago. > Saying it's a "VERY costly mistake" is baffling. Maybe if MS say it? https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... https://www.zdnet.com/article/microsoft-heres-why-we-love-programming-language-rust-and-kicked-off-project-verona/ https://www.zdnet.com/article/microsoft-heres-why-we-love-pr... Just to point a recent one...
nilkn 6y ago
C++ has a large ecosystem in certain domains that Rust and Go can't match (and may never be able to). Graphics and game development are examples. So I don't think C++ is just going to die out and be replaced entirely by Rust and Go. Also, in some of these domains, Go fundamentally isn't a good fit, though Rust theoretically could be if not for the ecosystem problem. That said, I do think that for a certain category of greenfield projects that can avoid needing certain types of dependencies on and interactions with other existing software or codebases, Rust and Go will completely dominate C++ going forward. For new work that doesn't need the C++ ecosystem and doesn't rely on dependencies not available for Go/Rust, it really is hard to imagine how one of Go/Rust would not be a significantly better choice in 2020 and beyond. Some companies will be entirely based on such greenfield projects. Others will be entirely based on problems that rely on some of that existing C++ ecosystem. Yet others will be mixed and may be able to use C++, Go, and Rust as it makes sense. So I think it's going to be a complicated situation where some folks will be able to completely move ahead of C++ and others will be tied to it for a long time yet.

ur-whale 6y ago

> can do everything that C++ can Don't know about Rust, but for go: . can't match C++ on speed . doesn't (yet, AFAIK) have generics.

ben-schaaf 6y ago
Go also can't call any C libraries without massive overhead (at least not the reference implementation), nor run without a runtime. Go isn't really an alternative to C/C++/rust and it's not meant to be.
- adrianN 6y ago
  Every programming language is, to different degrees, a replacement for every other programming language. Whether Go is a replacement for C++ or not depends on what you want to do. For a lot of use cases where you might choose C++, Go would be fine too.
  - stouset 6y ago
    I think GP’s point is that the overlap of domains that C++ is well-suited for and that go is well-suited for isn’t particularly large. Go was at least originally touted as a C++ replacement, but to be honest, that story hasn’t really panned out in practice.
    - pjmlp 6y ago
      Depends, https://www.f-secure.com/en/consulting/foundry https://www.f-secure.com/en/consulting/foundry
      - stouset 6y ago
        With all due respect, I said the overlap wasn't particularly large. Not that it was entirely nonexistent.
- pjmlp 6y ago
  Depends, while I am not big fan of Go, not everyone thinks that way, https://github.com/f-secure-foundry/tamago https://github.com/f-secure-foundry/tamago https://labs.f-secure.com/blog/tamago/ https://labs.f-secure.com/blog/tamago/ https://www.f-secure.com/en/consulting/foundry https://www.f-secure.com/en/consulting/foundry

dgellow 6y ago

Anything related to graphics or game programming has very few reasons to switch to something else than C++ (talking about the engines, not the scripting part).

pjmlp 6y ago
And for the scripting part something like .NET or Python rules, and will hardly change given current industry adoption.

turbinerneiter 6y ago

I think if you are on a green field and do not rely on specific i.e. libraries that are not there yet in Rust, I would have a hard time finding good reasons to use C++ over Rust. Mainly I guess if you have really good C++ programmers who are not interested in Rust. If you are not on a green field, stuff gets complicated. If you have a really good Rust programmer on the team, that is willing to take care of the language interop it can work well, if you have a bunch of Rust learners, you might blow up.

steerablesafe 6y ago

> can do everything that C++ can There are still areas where C++ is more expressive than both rust and go. AFAIK rust just recently got the capability to work with const generics and compile time evaluation. Lack of overloading (besides operators) in Rust is a double edged sword. Overloading allows for very expressive C++ code in the expense of awful error messages when it doesn't work out. C++'s concurrency story is continuously improving, but I'm not qualified to compare here. C++20's coroutines will be quite powerful. And there is one area where Rust and go can't compete: interacting with existing C++ code, including templates. There is a lot of that already. Having said that I keep a close eye on rust, it can certainly replace C++ in certain areas, possibly all areas in the future. But it can't replace it overnight, considering that there are millions of lines of _maintained_ C++ code out there. Not go though, that's like comparing apples to oranges.

bluejekyll 6y ago
I think this is probably the most important reason you list: interacting with existing C++ code, including templates. I wonder if we could ever get direct Rust to C++ FFI. There are ways around it of course, by dropping down to C FFI in both languages.
- cptroot 6y ago
  It's important to remember that C++ doesn't define an ABI, so you'd have to focus on specific compilers' ABIs.
  - bluejekyll 6y ago
    For some reason I thought C++ had gotten a stable ABI? Not sure why (I’ve been out of C++ dev for years).
    - pornel 6y ago
      C++ has a policy of not making changes that would break anyone's ABI, but still doesn't have an official one. https://cor3ntin.github.io/posts/abi/ https://cor3ntin.github.io/posts/abi/

saurik 6y ago

FWIW, C++ has actually had stable async/await (I have been shipping a production product compiled to numerous platforms now for a year built with C++ coroutines) since before Rust finished theirs (and from what I so far know about Rust's, I like C++'s better, though I admit I don't know enough enough about what Rust did). C++ also frankly has a much better cross-platform build system story, with more extensible and hookable builds (the ability to do header injection on library dependencies with #include_next is epic)... I have so many bugs filed against cargo and rustc with respect to even basic cross-compile scenarios it isn't funny anymore :/. (I mean, cargo doesn't even get reproducible builds for cross-compiled binaries correct, though at least I was able to figure out a super awkward workaround for that where I give it a "rustc wrapper" and then run a filter on the command line arguments to strip the host-specific cargo metadata.) Some of us also think Rust made the wrong call on not supporting exceptions (if you want to use "monadic error handling" but you don't actually support defining monads, something seriously broken happened). C++ also has faster serial build times than Rust and fundamentally better support for parallel and incremental compilation than Rust (due to its support for prototypes and translation units; I ship my builds off to AWS lambda and expect to get linear speedup on -j1000 now that Amazon supports EFS mounts). <- So like, while I might agree that Rust's build system is "simple and clean", the reality is that computers aren't and so it is a fundamental mistake to make such a rigid build system :/. Rust is also still lacking in some key type system features, such as being able to template over values (which lets you create compile-time safe buffer types), which is a frustrating tradeoff against Rust's feature of lifetimes (which is absolutely a good thing, but isn't actually a source of issues in my code vs. buffer handling: what I really want is even dependent types... if Rust had at least gone for full linear types it would sell me much more quickly, as dealing with those situations is currently miserable in both languages and I know I could use such a facility to prevent the vast majority of the issues I actually run into in my code with respect to asynchronous cross-computer behavior). C++'s obviously-trivial compatibility with the massive ecosystem of C/C++ libraries is also useful. And like, while I totally appreciate the reasons object oriented programming can suck, for GUI programming it is still an incredibly common paradigm that C++ supports but is directly supported by neither Rust nor Go (which I haven't complained about at all in this comment, but mostly because I consider it a competitor to Python, not C++).

6y ago

cmrdporcupine 6y ago

You may have a team of experienced C++ developers and libraries of C++ code to interface with. I think one make a good argument for Rust, but you will also have a harder time sourcing developers and ramping up to speed. It's still novel, despite maturing rapidly. There are many many many high quality C++ libraries out there, and the modern C++ language is, for me, decently pleasant to work with, once you pick your style and set of constraints. Also, I really don't want to go around on this argument _again_, but I don't think Go is a serious competitor for C++ for the systems level programming where C++ dominates. Go is not the language for writing OS kernels, drivers, embedded code, etc. Nor do I think a garbage collected system is appropriate for hard real time systems of most kinds. I think what we have here in this discussion is another classic case of HN having a bit of a blindspot for anything that isn't web / web services or mobile app development. For many embedded systems developers for example it's a challenge just to get them to consider C++ over C, let alone something like Rust.

yahyaheee 6y ago
The c++ library argument is funny to me because it’s so incredibly difficult to import external projects in c++. This is where Rust is going to eat their lunch.
- pjmlp 6y ago
  Had C++ standed still, yes. Except that now there is vcpkg, conan, prefab (on Android) and contrary to cargo,they support binary libraries, meaning I don't have to build the world every time I start a new project.
  - yahyaheee 6y ago
    C++ has had ages to solve this problem, vcpkg and conan are still a ways away from the simplicity of cargo. Doesn't support binary libraries? I don't really care considering everything else I get, I'm sure they'll support that in the future.
    - 6y ago

pjmlp 6y ago

Plenty, let me see. Although it is a polyglot target environment, CUDA hardware is designed for optimal support of C++ semantics. C++ is used for device drivers on Apple and Google's OSes. Swift and Rust depend on LLVM, written in C++. Unreal, Unity, CryEngine, Godot have C++ at their core. AUTOSAR safety standard for cars is based on C++14. UWP and DirectX are heavily based in C++. Tensorflow and PyTorch depend on C++. And plenty of other endless examples. Sure you can try to make do with Rust or Go, but be prepared to code like we used to program in C++ 30 years ago in regards of eco-system, IDE support and wealth of existing libraries.

cmrdporcupine 6y ago
Yep, and consider the chromium code base, or at least V8 which is embedded in all sorts of projects. C++. Yes, you could use a Rust wrapper, but it would not be pleasant. There's a bunch of other examples of this kind of thing. Additionally, if you work at one of the FAANGs (or many other large established companies) there's good chance you are working on an existing C++ base, with existing C++ build tools, with a good C++ style guide, and with plenty of other competent C++ engineers. Rust is not of the endorsed/established languages at Google. (And no, Go isn't frankly used as much at Google as people seem to think it is, though its use is increasing).
nilkn 6y ago
> be prepared to code like we used to program in C++ 30 years ago in regards of eco-system, IDE support and wealth of existing libraries. That's a bit of an extreme statement that needs some significant qualifications. This might be true if you are pushing for Rust or Go in one of the domains you mentioned, like professional game development. It would be fairly absurd for a studio to seriously try to switch to Rust in some of these areas. That said, if you're largely working on greenfield projects that don't rely on an existing C++ ecosystem, the situation almost gets inverted. For instance, C++ still doesn't have any kind of standardized package manager in 2020. There are a thousand little paper cuts in C++ that are hard to justify if you don't have to interface with an existing ecosystem or target a specialized environment that only it is well-suited for.

ganfortran 6y ago

The last few strongholds I see with C++ is probably game development. To crack into gaming industry, C++ is still a must-have skill. But TBH, I really don't want to use C++ if the circumstance allows. The language spec is just so overtly complex that feels self-defeating, it is harder and harder to justify use it in the first place.

fulafel 6y ago

That's a pretty low threshold to pass, obviously it's not doing to die overnight in 2020. C++ will continue its steady decline in mindshare but the user count will stay high, countered by the growth of the programmer population.

rvz 6y ago

Well I still can't create a mature cross-platform GUI app in either Go or Rust and Qt seems to be the first class option for that in the C++ world. Looking at some of the solutions for both Go and Rust, its either immature bindings to wrap around C or C++ for the same thing (the best you would get is GTK+) which are unmaintained and less stable / usable to what you would get with Qt5 with C++. I still keep seeing lots of cross-platform closed and open-source GUI apps still taking the Qt route.

jasode 6y ago

>Does the case for C++ in 2020 still exist? Rust and Go are much simpler to learn, can do everything that C++ can There are 2 levels of comparisons: - (1) language syntax : the "they're both Turing Complete" so whatever one can do, the other can do and because Rust is newer, it has nicer syntax. E.g. plain Rust syntax already has "ownership pointers" by default so doesn't require typing ugly verbose syntax such as "unique_ptr<T>". - (2) ecosystem and dependencies : In 2020, C++ and not Rust is still the primary API for things like NVIDIA CUDA, Unreal game engine, Qt GUI, and the ARM Allinea developer tools[1] for compiling code for the new Neoverse chips (e.g. latest AWS Graviton2 ARM servers). Sure, one could write wrappers in Rust for all those things but doing so will be going against the grain and now you're yak shaving your tools instead of building business value. If I had a brand new startup today, I'd use Rust as much as I could but there'd still be 25% to 50% new C++ code because deep learning (e.g. CUDA) is C++ not Rust. [1] https://www.arm.com/products/development-tools/server-and-hpc/allinea-studio https://www.arm.com/products/development-tools/server-and-hp...

Kenji 6y ago

> Does the case for C++ in 2020 still exist? No. Only if you are working with legacy code or large C++ libraries (like e.g. Qt). Rust is better than C++ in every single aspect.

rkangel 6y ago

We mostly use C rather than C++, but the same two big reasons get in the way of using Rust for everything: * Compiler support * Availability of suitable engineers Context - I work for the Wireless Division of Cambridge Consultants (Cambridge, UK). We build comms technology for our clients for basically anything you can think of - satphone, telecomms infrastructure, bluetooth headphones etc. This means that a lot of the software we right runs on an embedded target - that might be a microcontroller or it might be Linux. And importantly - often when we've designed something, our clients will carry on the maintenance and ongoing development. We have to take the long view - if we choose C/C++ we can guarantee that a compiler will exist for whatever hardware target they choose for the next generation of the product (or even the current generation - architecture swaps often happen at the cost reduction stage). Rust support is improving but can I guarantee that there will be a compiler available for some niche processor, or even the Xilinx Zynq target I'm using at the moment? And then when we hand over the code, we have to explain to the client that it's written in a language that none of their existing software engineers know, and if they advertise for people they may or may not be able to find them. All that said, we are pushing to use more suitable languages for our work. Using C/C++ for anything where security is important is beginning to look irresponsible, the above issues don't always apply and that combined with improved embedded support, more name recognition for Rust and ever more enlightened clients means that it's going to be an easier sell for more and more projects. But not all of them, not now. Actually it turns out that it's easier to sell Elixir as an alternative to some of our C development. My current project is a Linux target, microprocessor support is not important and the challenges it has are exactly what Erlang is designed to solve. I'd also suggest it's easier to incrementally teach the client Elixir than Rust. We'll keep pushing Rust though, and we'll get there eventually.

thenewwazoo 6y ago
I have experienced this horrible chicken-and-egg problem firsthand. I worked at Zipcar building the control boxes used for rentals and the fit for Rust was obvious and compelling, but was squashed by management because it was "too hard to hire" and "the language is underdeveloped". While those things are true, to fix them someone has to just do it. Instead, they fired me and now I make twice the money doing SRE work again at a FAANG.

quietbritishjim 6y ago

> Rust and Go are much simpler to learn I don't think this is true. I say that even though I would be deliriously happy if Rust replaced C++ in most situations it's currently used. Yes, learning the whole of Rust, including any/all dark corners (no doubt it has a few) is easier than learning the whole of C++ including all its dark corners (it certainly has many!). But getting a basic working knowledge of both is not too different... except for Rust's ownership system. I realise that the ownership system is one of Rust's main benefits, but that doesn't change the reality that it's a significant obstacle for many decent developers. I actually wish it were possible to use Rust in an "unsafe everywhere" mode where you could ignore the ownership stuff. (Maybe this is already possible with liberal use of the "unsafe" keyword, but it is at least socially unacceptable.) Of course it wouldn't be right for every project but it would still be a huge improvement over C++ while being much more accessible than fully safe Rust.

steveklabnik 6y ago
It's not possible, because unsafe does not turn anything off; unsafe is a superset of safe.
- quietbritishjim 6y ago
  But if I use unsafe everywhere then couldn't I pass around raw pointers everywhere instead of references to avoid the lifetime checking? (Try to contain your horror! :-) )
  - steveklabnik 6y ago
    Only if you write the entire universe; you're going to want to call functions that accept references, and then you're stuck. > (Try to contain your horror! :-) ) Ha! Nah, no horror there. It is interesting to think about, for sure.
    - quietbritishjim 6y ago
      But I thought you could cast a raw pointer to a reference with "as" in an unsafe block? Obviously that makes it possible for you to create multiple mutable references, or a mutable reference at the same time as an immutable reference, which is undefined behaviour, but undefined behaviour was always going to be the risk of this idea. Also, even if you had a compiler switch to make "unsafe" implicit everywhere, your code is going to be littered with a lot of casts. (Obviously I'm not a Rust expert, which is why my comments are in the form of questions.)

dragontamer 6y ago

> Does the case for C++ in 2020 still exist? Are there C libraries you want to remain (nearly) source-compatible with while using classes, templates, and other more modern programming features?

Communitivity 6y ago

If you are supporting Windows or Linux, and are supporting the x86 platform, then for me the only reasons to use C++ over Rust are for compatibility with existing code/libraries, or lack of Rust expertise on the team and no time to learn Rust. If you are working in an embedded environment Rust is still very capable, but the tooling for Rust does not seem at the level of the embedded tooling for C and C++. You can still use Rust for embedded, and there are success stories to be found in the links below. [1] https://www.rust-lang.org/what/embedded https://www.rust-lang.org/what/embedded [2] https://rust-embedded.github.io/book/ https://rust-embedded.github.io/book/ [3] https://github.com/rust-embedded/awesome-embedded-rust https://github.com/rust-embedded/awesome-embedded-rust [4] https://github.com/rust-embedded/cortex-m-quickstart https://github.com/rust-embedded/cortex-m-quickstart

pjmlp 6y ago
So giving up on Visual Studio, C++ Builder, QtCreator, NVidia NSight productivity, and fast builds via UWP/COM tooling is compatibility with existing code/libraries?
- cptroot 6y ago
  My dude, we get it, you like your IDEs. You don't have to mention it in every comment thread. If you find Visual Studio and CLion to be your desired work environments, both of them have support for Rust code via extensions. No it won't be as perfect as what you're used to, but it will be more than sufficient for most people.
  - pjmlp 6y ago
    Well, there are plenty of dudes like myself to convince to drop 50 years of mature tooling support.
- Communitivity 6y ago
  I use Visual Studio Code for both my Rust and my C++ work, and love it. Tooling support comes from plugins there. I've also used QtCreator, and hated it because for me it was a resource hog, you had to do things its way, and the Qt APIs were horribly designed.

jfkebwjsbx 6y ago

> Does the case for C++ in 2020 still exist? The question is the opposite: you have to prove to managers the benefit overcomes the risk of using a new language. Rust is still not nearly stable nor popular enough for many fields. Go is a very different language with different goals and constraints, so the question does not really fit. > Rust and Go are much simpler to learn Go is a simple language, yes. Rust is a different beast with the same intrinsic complexity as C++. > can do everything that C++ Not exactly true (for the moment). Rust is lacking on const generics, HKTs and other details. > sane, simple and clean build systems/package managers That is not a big argument for the kind of projects is used for. And it is not true either, since nowadays there are several competing, modern package managers for C++ too (build2, Meson, Conan, modern CMake...). > not to mention async/await concurrency The async IO model has been available in many languages for many years, including C++. In the recent years several languages (including Rust and C++) are bringing syntax sugar to let the compiler create the state machines. But it is not the only way of doing async.

deleted 6y ago
[deleted]
ncmncm 6y ago
This from yesterday: https://news.ycombinator.com/item?id=24032305 https://news.ycombinator.com/item?id=24032305 Tl;dr: C++ is now and will remain the near-exclusive choice for essentially all of the highest-paid, most demanding work in medtech, fintech, CAE, HPC, telecom, and aerospace, for decades to come. Rust code will never be able to call into the very powerful libraries these applications depend on, because they are based on language features Rust will never have. No language other than C++ and Rust targets these applications. Very noisy Rust advocates here are inaudible elsewhere; many more people start using C++ in every week than the total who touch Rust in that week. That will not change soon. Rust is a much better language than C, Go, Java, C#, Visual Basic, Delphi, COBOL, Nim, and Dart, and much faster than Python, Ruby, and Perl. Advocates would better focus recruiting there than tilting at C++.
mlindner 6y ago
> The question is the opposite: you have to prove to managers the benefit overcomes the risk of using a new language. Rust is still not nearly stable nor popular enough for many fields. I'm not sure what you're saying. Rust 1.0 code compiles just fine in the most recent rust compiler. It's been stable since that 1.0 point and promises to continue being stable. C++ doesn't have a a stable ABI either.

mamcx 6y ago

> Does the case for C++ in 2020 still exist? Even if exist, is better to let it die. C/C++ is a costly mistake. VERY costly. Apart of interact with legacy code, both C/C++ have much better replacements (like pascal). Is only the stubborn "but what if I need to replace my heavily bug-ridding, unsafe, crash-prone, hard-to-mantain, harder-to-prove is good; source code, and need to retrain my developers that spend a lot of mental energy in workaround them in something, better?????" Our industry is weird. In any other, if the "engineers" insist in use a well-know unsafe tooling and refuse to learn safer tooling/practiques you will fire them as incompetents. By the way, I learn mechanical engineering (at trade level).

hota_mazi 6y ago
> Even if exist, is better to let it die. C/C++ is a costly mistake. VERY costly. Not sure what you are basing this on but it's probably not an exaggeration to say that C/C++ has generated hundreds of billions of dollars in revenue over decades, not mentioning employment, advancement in programming language theory, learning lessons, etc... I am really not a fan of C++ overall but its achievements cannot be understated. Saying it's a "VERY costly mistake" is baffling.
- mamcx 6y ago
  > Not sure what you are basing this on but it's probably not an exaggeration to say that C/C++ has generated hundreds of billions of dollars in revenue over decades And PHP, Cobol, Perl, etc. Just because a tool is useful is not a reason to avoid point their problems. And C/C++ have very well know problems, since decades ago. > Saying it's a "VERY costly mistake" is baffling. Maybe if MS say it? https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... https://www.zdnet.com/article/microsoft-heres-why-we-love-programming-language-rust-and-kicked-off-project-verona/ https://www.zdnet.com/article/microsoft-heres-why-we-love-pr... Just to point a recent one...

nilkn 6y ago

C++ has a large ecosystem in certain domains that Rust and Go can't match (and may never be able to). Graphics and game development are examples. So I don't think C++ is just going to die out and be replaced entirely by Rust and Go. Also, in some of these domains, Go fundamentally isn't a good fit, though Rust theoretically could be if not for the ecosystem problem. That said, I do think that for a certain category of greenfield projects that can avoid needing certain types of dependencies on and interactions with other existing software or codebases, Rust and Go will completely dominate C++ going forward. For new work that doesn't need the C++ ecosystem and doesn't rely on dependencies not available for Go/Rust, it really is hard to imagine how one of Go/Rust would not be a significantly better choice in 2020 and beyond. Some companies will be entirely based on such greenfield projects. Others will be entirely based on problems that rely on some of that existing C++ ecosystem. Yet others will be mixed and may be able to use C++, Go, and Rust as it makes sense. So I think it's going to be a complicated situation where some folks will be able to completely move ahead of C++ and others will be tied to it for a long time yet.