Hacker News new | past | comments | ask | show | jobs | submit login
Bjarne Stroustrup Weighs in on Distributed Systems, Type Safety and Rust (thenewstack.io)
151 points by rsecora on Aug 3, 2020 | hide | past | favorite | 228 comments

> He’s aware of other languages, as he reveals in his answer to a later question. (“I think C++ can do anything Rust can do, and I would like it to be much simpler to use.”) And towards the end, he couldn’t resist noting that longevity has its advantages. “It’s highly humorous when some of the Rust people come up and accuse me of having stolen some of their ideas without acknowledging — when some of the things I did I actually did almost 40 years ago.”

Does anyone know what these accusations were? Given that C++ has been around for so long, It's incredulous to think that anyone from the Rust community can put forth such a claim.

> It's incredulous to think that anyone from the Rust community can put forth such a claim

If you talk about something so undefined as _the Rust community_, I'm pretty sure I can claim that _someone of them_ has said pretty much anything in existence.

Like some of the "why did you not write it in Rust" bros on any forum like Reddit or here might very well have writen some utter bullshit about other languages, would not be surprised.

I'm more than half convinced that the "why did you not write it in Rust" group actually hates Rust and its a meme because those comments certainly promote a visceral hatred.

I can assure you that they exist, and they are unironic.

Today, that saddens me greatly. It seems like there are always members of any community, virtual or physical, that go to such an extreme that they provide fodder for all those who don't like the community as a whole. The Warhammer Heresy memes are just too true.

The parent and Stroustrup were both clear in saying “someone from the Rust community” and not “the Rust community”. Talking about group opinions is hard but in this case they were clear.

“Someone from the Rust community” is super vague.

Super vague as to who it was, yes. But it's really clear that it wasn't the position of the bulk of the community.

The only thing I can think of is modules, which C++20 is planing to introduce. But I would be very surprised if anyone was accusing anyone else of "stealing" ideas. It's preposterous because 1. every language copies good features from others (that's a good thing) and 2. Rust has copied a lot from C++.

I wish people wouldn't talk about one or two people with a warped view as "the community".

3. Everyone I've met from the rust community is super explicit that Rust has stolen as many good ideas that it could find, and that that is a good thing.

> Rust has copied a lot from C++.

I think this is exactly the thing: if you come from C++ it's very obvious that they drew a lot of inspiration from there (I won't use a charged term like "copied"). But I get the impression that people who got into rust without learning C++ first are largely unaware of this. Or, even if they had worked with c++ but missed the boat on raii and smart pointers.

> I wish people wouldn't talk about one or two people with a warped view as "the community".

At least in the quoted sections, they weren’t talking about the opinions of the rust community, but rather those of someone from the Rust community.

My point is that saying "Rust community" implies that this person represents the community in some way or worse, is representative of the community. Neither is true. It's just some random person with no credentials. That person is no more the Rust community than I am the HN community. Imagine how you'd feel if people made assumptions about you based on what nindalf said that one time.

C++ modules have been a thing for a long time even if the standard is being presented this year.

It is not a C++ idea anyway, older languages have had similar facilities.

Additionally, just because C++ "had it" doesn't mean it was done anywhere close to well.

Modules have existed far before rust e.g in javascript, python, Java, etc

Those are valid examples, but modules are much older than that: https://en.wikipedia.org/wiki/Modular_programming#History

It really shows Stroustrup's point on how most of these programming concepts have been around for a long time.

Rust officially credits many languages including C++: https://doc.rust-lang.org/reference/influences.html

First Mozilla introduction of Rust states:

> Rust is a language that mostly cribs from past languages. Nothing new.

http://venge.net/graydon/talks/intro-talk-2.pdf (I recommend reading the slides — they're great!)

so whoever is accusing C++ of "stealing" Rust ideas is uninformed about C++ and Rust.

It usually comes from more emotional adopters without much experience in programming languages.

You will also see some safety assertions regarding stuff that was already safe when using Ada, or any Modula or Oberon linage of programming languages.

Not everyone on Rust community tends to be like that.

Good artists copy but great artists steal :-)

Joking aside, it's funny that Bjarne did not talk about D since it seems that C++ is copying many of D nice features in later of C++ iterations for over a decade now.

And now D is copying the Rust/Cyclone ownership concept, nice!

People in the D community like to think that, but stuff like ranges is older than D, born out FP languages research and even Smalltalk had them on its collection types, then auto for type inference was already there in C with Classes, just Bjarne faced too much opposition back in the 80's.

I'm honestly wondering why he explicitly mentioned it.

Languages taking inspiration from other languages and that's normal I don't think anyone bm the people I know from the rust community (which e.g. work on the compiler and language) would do so.

That's except if you write something like a paper, in which case it's party of the proper proceeding to mention "priority art" you are aware of *even if you didn't copy it or even had the idea early but just didn't publish it.

I hope it's just some random thing he remembered thought of when causally doing the interview, because the other alternatives wouldn't make him look good.

Admitting that D even exists should embarrass the C++ committee.

Modules and contracts have taken something like 30 years combined, and they still aren't prevalent. The tried to borrow static if, but theirs is scoped and misses the point (the static if paper).

All of the aforementioned are maintained in a language that has less maintainers than C++ has committee members, with better solutions and orders of magnitude faster compile time.

Why should it? At least ISO C++ knows what they want, while D is still trying to find out to which community they should be advertising to.

I find many of the people on their forums quite nice, but D lacks a profound sense of direction and which market they want to target.

Filling multiple roles is not the same as lack of direction. D does lack direction, but that's arguably a good thing - that's why the scripting-like features can exist alongside the features which are intended for writing high performance code.

The fact that C++ is only used for performance is due to C++ being a bad language everywhere else rather than being amazing at writing high performance code. How many hours of developer productivity have been lost to slow compiles and bad metaprogramming (traits, contracts, and constexpr are emblematic of the half in half out C++ way)

Might be, but right now I don't see D ever taking off, rather going on the down slope of adoption curve, while C++ despite its warts, keeps increasing adoption thanks to AI, GPGPU shaders and driver SDKs for all major OSes.

By the way no one at Remedy is using D nowadays, while the number of studios using C# alongside C++ keeps increasing.

I am very curious too; I don’t think I’ve ever heard anyone claim this. If anything, folks talk about the debt we have to C++ for pioneering a lot of this stuff!

C++ is building something similar (and maybe with less syntactic noise aka lifetimes markers) to rust borrow checker https://www.reddit.com/r/cpp/comments/8zle4k/current_state_o...

But yeah indeed, rust borrowed more concepts (e.g RAII) from C++ than C++ borrowed from rust

Rust also borrowed concepts from Cyclone:

> The inspiration for safe borrowed references comes in two ways from the Cyclone programming language, a joint development effort by AT&T and Cornell University. The notion of a borrowed reference is adapted from Cyclone’s polymorphic restricted alias pointers. Additionally, Cyclone’s safe memory management focused on regions (which are usually arenas). In order to ensure memory safety, Cyclone pointers could be annotated with a named region qualifier preceded with a back-tick (making them look very much like Rust’s apostrophe-based lifetime annotations).

source: https://pling.jondgoodwin.com/post/lifetimes/

Any community that is large enough is going to have some less informed brash members. Communities are open big tents after all.

Yeah it's probably actually a sign of a healthy community that it has less informed members that feel safe to speak up. That's how they learn even if it can be hard to deal with.

nit: Only people can be incredulous. Well ok, dogs etc too. It means (of a person) "not wanting or not able to believe something, and usually showing this".

People are avoiding "incredible" for its dictionary meaning nowadays because it has morphed into a generic intensifier.

In a few years that will pass, and people will not say extremely silly things like "incredibly honest" anymore. But they will necessarily take up saying other equally silly things.

Thanks!! "Generic intensifier" is a very useful label, e.g. it's been driving me nuts how "literally" is used so frequently and inappropriately, on HN and other places. It's become a generic intensifier. But these words that cry wolf lose their..Ah well, this is what language evolving looks like I guess - like it's going downhill! But it's like Reutersvärd/Penrose stairs, only appearing to descend.

You are tripping over the Recency Illusion. As with almost all complained-about English usage, abuse of "literally" began (literally) centuries ago.

British newspapers regularly host shrill complaints about language degradation in the Colonies, but in every single case the reviled usage turns out to have started somewhere in England, typically before the colonials went. That shouldn't surprise: there is overwhelmingly more variability in English usage in England than the sum total in all other places.

It would not be at all surprising if "incredibly" went through a similar cycle 200 years ago. For a time, "nice" meant "stupid", before it meant "precise". For a time, "plausible" meant "implausible". Just be glad abuse of "exponentially" has fallen off.

> You are tripping over the Recency Illusion.

Maybe, or maybe it is an unprecedented recent spike. We're both guessing, I suspect.

[5 minutes research later] Well, there is this measure of the frequency of 'literally' in books in English since 1600. (Although I meant in speech and online comments)


Which does seem to possibly support the 'unprecedented spike' hypothesis! A huge surge since 1990, the largest ever, the word is now used twice as often as in books in 1990.

Looking at examples from 1800-1820, during the 2rd biggest surge, which lasted around 100 years centred on 1840,


- none of those on the first few pages of results appear to be the general intensifier kind of 'literally'.

Compare with 2019-2020, where most examples in the first few pages are the kind I've gotten so sick of lately:


I eagerly await further research in the field. :-)

You need to subscribe to Language Log, from upenn.

A modern confounder is that copy-editing activity has declined along with the cost of publication, so that misuse that previously appeared much less in print than in oral discourse now evades scrutiny. Transcripts of court testimony would give a better sense of how people spoke.

Nonetheless, from your link I find in 1812, "was literally bathed with sweat" and 1810, "it shall bruise thy head, and thou shalt bruise his heel. This between the woman and the Serpent is most literally fulfilled ."

> Once you get users, you have responsibilities, and one of the responsibilities is not to break their code.

That is both a good and bad thing.

Within both C++ and JavaScript there is a very elegant programming language with powerful semantics.

However, there are also a lot of bad solutions and dangerous hacks accumulated. And most of us programmers don't know how or don't have the self discipline to separate the good parts from the bad parts. And sometimes even with the knowledge and self discipline you can't avoid them (e.g: when using someone else's libraries).

In some languages (e.g: Lua, Python) the designers are ready to break backwards compatibility. C++ chose not too.

Perl was the #3 language on the Tiobe ranking in 2005. It had massive codebases in banks and other industries. In 2019 it was ranked #19 and the incompatible replacement, Perl6, is #93. Breaking backwards compatibility is hugely costly. It creates immense work as people have to validate that new versions of previously working code meet the implicit, accumulated requirements.

Old code will always seem old fashioned. It will not address modern concerns. However, the option to keep using it is very valuable!

Two things - TIOBE is meaningless. And secondly, Perl is a valid example, but so is Python. After a 10 year painful transition, Python is more popular than ever. It's used more than any other language bar Javascript.

> Two things - TIOBE is meaningless.

Pick any other language survey of your choice and I guarantee you it will generally agree with the TIOBE.

Agree with what? TIOBE is just a vague measure of online chatter. I mean, right now TIOBE's site has a section on how Go, Swift, and SQL are tied. What is there to agree with? I mean, you can add "burrito" to TIOBE and the result would be just as meaningful.

That's maybe a good name for a successful programming language :) TIOBE driven design is the future!

That may be true about Python, but despite of the horrible transition from 2 to 3. That transition is a source of frustration to anyone who had to maintain code across the versions 2 and 3.

Not really, plenty of MBA type managers use it as a measure to allow for language adoption on their projects.

The language formerly known as Perl 6 is now called Raku so there are no more backwards compatibility issues.

Perl 7 is the new opportunity for backwards incompatibility (and probably doesn't even have an entry on Tiobe which would make your argument even stronger!)

Also, Tiobe is about as interesting as a gossip column. There are many reasons to pick one language over another, but ranking on Tiobe will never be one of them.

At my current workplace it took at-least 6 months of 2 engineer efforts. That’s about 200k of sunk cost + the opportunity cost of them working elsewhere. Plus other people who got pulled in, it’s easily about 300k to migrate from oy2 -> py3.

We still have a mumbo jumbo mess of py2 scripts lying around.

> In some languages (e.g: Lua, Python) the designers are ready to break backwards compatibility. C++ chose not too.

There are still quite a few Python 2 codebases that will never migrate to Python 3, and quite a few developers who still use Python 2 for new projects.

Anecdotally, several Python developers I know would rather rewrite their Python 2 programs in another language than put in the work to move to Python 3. A lot of them seem to be considering Go and Rust.

The way the Python 2 to 3 change was handled was a huge mistake.

>quite a few developers who still use Python 2 for new projects.

[citation needed], I haven't seen anyone use Python 2 for new projects in the last ~5 years. It reached EOL this year, nobody in their right mind would use Python 2 for new projects today.

Herb Sutter has a nice talk about it, with several examples, expect 10 year adoption delay if breaking features is a thing.

I do wonder about the approach of defining an 'official' Ratfor or F that is strict subset that removes all the old parts of the language and doesn't worry about compatibility with the old code leaving only what is considered best practice. It might be very helpful to show folks the current way to do things while the full language is available to migrate code if it is considered cost effective. Plus, it would be helpful for go forward code. I wonder what a Rational C++ would look like with Concepts and the lot.

In addition to libraries, we often have colleagues and persuading colleagues to agree on a which features should be prohibited can be difficult in many organizations.

> Once you get users, you have responsibilities, and one of the responsibilities is not to break their code.

That's rich. Figuring out how to use C++ on a large project (where you often depend on existing codebases) is always an exercise in figuring out what subsets of what version of the language to use. Presenting C++ like one language that has maintained backwards compatibility is, at best, a gross oversimplification of what is one of the bigger headaches of using C++.

That being said, I can't remember C++ ever doing something directly destructive and unnecessary like redefine how integer division works like I have seen in certain other languages that also result in hostility towards the user.

In Rust, ownership is a compile-time issue. This puts constraints on how you can use references, how ownership is passed around and so on. This programming model has a cost to the user and is probably inherently slower to compile just because the compiler has to do more.

But at runtime it's essentially free.

C++ on the other hand added a set of primitives starting in C++11 to be explicit about ownership through std::unique_ptr and such. These have a runtime cost and ultimately mean getting locks. I've seen estimates of this cost in the single digit microseconds. Not exactly super-expensive but not free either.

There are simply some assumptions Rust can make that C++ can't because certain things aren't possible in Rust.

Another example: Rust doesn't have exceptions. Over the years I personally have some to believe that exceptions are largely a false economy (particularly the failed experiment that is/was checked exceptions in Java).

Instead Rust has match expressions and enumerated types (with state!) that force you to deal with return types. This BTW is very much what Google C++ looks like. It's even debated if you can ever write truly exception-safe C++ code.

This is another problem Rust doesn't have by virtue of not having the feature.

Are you starting to see the pattern? C++ has everything in it. That comes at a cost and there's no getting around that.

> ... std::unique_ptr and such. These have a runtime cost and ultimately mean getting locks. I've seen estimates of this cost in the single digit microseconds.

You're no doubt thinking of shared_ptr (which I guess is what you meant by "and such"). That has a reference count, which does not lock but does use an atomic counter with the usual costs that involves. unique_ptr has no such thing and is essentially free.

It's not essentially free



I'd rather you'd just stated your objection instead of making me watch a bit of video. Thanks for at least including a time stamp. For the benefit of others: Using a std::unique_ptr adds exception handling code to the functions that use it to guarantee cleanup when exceptions are thrown. Of course, that extra code is not actually executed if the exception is not thrown.

I was responding to a comment that claimed that std::unique_ptr used locks to transfer ownership, and my objection to that is not disputed by what your saying.

You're making the point that exception-safe code is less efficient than exception-unsafe code. I do not know enough about that topic to comment on that matter, I was never trying to say anything about it in my previous comment. But I would like to point out that Rust has an analogue of exceptions: panics (although you can change their behaviour to abort() instead of unwind). So it must have something similar to unique_ptr's unwind handler anyway.

Nah, you missed the main point, it doesn't deal with exceptions. But since you misuse the downvote feature after I looked for the video and timestamp for you, I guess you don't want to be proven wrong anyway. Have a nice day.

You can't downvote direct replies to your comments, you'll notice the downvote button is missing for you on this comment of mine. That must be someone(s) else.

What do you mean by "it" in "it doesn't deal with exceptions"? Rust? Or the C++ snippet on the left hand side in the presentation with the shorter assembly output?

Edit: Since I'm still apparently not clear on your main point, this might be irrelevant, but here [1] is a Godbolt link showing that Rust functions have similar panic-safe unwind code to the C++ exception unwind code shown in the presentation. Admittedly the Rust version does seem a bit shorter (comparing just the actual function, at the bottom of the Godbolt output) and I'm afraid I don't know enough assembly to be able to analyse the difference. But I think the principle is similar.

[1] https://godbolt.org/z/K1xPr3

A bit off topic but I didn’t want to make a separate post for this. I want to brush back up on C++ and learn all the modern features. It’s been over 10 years since I’ve touched any C++ and looking for a good book recommendation for someone that’s familiar with many other programming languages and has programmed quite a bit of c/c++ in the past.

If you are coming back to C++, a great book is "C++ Crash Course" by Josh Lospinoso. Don't be put off by the jokey title and cartoons, it is comprehensive and goes directly to modern c++ ground up (c++17) without going through the dreadful pre-modern c++ parts (ex. protected, friend, class OOP stuff).

After that you can try Stroustrup's "Tour of C++", second edition for a more formal introduction to the language (C++20). You will be ready to tackle coding modern c++.

If you're already familiar with C++ (or just C), Bjarne's blue book is really good, but a bit academic. I'd recommend reading that along with Scott Meyers "Effective Modern C++". I came from knowing only a bit of C++98 from college 10 years ago, read both of those, and now feel like I know C++ (the language) really well. Mastering the STL is step 2. Mastering a (any) build-system is step 3.

Second for Scott Meyer Effective Modern C++. I was in the same situation as you and it seemed like the book was written almost specifically for that.

I love Scott’s books. Not just for the quality of the content, but also for the humor he manages to inject into a quite dry topic.

That said, I find he only covers a few of the more tricky topics, then after a brief “this is what it is and why its useful”, then spends more time on “these are all the edge cases that are dangerous and confusing”.

Maybe he’s right and it’s important to learn all that. But I tend to finish a chapter and think “Cool feature, but I’ll never remember all those foot-guns so I’ll just avoid it if I can”.

But maybe that’s a fair take on C++ <shrug>.

I really like that he points out the dragons.

Most books just explain the language/system design, and add value only by crafting good explanations. But Scott (and others) add an element of experience as well, which is extremely valuable.

I don't think you need to learn all the corner cases, but reading about them at least helps me a lot with understanding the underlying semantics. And when I do run into them, I might get a vague uncomfortable feeling that's enough to make me go back to the book for a reminder.

Perfect thanks.

Bjarne Stroustrup - A Tour of C++,

Arthur O’Dwyer - Mastering the C++17 STL,

Jacek Galowicz - C++17 STL Cookbook,

Scott Meyers - Effective Modern C++ books

also https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

and https://en.cppreference.com

and the conferences of CppCon in youtube.

This is a pretty common question on /r/cpp; here's a thread from two months ago on the topic https://www.reddit.com/r/cpp_questions/comments/gs0and/list_...

Bjarne's Tour of C++ is a good book for it, get the 2nd edition though, as it is updated for C++20.

> We have a model for better concurrency coming up. Almost certainly it will be in [C++ version] 23. It exists and it’s used. It’s backed by people like Facebook and NVIDIA and Intel… So that’s where we’ll get a better concurrency, better use of hardware… Beyond that, I am looking at functional-style pattern matching...

Better concurrency and functional-style pattern matching? Yes please.

Does anyone know what Stroustrup is referring to regarding "better concurrency"? It sounds interesting but it's way too vague.

I believe the big feature slated is executors.

Something like that? https://docs.oracle.com/javase/7/docs/api/java/util/concurre...

What I would like to see in C++ would be green threads and use of io uring and restartable sequences like in project loom.

Yes, same concept.

C++20 added coroutines already.

Also, don't forget that C++ has _age_ behind it. Lots of places are still on arm-gcc-5 because heaven forbid you try to get a new compiler digesting an old code base, then get all stakeholders and customers onboard.

I dream of C++20. But my nightmares are all pre-C++14.

And that will happen no matter what language, just the other day I was reading about poor souls still having to deal with Java 6 code.

I worked at a place from 2006-2010 that had a lot of C++ code written in the mid-90s (some was even from the early 90s). Templates were not allowed (so no stl) and they used their own container classes that were written in the early-to-mid 90s. We used a version of gcc that was at least 5 years old during the time I was there.

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.

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

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.

> I wonder if we could ever get direct Rust to C++ FFI

https://github.com/dtolnay/cxx/ exists and works well AFAIK. That's what Chromium (https://chromium-review.googlesource.com/q/project:experimen...) and others use.

It's important to remember that C++ doesn't define an ABI, so you'd have to focus on specific compilers' ABIs.

For some reason I thought C++ had gotten a stable ABI? Not sure why (I’ve been out of C++ dev for years).

There isn't any standard C++ ABI but there is a de-facto standard ABI that many compiler writers have agreed upon (icc, clang, gcc), funny enough it was developed for Itanium originally: https://itanium-cxx-abi.github.io/cxx-abi/abi.html

C++ has a policy of not making changes that would break anyone's ABI, but still doesn't have an official one.


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

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

This from yesterday:


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

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.

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.

The problem doesn't exist for in house software. Any good programmer can learn whatever language in a week. They can become good over the next few years. Coworkers to help teach help a lot.

When you turn code over to someone else it matters because who you turn it over to needs to learn the language fast and they won't have a few weeks or someone else to teach them.

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.

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

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

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.

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

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

As someone who had a go at both languages Rust has some hard topics, but the time needed to know enough Rust to be able to not shoot yourself in the foot while getting things done is lower than in C++. Of course this has to do with Rusts philosophy of not letting you shoot yourself into the foot, while in C++ you'd have to get much more experience to achieve the same robustness.

Yea I don’t think it’s even comparable, and with c++ it’s still a nightmare to import anything not to mention having to deal with the horribly awkward syntax they have accumulated over the years

Just wait until Rust gets 50 years old.

As for the rest, there is vcpkg and conan nowadays.

Used both vcpkg and conan, not comparable to the ease of use of cargo.

Needed some high performance code last year, wrote it all in c++. This year migrated to Rust, will never look back.

C++ is going to need to break things if they want to fit into the modern landscape.

Cargo is only simple if one is doing FOSS with Rust only code.

Speaking of modern landscape where is a Rust IDE comparable with VS, C++ Builder, QtCreator?

Cargo works fine with private repositories, and I use it wrapping C++ code and that works fine as well.

I use VScode with rust-analyzer and its been a great experience, had an easier time with it than the c++ vscode extension.

> Cargo works fine with private repositories

So does any of the main package managers for C++.

> had an easier time with it

That is an empty argument. Not to mention Rust is only now in 2020 starting to get actual IDE support.

For C++ there are at least 8 major production GUI IDEs available, plus a few TUI ones too, plus dozens and dozens of specialized tools around it.

> So does any of the main package managers for C++. Never said they didn't...

> That is an empty argument. Not to mention Rust is only now in 2020 starting to get actual IDE support.

Actually thats an empty argument, I'm responding to someone saying rust doesn't have IDE support.

It does, I use it every day and it works great. Not saying c++ doesn't just saying it worked better for me than the MS c++ vscode extension.

The person you are responding to is talking about an actual IDE, not an extension to VS Code.

rust-analyzer is great and we have waiting for it a long, long time. But it is not an IDE. Neither is the MS C++ extension.

what? Yes it is, vscode was built to be powered by extensions and they work great.

I've been using vscode for the last 5 years for all kinds of languages and have never though to myself "I wish I had an IDE"

You can also do all your work in a raw text editor, yet you prefer VS Code. Same distinction for an actual IDE.

The Rust and C++ extensions are very far from what an IDE offers. They only handle basic debugging and code completion/browsing. With a few more extensions you can a bit better, but again, you are doing the job that an IDE is supposed to solve for you.

I guess I'll take Rust is my no good "editor" over c++ in a "proper IDE", don't think thats gonna sell most people

CLion has excellent Rust support, among other IDEs..

Yeah, JetBrains has been the first major player to bite, but what others do you know of?

And C++ supports private and public repositories, why waste time always compiling the same binaries for third party dependencies?

There is an eco-system out there for C and C++ developers where companies only sell binary only libraries.

VSCode is not an IDE, just an text editor with a couple of plugins.

C++ Builder, Visual Studio, XCode, Android Studio, QtCreator, KDevelop, those are proper IDEs.

lol "proper IDEs" ok...

vscode is one of the most used editors on the market and I seem to be able to produce quality software in a number of languages with it.

As for binary dependencies, I'm certain Rust will have that in the future. I'm fine without it for now, and what I'm not certain of is whether C++ will ever actually fix their problems because they seem to think they don't have any!

> vscode is one of the most used editors on the market

So not an IDE, see.

funny, it has all the features of an IDE

I guess you never used an IDE.

never in my 10 years of programming a bunch of languages, never done it

Presumably the C++ package managers don’t do very well when interacting with non C/C++ code either? I don’t understand the argument...

It's not possible, because unsafe does not turn anything off; unsafe is a superset of safe.

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! :-) )

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.

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

Nah it's all good! This is a pretty common thing, and sometimes comes in an alternate form ("can't you just Arc all the things?")

You can cast them to a reference. The issue is, the tricky UB happens at this exact boundary. If you're only using references, then the compiler has your back. If you're only using raw pointers, then there are no aliasing issues, so you're good. The hardest part is exactly the boundary between the two. Staying in one world or the other is much easier than going back and forth.

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.

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.

You're defiantly missing the point and beating it to death.

The issue for you might be ease of configuration, but that's not the issue I was talking about. It's availability of libraries and toolkits, which C++ still dominates in the realms of mathematics, graphics & video, GPU programming, gaming, embedded, networking, etc. And if there's something not available for C++ chances are it's there for C and easily used or wrapped.

Configuration management has indeed been C and C++'s weak point, but in the last 5-10 years things have definitely improved since the world of autotools and the like, and while I appreciate Rust's module and package system for what it is... I can get by with CMake + Hunter or similar systems.

And besides, for my day job (Google) it's either C++ with GN/Ninja or C++ with Blaze/Bazel. And that is also quite excellent for what it is.

At this point my career being able to quickly try out a package or rapidly add a new dependency isn't my measure of quality engineering. In my past life I was a Java developer and a big Maven advocate (when it was pretty new); and the world of bottomless dependency trees that spawned is not something I'm eager to repeat. These days I try to keep my external dependencies ... strategic.

packaging == community

and community is the most important aspect of a language.

Yes c++ still dominates in accelerated computing but it won't for long. All these conversations I've had with c++ devs have just assured me of its demise.

Why would the next generation of developers ever use c++ over Rust?

Don't have a library? Great thats my chance to make my mark.

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.

Conan and vcpkg are not even remotely standardized on in the C++ community, and C++ teams I've worked on/with recently wouldn't use either of them, preferring raw CMake only. That said, if the whole community could really get behind one of them and throw immense support behind it for several years, it would probably be possible to largely solve this problem for C++.

Those on Microsoft world will need to get used to vcpkg, no matter what, because that is how Microsoft is now delivering some of their C++ libraries.

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.

Cargo is only simple if one is doing FOSS with Rust only code.

Speaking of modern landscape where is a Rust IDE comparable with VS, C++ Builder, QtCreator?

Cargo supports non-public package repositories, not sure what you’re referring to here?

You got a similar response in another thread: https://news.ycombinator.com/item?id=24038376

They are complaining about no support for binary-only crates, which is not cargo's fault, but rather Rust's lack of stable ABI.

Ah. With decompilers these days, what’s the point? I only want that for the potential speed of overall compilation benefits.

I think adding external projects to a C++ project is a major decision that should be taken very carefully and the amount of research you need to do to make such a decision pales in comparison with just how exactly you integrate it in your project so you can #include its headers and link against its libraries. Then once all that work has been done it's now part of the internal repository so using it with any number of internal projects should be quite easy.

In the modern world you should be able to grab things and quickly integrate them and see how they work as your prototyping projects.

C++ doesn't conform to this model.

This keeps being repeated and repeated and it is just a myth.

Even without a package manager adding dependencies manually is quite easy for the vast majority of popular libraries. With a manager it is the same as cargo.

I assume you are talking about old, broken, unsupported, closed source, binary only libraries, but then it is not a meaningful comparison.

Its really not, even with current libraries, not when you come from languages that have a modern packaging system.

This is exemplary of why Rust will win out in the end. The c++ crowd can't acknowledge its shortcomings and fix them in a meaningful way

It is the same for cargo, npm, pip, C++ managers and other languages.

Usually a single line does it in all of them, either in the shell or in a config file.

I call FUD.

It was rarely a single line with C++ when I used it over the last year, moving to cargo it is literally always a single line and I was done.

Rust is going to make the C++ community actually look in the mirror for the first time in who knows how long.

So that project didn't use a package manager and you extrapolate that to an entire ecosystem.

Its sooo many projects, if the argument is that c++ has all these libraries, thats mute, but again the c++ devs just think everything is fine!

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.

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

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

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

For example, one can code with async/await in UWP via C++/WinRT today, without having to think which runtime to use, or possible incompatibilities across async runtimes.

That’s because WinRT already provides an async executor based on the Windows thread pool for you, C++ coroutines specify the plumbing for writing coroutines but nothing more, just like Rust - Microsoft just spent the time working up the WinRT async interfaces to coroutines.

ISO C++20 defines them in a way that the current incompatibilities in the Rust world aren't happening as such and any C++ library using concurrency features is expected to just work across compilers.

ISO C++ also does not define how std::thread should be mapped into the host platform.

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 [2] https://rust-embedded.github.io/book/ [3] https://github.com/rust-embedded/awesome-embedded-rust [4] https://github.com/rust-embedded/cortex-m-quickstart

> 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

But these are huge reasons. It is the difference between theory and practice. In theory you can just replace C++ with Rust. In practice, it can be difficult because of those reasons.

Choosing a language isn't just about the language, but about the entire ecosystem and community.

It really depends. In some domains, compatibility is a big enough reason as to completely rule out Rust or Go. In other domains, it's just not something you need at all.

No, for things like database engines C++ still has significant expressiveness and memory model advantages. While you could write something equivalent in Rust, it would require a lot of "unsafe" since it can't express the memory semantics of some modern architectures and it would require much more code.

as someone whos really interested in this kind of thing, what kind of memory semantics specifically does c++ support compared to rust?

A couple examples:

Rust requires references to memory to be visible at compile time. If you use direct DMA for I/O then the silicon holds mutable memory references at runtime that are not visible in code at compile time. In C++ you can make ownership objects (in the vein of unique_ptr) that automagically track the lifetime of DMA references. Exposing most of your address space to DMA is not optional in databases if you care about performance. DMA has other nuances as well e.g. it can modify memory that is not part of the object you care about and which might be "owned" by someone else.

There are safety models wherein it is provably safe, and optimal code-wise, for multiple mutable references to the same object to coexist at runtime. Modern databases often use schedule-based safety, which dynamically reorders operations on references at a fine-grained level, for performance reasons, and which guarantee correctness of the aggregate execution graph without using locks. This wasn't common a decade ago but it is today. A developer can grab all the mutable references they need to objects, knowing that the execution scheduler can see through and arbitrate any potential conflicts. (This is a sophisticated reimagining of the old "deadlock-free" locking structures in databases without the locks, which didn't prevent deadlocks per se but transparently detect and resolve them.)

You can make all of this work in Rust by using a lot of "unsafe" and inelegant data structure workarounds but it voids most of the safety benefits of Rust and requires more complex code.

It takes work, but you can write safe DMA code in Rust. A good post by Jorge Aparicio explaining how is at his blog[1].

[1] https://blog.japaric.io/safe-dma/#:~:text=DMA%20stands%20for...

thanks for the reply!

> In C++ you can make ownership objects (in the vein of unique_ptr) that automagically track the lifetime of DMA references.

does that require os support to make it work? i assume the tracking is handled by some specific inturrupts?

> You can make all of this work in Rust by using a lot of "unsafe" and inelegant data structure workarounds but it voids most of the safety benefits of Rust and requires more complex code.

i see... so i guess rust would have to take one small step out of static, and into dynamic territory with a smart pointer "trait"?

The OS has to provide syscalls and other APIs for scheduling DMA operations into your address space. Linux has supported this to some degree for a very long time (storage DMA was introduced in the 2.5 kernels). In terms of behavior and APIs, storage is very different than network, since the former is schedule-driven and the latter is interrupt-driven.

There is a lot of implementation detail, but you need object references that are aware when a DMA operation is outstanding on address space they “own”, the type of DMA operation, and rules about when new DMA operations can be scheduled with respect to object reference lifecycles. There are no fixed set of rules but there are a common set of design patterns. The scheduler design does a lot of the heavy lifting.

i see, very interesting, thanks ^^

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?

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.

Well, there are plenty of dudes like myself to convince to drop 50 years of mature tooling support.

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.

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

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.

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.

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.

With all due respect, I said the overlap wasn't particularly large. Not that it was entirely nonexistent.

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.

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.

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.

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

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

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

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



Just to point a recent one...

Does anyone have an example of a large codebase that actually uses modern C++ to its fullest?

One of the larges codebases I know about, Chromium, seems to use only a minimum of C++ features. It's mostly limited to 1980s "C with objects" paradigm, plus smart pointers.

It's not as large as Chromium by far (~55k lines + ~27k lines support library), but I quite like the Thrill codebase. It's a research prototype (but not what you would typically associate with "research code") of a big data platform like Spark but in C++. It makes nice use of lambdas with return type deduction, some template metaprogramming in the internals, smart pointers & RAII, and generally uses lots of modern C++ features. https://project-thrill.org/ and https://github.com/thrill/thrill (disclosure: I know the authors and have worked on/with it for a bit).

Perfect, thanks! Looks like an interesting project. I've bemoaned the dominance of Java in the distributed data processing world for a long time, and I didn't know about Thrill.

> Does anyone have an example of a large codebase that actually uses modern C++ to its fullest?

The point of a language is not to use all the bells and whistles just for the sake of playing language feature bingo. The point of a language is to offer developers the tools they need to use to achieve their goals. Some C++ standards offer stuff that are must-haves, nice-to-haves, and meh. Just because you want to use std::make_unique that doesn't mean you should rewrite your code to get all your lambdas to do return type deduction.

Sorry, that's not an answer. I'm asking whether there are any projects that use modern C++ to its fullest. By fullest I don't mean using features for features' sake; that's a ungenerous reading of my comment.

> Sorry, that's not an answer. I'm asking whether there are any projects that use modern C++ to its fullest.

That's precisely the answer, because the question, as you framed it, is absurd.

The point of using a language is to benefit from the features it provides. It makes absolutely no sense to argue that a language is not used "to its fullest" if you don't play feature bingo in your projects. That's silly. I'm using C++14 to its fullest if I use std::make_unique even if I use no template metaprogramming or lambdas or even throw exceptions. It makes no sense to argue otherwise.

That's still a non-sequitur.

As an counter-example, it's possible to write conformant C++ without using any features that aren't also in C: I am, objectively, not using C++ to the fullest if I'm restricting myself to functions instead of methods, char pointers instead of std::string, statically allocated arrays or pointers instead of vectors, and so on, thereby ignoring 90% of the spec.

If I'm not using constexpr, for example, then I'm using one of less feature provided by the language. Constexpr, like all other modern C++ features not present in "old" C++, was invented to serve a purpose, and without it, you have to reach for more blunt, possibly more verbose and less expressive tools. In other words, many new features (such as ranges) increase expressiveness in a quantifiable manner. I may not need, for the specific program that I'm writing, the full range of features, and may not need constexpr. But that wasn't the question.

Again, I'm not asking about egregious use of features of features' sake. I'm asking about examples of projects that use in a positive and not superfluous terms modern features of C++.

It's not an absurd question, and your response is just obtuse (and unhelpful!).

C++/WinRT for UWP makes use of advanced C++17, not sure if that is using C++ at its fullest whatever that means.

Same thing applies to SYCL, CUDA and Metal Shaders (MSL uses C++14 though).

“I don’t believe that there is or could be a perfect programming language — at least not in the time scale we’re talking about, a few decades or a hundred years. Maybe in a hundred years, but not in my lifetime.”

Absolutely agree and wish more people did.

He talks about fixing Exceptions in c++, what is wrong with exceptions in c++ and how would you fix those? Go does not have exceptions, but I don't think Go's method of checking for error on every step and doing early returns is more elegant.

> "Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know."

While likely accurate, this thinking is likely not conducive to UX innovation.

I think you meant to comment in the Laws of UX thread: https://news.ycombinator.com/item?id=24030969

Sorry if my assumption is incorrect.

> “I think C++ can do anything Rust can do, and I would like it to be much simpler to use.”

I think Bjarne isn't getting the issue with C++. Yes they're Turing-complete, yes they can both solve the same set of problems.

The issue is that C++ can do everything that every other language can do, which means it's not a language, it's a universe of features. You make the language by picking which features, patterns, philosophies, architectures you want. It's like if a language dictionary included English, simplified Chinese and Korean.

The problem IMO is there's no such thing as C++. Each company, each team, each person has their own. Many of these C++'s are incompatible with each other.

Worse, many of the new language features can't be properly implemented because they would break someone else's C++.

The problem is it tries to be everything to everyone, and that makes it (and futures standardization efforts) full-on Quixotic efforts. I mean, by all means, have at those windmills tho.

Bjarne points out how much he hates templates, and has some great new ideas for generic programming. Lovely, but he's never gonna get rid of templates, so now we have 2 problems.

Rust actually can do things C++ can't do. People who use Turing equivalence to equate language capability are just uneducated imo.

There's another "truth" of PLs: Curry-Howard. So a language with a richer type system can express more propositions than a lesser one. Just because two languages are Turing equivalent doesn't mean they are Curry-Howard-equivalent.

So the things some languages can do that others can't happen at compile time.

And tbh, you'd probably be better served by a language that isn't Turing complete but allows you to express rich types than a Turing complete language with a bad type system. Very little of people's code needs Turing completeness.

> Rust actually can do things C++ can't do. People who use Turing equivalence to equate language capability are just uneducated imo.

This is a very myopic view, and misses the point entirely. The entire notion of a "Turing machine" is that any Turing-complete machine can compute any result that another Turing-complete machine can compute. No mention is made of how the results are computed or how the programmer approaches the problem on each machine.

Any Turing Complete language can be used to do the same work as any other Turing complete language or mechanism.

The expressiveness of any particular language does not factor into the equation at all, and does not matter at all when speaking of what is computable and what is not.

You are talking about language features, which is an entirely different topic. All Turing-complete languages are equivalent in terms of their abilities; that is to say that they can all compute the entire set of computable results.

Right I'm saying there are other theory-grounded ways of discussing language capability beyond Turing completeness.

> Very little of people's code needs Turing completeness

The Wikipedia page on Total Functional Programming [1] has a nice (even if contrived) example of this with Quicksort. I feel like my undergrad complexity class did me a disservice by emphasizing Turing Completeness so much without discussing any other aspects of abstract computation, like lambda calculus, type systems, etc..

[1]: https://en.wikipedia.org/wiki/Total_functional_programming

Can any code written in rust be transpiled to c++ without losing something?

No. There is no version of the env! or include_str! macro! in C++ (they are implemented in the compiler for Rust). These macros can be used to the get the values of environment variables or the contents of arbitrary files at compile time. You could of course implement them within a build system, but there isn't a way to replicate these macros with just pure C++ being passed to a compiler, even with pre-processor macros.

File embedding seems to have been a low priority for the standard, perhaps because there's always been workarounds, but it has gotten some attention recently with the std::embed proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p104...

If "something" includes safety and maintainability, then no.

Maintainability doesn't matter in this case. I would assume all the safety features of rust could be implemented in the transpiled code.

If maintainability doesn’t matter, what are we even talking about though? If a solution is maintainable in Rust and an utter nightmare in C++, the answer to the question is “nope” for all practical purposes.

> > “I think C++ can do anything Rust can do, and I would like it to be much simpler to use.”

> I think Bjarne isn't getting the issue with C++.

In my opinion, put succinctly, the issue with C++ is that it can do things that Rust can't. And, as it turns out, most of the things that it can do over Rust aren't important for solving problems (one of those things is explicit memory management).

> Rust people [...] accuse [...] stolen

There is something that many developers struggle with, and it seems to be cropping up here. You are not your work, folks. Go back and honestly look at your very old code, it's probably not good, it's probably not good at all. There's no reason to be ashamed of that, because your work is not your identity.

If your work becomes your identity, you lose the ability to critique your own work objectively (biologically/psychologically), which really impedes your ability to improve your work.

But do you agree that Rust stole many things from C++?

Because that was his point, the whole argument about developers identifying with their work seems to sidetrack the original discussion.

Of course Rust "stole" many things, there wouldn't be much of a language if it didn't. C++ is a crucial piece of history in the evolution of programming languages.

> the whole argument about developers identifying

Taking inspiration from C++ is inseparable from developing a language today. Arguing about who "stole" ideas is sidetracking the overall discussion, in the first place. The development of C++ is being hampered by the perception of a threat/enemy who "steals" ideas - which is a very human and normal way to act. If the discussion is "them/Rust" vs. "us/C++", then the reasoning behind that counterproductive mindset is worth talking about.

It's certainly possible to see it this way. However, I'd like to argue that there is a certain kind of value to what you consider a problem as well. Quoting Bjarne from the article:

> “But besides adding object orientation to C, he also remembered his earliest design goals for C++. “I wanted very great freedom of expression, very great generality. [...]”

I can only speak from my own experience here, so it's anecdotal, but the main reason I love using C++ is precisely this "great freedom of expression", which is most likely, but at least in part, a direct consequence of the fact that it "tries to be everything to everyone". When writing C++, my mind often wanders and comes up with code and designs that would either be actively discouraged in the majority of other (opinionated) programming languages, or straight up impossible to implement. It's a great and highly valuable (possibly creative) experience that I haven't, to this extent, experienced in any of the other (numerous) languages I've been using. I also feel it makes me a better software engineer as a whole, even when I'm not working with C++ (which is actually most of the time). Beyond that, I also feel it's one of the reasons why C++ is so successful.

Obviously it also leads to the fragmentation you described, and it's perfectly valid to criticize, but I wish people would, more often, at least acknowledge that this kind of programming language is still valuable in certain ways and situations.

Yes, if you are mainly focused on getting a job done with minimum friction (and maybe maximum speed), there is a high chance that there is a language better suited for the task than C++ in today's age. That does not make C++ obsolete, quite the opposite in my opinion. I believe the fact that C++ isn't as opinionated or streamlined as other languages shouldn't be considered an "issue" or a "problem", but a feature.

That great freedom in expression is probably what leads to many bugs from expressing things "too freely".

Generic wise phrase: Perfection is not reached by adding more and more things, but by taking things away, until only the true core ideas remain, on top of which one builds the rest.

This is something C++ is very far away from attaining. What one wants for maintainabIlity, simplicity and understandability is the core concepts, not 120 keywords and different meanings of keywords depending on where they appear.

> "That great freedom in expression is probably what leads to many bugs from expressing things "too freely".

I agree.

I'm not sure why C++ needs to attain perfection of this specific kind - or any kind, for that matter. You could also argue that the great freedom and flexiblity were preconditions for (or at least greatly aided in) the creation of languages like Rust. Through them, people learned what to be aware of; and were thus capable of "distilling" this knowledge into such languages.

My point is: there is nothing inherently wrong with a language choosing to be liberal/maximum generality, allowing for a playground on which new ideas and learnings can happen. I consider C++ to be of that kind, it has served this purpose for a long time in my opinion.

Don't get me wrong though, I'm perfectly aware of all the issues that come with it, and I'd not advocate C++ as the language of choice for the majority of software nowadays. I reject the idea though that C++ should now be considered obsolete, redundant, or anything that goes into that direction just because some people now believe to have found some kind of (final) "perfection" in new languages.

And also, there was a time where he really loved templates (hell, all of us did).

But yes, you are completely right: teams developing ultra complex languages (e.g. C++, Scala, Ada) usually fail to understand that the fact their language can do everything all the other languages can do is exactly the problem.

The value of these other languages is precisely choosing not to have certain features.

> Bjarne points out how much he hates templates

I don't think he's saying he hates templates in general:

> “I’m not a great fan of template meta-programming"

He's not a great fan of template meta-programming which is a specific use (or abuse depending on your point of view) of templates. Though it is a fairly popular use of templates now.

He‘s not British but was several years at an English university.

If I interpret this sentence with English understatement, then indeed, he hates templates.

That just seems like a big stretch. No templates means no STL. The STL is a pretty big jewel in the C++ crown at this point. No templates and no STL means we'd have some kind of container libraries with long inheritance hierarchies kind of like what we had in the 90's prior to the introduction (and implementation in compilers) of templates.

The subtlety (also missed by the parent comment) is that he specified template metaprogramming, not templates in general. As I understand it, template metaprogramming refers to deeper uses of templates to do compile-time programming.

(I interpreted his British-rooted understatement in the same way as the parent comment.)

> Worse, many of the new language features can't be properly implemented because they would break someone else's C++.

And yet, I understand where the baggage comes from. My favorite language when I was young, Python, went through a decade of stagnation because programmers couldn't be hassled to write print('hello') instead of print 'hello'. It's frustrating, but almost all languages gather baggage over time.

This comment is probably tongue in cheek, but I think the slowness of Python 3 uptake was mostly caused by a perceived lack of beneficial features to the large HPC/scientific computing crowd. Breaking syntax changes (outside some very obscure things like trigraphs) is what C++ has been looking to avoid (for good/bad).

By “I think C++ can do anything Rust can do, and I would like it to be much simpler to use.” I think he’s saying that he knows there’s an issue with the complexity of C++. See his quote “Within C++, there is a much smaller and cleaner language struggling to get out” https://www.stroustrup.com/bs_faq.html#really-say-that

Features can’t really be removed from C++ because a major advantage of the language is compatibility with existing code. However, within that constraint, C++ is driving toward a simpler, cleaner, safer dialect. It’s a hard problem.

> The issue is that C++ can do everything that every other language can do, which means it's not a language

None of statement are true...

C++ cannot do everything. C++ can do most every other "system programming languages" do, but that's by design that they are all system programming languages.

Even if C++ can do everything as other languages, that does not make it beyond a language. C++'s system is coherent. It is complicated, but no where it contradicts itself in any major fashion.

How come the "current best practice" programming model changes with every language release?

This is the main complaint with friends of mine. They get up to date on C++ whatever. Then spend a couple of years writing code in another language. And when they come back to C++ it's now C++ whatever + n and they're like WAT is this language?

That generally does not happen with other languages.

Sure it does, drop someone using Pyton 2 into a Python 3 code base, Java 8/Android Java into Java 14, C# 5 into C# 8, and watch them struggle with the modern idioms and toolchain updates.

> Many of these C++'s are incompatible with each other.

> Worse, many of the new language features can't be properly implemented because they would break someone else's C++.

Could you give an example?

One would be, some are using the new-style enums (with the unhelpful syntax "enum class") while some are using the old-style enums.

I think you are describing an interface change, which is not surprising to break existing code. If you added or removed an item, you could also likely be breaking code.

I’d love to know how he’d like for C++ to support distributed systems in broad strokes.

The first thing that comes to mind is things like gRPC or the actor model but I can’t imagine he has either of those in mind.

C++ was born for writing distributed systems at Bell Labs actually.


"The work on what eventually became C++ started with an attempt to analyze the UNIX kernel to determine to what extent it could be distributed over a network of computers connected by a local area network."

That was the only connection it had to something "distributed". In a literal meaning of the word, not distributed systems.

The problems distributed systems actually face were never addressed by C++ in any way. Something like meta facilities for implementing actor runtimes and using an actor model could be the first step, but who knows what Stroustrup was talking about, maybe it's all just marketing buzzwords useless for distributed systems, like in most languages that claim distributed systems support.

Most of my issues with distributed came from poor over the wire interop. Very crappy libs that would serialize and deserialize in amazingly bad ways. Or some descriptor lang (like idl). Then God help you if you had two different CPU/compiler platforms on both sides. JSON has in many ways filled the niche that XML was doing and RPC before it. But I had to spend so much time writing glue code just so both sides could send/recv that data.

I specifically mean what he has in mind for “But I’d like to get to not-shared memory.”

> I think C++ can do anything Rust can do, and I would like it to be much simpler to use

You're going to need to break c++ then. It is so much harder to use than Rust today, I have no idea why anyone would choose c++. The libraries argument is mute because its such a pain to use external libraries.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact