Hacker News new | past | comments | ask | show | jobs | submit login
Thriving in a Crowded and Changing World: C++ 2006–2020 [pdf] (stroustrup.com)
111 points by scott_s 14 days ago | hide | past | favorite | 137 comments

I used to be excited about learning new languages, but a few years ago I lost interest and decided to consolidate on just one language. That language was C++.

C++ gets you most of the way to Python, which is as high as you can go (cue Smug Lisp Weenies with "muh macros"). So stop futzing around, and just use C++.

All these other plethora of languages are all well and good, and I'm sure they all have their secret sauce, but is their secret sauce tasty enough to justify a switch?

Unless a language consistently allows you to do in 1 line of code what others can do in 10, then there's little point to them.

Having said that, I have recently been poking my nose into Ada for use in microcontrollers. Their notion of "tasks" seemed quite interesting. A version for AVR didn't really seem to be any better than C, just with a different syntax. The one for the Raspberry Pi Pico didn't support tasks, which took a lot off the shine about the prospect of switching to Ada for me. Maybe it's too early days for the Pico, though.

I also had a quick try at Julia, as I was interested in trying out some DSP. There seemed to be some nice features about it. It seemed quite good at arrays. You can read a binary file very easily and convert it to a different type if required. So it is still on my radar.

I use Python for quick-and-dirty stuff.

Nevertheless, C++ is basically unbeatable generally.

Exactly my viewpoint!

The industry prevalence, the community size, the installed codebase size, C compatibility, ability to write code at any level of abstraction, etc. makes C++ THE "Industrial Language" to learn.

I keep telling everybody to learn C and C++ irrespective of whatever else they might be forced to study/use since these literally gives them the ability to work at any level in the Software Stack; C is the "universal glue language" and C++ is the all-encompassing monster :-). Bored writing User mode Applications? Jump into writing Libraries/Frameworks/Kernel/Bare-metal code; all using the same familiar language and toolchains. Familiarity trumps everything else. I myself have successfully transitioned from writing Windows desktop apps(16/32-bit) to Network Protocol state machines to Kernel drivers and Bare-metal MCU code all using C/C++.

"Modern C++" (C++11 and later) has shifted the learning goalposts somewhat but nevertheless all the pre-C++11 knowledge is still the bedrock on which to build the new edifices. As a side-note, i completely disagree with people (mainly the "Modern C++" proponents) trying to divorce C++ from its C roots.

Other than C++, the only other language i am willing to spend time on from a professional/industrial pov is Erlang due to its concurrent/distributed/fault-tolerant features.

>I keep telling everybody to learn C and C++ irrespective of whatever else they might be forced to study/use since these literally gives them the ability to work at any level in the Software Stack

I would have agreed with you for many years, but I feel that we might be at an inflection point right now.

For many years, all new languages that got any traction at all were higher level, a bit (or a lot) slower, much more memory hungry than C and C++ and came with a huge runtime of their own.

These languages have largely replaced C++ for application development, but they are clearly less suitable for lower level tasks such as writing operating systems, drivers, ML frameworks, game engines, browsers, graphics libraries, embedded systems and libraries that are supposed to be usable across language runtimes.

But now there's Rust, which fixes a number of C++ weaknesses, comes with more modern infrastructure (such as cargo), and appears to have significant support within some of the largest corporations.

It's still very much an open question how this is going to end, but for the first time in my life as a professional developer (starting in the early 1990s), I wouldn't be surprised if C++ was in very gradual but terminal decline.

C++ hasn't stand still, if you are in Microsoft ecosystem, vcpkg and NuGET take care of cargo, others can make use of cmake and conan.

Then as much I love borrow checker and being safe by default, there are a couple of C++ domains where Rust isn't even a though in 99.9% of the eco-system.

Just consider that Apple has decided to create a C dialect (basically turning all the knobs to be safe by default) instead of Rust for their iBoot firmware.

>I wouldn't be surprised if C++ was in very gradual but terminal decline.

I am quite sceptical that this will ever happen. C and C++ are fated to live together and forever :-)

The "accidental" rise of Web Applications gave a fillip to other languages simply because most of the early programmers were non-CS people. But once these apps hit their limits at scale they had no other option but to fallback to C++. So most often you only have a shim/skeleton app written in some other language whereas the libraries/guts are all written in C++.

Despite the hype around certain newish languages, and their promoters' desperation to denigrate what they see as the competition, C++ usage is still growing very, very fast. In any given week, more people pick up C++ for the first time than have ever heard of the new ones.

Up until the pandemic hit, for several years running, more people attended each ISO C++ Standard meeting (in places as far-flung as Hawaii and Prague) than any previous meeting. Attendance at C++ conferences, and at the same time the total number of C++ conferences, including for smaller and smaller regions, has shot up year after year.

So any perception that C++ use is in decline, or even not exploding, is wholly a product of propaganda. C++ people code while others hype.

The jobs numbers paint a rather different picture, at least here in the UK: https://www.itjobswatch.co.uk/jobs/uk/c++.do

But that‘s not even what I‘m talking about as it merely reflects the fact that C++ has been replaced by higher level languages for development of regular business applications.

What I‘m saying is that now for the first time there is actual momentum behind a language that is a suitable replacement for C++ in its remaining core domains.

And that momentum is driven by serious computer science concerns within large companies rather than by the usual suspects when it comes to hype cycles.

I‘m not predicting C++‘s decline. I‘m merely saying that it would no longer surprise me as there is now both the substance and the momentum to drive such a development.

The top salaries listed on that page are at the very low end of what is available to experienced coders.

I switched to C# after a decade of writing C++. My productivity went up and bug count went down. The main thing I found was when looking at any particular problem I need to spend less of my mental energy reasoning about the language so can spend more on the problem at hand.

Also it seemed no matter how well I learned the language there was always something there to trip me up.

Faster build times help as well (one project went from 10 minutes to less than one whilst increasing the feature count).

I still write some C++ but only if I can't avoid it.

Agreed. C++ passed the complexity threshold (where it's "worth it") for me a while back.

I still use a subset of modern C++ when I'm doing something cross-platform, and Qt helps, but it too often felt I was fighting a war on two fronts (the language, and the problem) when I was trying to keep up. So I gave up trying. And life is a lot happier now.

As a Mac guy, I still think ObjC (yes, I know, you don't like the syntax) was pretty much at the optimal level of complexity and performance. Not as fast as C++ in general, but plenty fast enough for 99% of things. Wonderful standard library with Foundation, and ARC really works well - memory management just isn't a thing I have to think about when I'm using it.

Swift ? Well, now I'm in the "I hate the syntax" camp :) I like my code to look neat (which is easy with C++ and C) and Swift just looks fugly to me.

Having written C++ for 30 years now, which is 75% of my life, I don't disagree from a personal point of view.

However, at one point I was teaching programming at the university. At that point you realize that C++ is .. huge. It may be fine for me, but is it the right choice for someone starting out?

That said I do love new languages personally. I like to study how they do things. I found that Clojure had nearly the exact concurrency model I prefer to use in C++, and much nicer metaprogramming. As a result, I use it for all web stuff these days.

It is PL/I style of huge, however the more time I spend in other ecosystems, they aren't that small either.

I would fail a C++20 pub quizz, but I surely wouldn't fair much better if the questions would be about Java 17, Python 3.9, C# 10, .... including runtimes and standard libraries during their existence.

>"I would fail a C++20 pub quizz"

Same here. It does not preclude creating high quality products though. I learn / fish out of my memory features on on need basis. Due to writing software for the last 40 years I have very good understanding what should be available and where but remember everything in multiple languages in detail is pure insanity. And in my opinion that knowledge is not what defines being good programmer.

The thing I find almost impossible to store in my own memory is which C++ version a feature was added in, so when working on a C++14 codebase, I write class template parameter deduction dependent code and then have to check CPP Reference to see why I was wrong. I agree that memorizing gobs of this stuff isn’t important.

Same here, but also applies to other languages as well, sigh.

I think the main difference is languages like C# don't have the foot guns that C++ does. You can start using them and write reasonable code straight away. I always felt with C++ you need to know a lot before you write your first line of code.

They do actually, like semantics of variables declared in foreach loops, how closures are captured, some of the runtime changes that require appconfig settigs for the old behavior, for example.

I've never used a programming language that is as hostile to programmers who have bugs as C++.

C is worse.

I'm not sure that's true. C's simplicity helps it out here.

Ultimately when everything is on fire, what's running isn't C or C++ but machine code. So, worst case in either scenario you're looking at the machine code.

But the correspondence between your C++ and the machine code is far worse than for C. In your C program a lot of closing curly braces don't result in any code being emitted, but in C++ lots of the machine code can be attributed to the innocuous looking closing curly braces. Every local leaving scope calls its destructors.

C++ doesn't actually "de-sugar" syntactic sugar in a consistent way. So, while you know your ranged for is in some sense sugar for a traditional C-style indexed for loop, you can't show that loop and aren't intended to. But this means a further loss of correspondence. In both cases the compiler is going to emit the same code, it's not stupid, this is the same operation, with more or less sugar. But the machine code looks a lot more like the indexed for loop.

I like for each type loops, iterator adaptors, and so on, if I never write another traditional indexed for loop in my life that'd be fine, but if the world is mysteriously on fire and I need to understand why, the nice sugar is not a good model for what the machine was actually doing.

Also, template meta-programmed constants. Your C++ program may have a difficult to understand bug at compile time. Yes, the C-pre-processor is terrible here, but that's technically shared by both languages, I'm talking about constexpr template madness. For example maybe at compile time your C++ program should parse JSON and behave differently based on the results. That's a real thing.

C's supposed simplicity is wholly a mirage. "Limited" would be the accurate description.

Everyone's chief exposure to complexity is the code written in the language, where the complexity comes from the problem domain and everything it takes to wrangle that complexity with what the language has to offer. By that measure, C's sharp limits mean that your exposure to complexity is much greater in a C program than in a C++ program.

> Nevertheless, C++ is basically unbeatable generally.

If your only measurement is "how many different distinct features are specified by the language", then, well, yes ... C++ is unbeatable for the number of different ways to do one thing.

If the measurement is instead "how much effort is needed to know enough C++ to move from team to team?", then the outlook is bleak for C++. Because the language itself is so huge, everyone uses a different 80% of it.

C++ is hard to use, because to use any of it, you basically have to know all of it, which is a rather large surface area to cover.

Is there another language that requires as much language-knowledge as C++? I can't think of one.

But the proposed solution to that seems to be "learn more languages", which is not exactly effortless.

I feel some people love learning new languages, while others just want to get shit done. C++ seems geared towards the latter - I don't (always) want to futz around with a new language, ecosystem, and toolchain when I just want to get something out the door. Programming is a tool, not an end for a lot of people.

Exactly. I've been coding C++ for 22 years and feel I know less now then I did back then. The language has grown. But at the same time I feel 10x more productive in it than 20 years ago.

I respectfully disagree. Once you know the core, say 25%, which I've seen devs with 5 years experience in unrelated language pick up basics in a couple of months of full time practice, and then become pretty good at after a year, then switching between teams that use different parts of the remaining 75% is as painless as anything else. I've seen people struggle way more with differences in web development dev envs than c++ and JavaScript is supposed to be simple! (It is but all the rest of the complexity of work comes along for the ride too no matter the language.)

Of course c++ isn't the right tool for every job and as each decade passed there are more languages that do certain tasks better.

Java, C#, F#, Scala, Clojure, Haskell, OCaml, Python, Ruby,... come to mind.

Yes doing "Hello World" is much easier than C++, however when one actually dives into the ecosystem, programing culture and language improvements since they exist, then it isn't that cut clear to keep skills up to date.

Try to move someone stuck in the ways of Java 7 into a team taking full advantage of Java 16, language, runtime features and libraries.

Talking to myself, but ...

I poked around with Logo a couple of years ago. It was invented in 1967. It is a dynamic language, and actually pretty good. I remember thinking that there didn't appear to be any obvious deficiencies in the language.

Dylan is also a powerful language, heavily inspired from Lisp, but "without the toenail clippings." It tried it out, but the compiler seemed a bit flakey at the time, so I didn't pursue it much further.

Then there's Pascal. It's very fast to compile, I think chiefly because, unlike C, syntax isn't context-sensitive. Old Pascal suffered from daftness like strings having to be of pre-defined length. It got me to thinking that this might actually be a strength if you're programming microcontrollers. But anyway, this silly restriction was lifted. Pascal is a language that's very easy to get to grips with. C++ wins out over Pascal for application development because it has resource management, not just pointer management (which pascal doesn't have, either).

There's actually a project called Ultibo, which is a "unikernel" for the Raspberry Pi, written in Pascal. You can compile your own kernel using Lazarus. Getting up to speed was pretty straightforward. To mind it had a fatal flaw, though: it had a pre-emptive scheduler, and thus wasn't particularly useful as an RTOS.

What a lot of this illustrates is that anything that can be invented has been invented. Mostly, anyway. The number of programming languages has exploded over the last decade. What do the do - really do - that hasn't been done before?

Here's an idea ... if you want to create a new language, then take a working Pascal, and add your own ingredients. Its syntax is designed to be easily parseable, so you should have a good basis from which to work.

Object Pascal also has resource managment, specially the later improvements added by Delphi, and RemObjects Pascal.

Ada also has it since Ada 95.

So what would this new Pascal like version bring to the table?

"So what would this new Pascal like version bring to the table? "

The kind of thing I had in mind is for creating Domain Specific Languages - more toy systems than any new earth-shattering paradigm. It's up to the tinkerer. Like, maybe someone wants to add coroutines to the language, for example.

I had one idea in that I'd like to add a nicer way of expressing the parsing of data.

Maybe a Cobol, but nicer. Or a Snobol, but in a more general-purpose language.

Another idea is in the realm of microcontrollers. It could write start-up code for peripherals, and ensure its usage doesn't conflict. I'm not a Rust programmer, but I am aware that it is the kind of problem it addresses.

BUT, the thing about compilers is that a function call is just a function call, it has no idea of intent. By extending the language, you can give the compiler that intent. So certain functions can have compile-time semantics as well as run-time semantics. You could probably achieve the same kind of thing with Lisp.

Anything where one feels the need/desire to extend syntax, basically.

You have been able to use Pascal and Oberon for microcontrollers for years actually.



> All these other plethora of languages are all well and good, and I'm sure they all have their secret sauce, but is their secret sauce tasty enough to justify a switch?

the evidence of all the code not written in C++ and Python suggests the answer is "yes"

I've considered doing this - I spend so much time learning new languages that I am average in many but not an expert in one. However, when I look at what language to pick for that 'one', I can't decide. It's gone from Python -> Common Lisp -> Rust, etc... What are some arguments for C++ to be The One?

C++ has a great reach, from bare metal to very high level of abstraction. It can be squeezed to support almost any paradigm, oop to functional. You can make dynamic object systems, build a reflection system or a garbage collector. You can do compile time programming.

In general, a systems language is a great asset in your toolbelt. A high level one can let you shape your own environment to great detail.

In the end I think most systems languages will take you to a similar place. Many others have fewer footguns or better ergonomics than C++. Its distinctive feature/bug is having no opinion of almost anything. Or alternatively, you can find subcommunities with almost any opinion.

But is it truly practical to use in 'higher-abstraction' apps like web or mobile? I mostly work in higher-level systems programming but dabble in most areas when I want/need to.

>But is it truly practical to use in 'higher-abstraction' apps like web or mobile?

Yes absolutely. Once you become familiar with the language the barrier is not that high. Familiarity trumps everything else.

That said, since i am not a Web/mobile developer i had collected some resources to help me learn how to use C++ for Web/Mobile apps, you may find it useful;




Not really. If you want to do iOS development, there's no point in using C++. The Swift interop with C++ is very painful.

I think for Android development, the NDK support is much better and there you might be able to leverage C++ much easier.

I have been working on many mobile apps that would share a C++ model between iOS and Android, and use platform-specific code for views.

Web and mobile is possible but anyone experience in both will realise c++ is only suitable for a minor subset of these.

>Its distinctive feature/bug is having no opinion of almost anything

This single phrase has clarified the workings of the C++ standards body like nothing else; When in doubt, add it in!

History shows this to be just plain wrong. There are many examples but for example look how long doubts about concepts held back that feature.

This very submission is 160 pages documenting this very fact.

Indeed. I have a lot of sympathy for the viewpoint that c++ is a very very complicated language in it's entirety, but not much sympathy for the idea that features are added willy-nilly.

It's a product of its time, massive success, and a herculean effort to retain backwards compatibility. It can be frustrating at times but I can seem to make great things with it still.

All the coolest problem domains (embedded/robotics, games, creative content creation software, systems) run on C/C++ and will for the rest of your career. If you dual wield C++ sword and Python dagger it gets even better (computer vision)

Good point. I think the rust hype threw me off incase it's going to replace C++ but I do agree with GP in that it's probably going to be more like a C/C++ split.

This post has convinced me to look at C++ again. Last time I used it I got put off by the lack of dependency manager so linking things like Boost sucked. Any tips on a modern tool chain?

To pick on the sibiling comment, these are the C++ versions of crates.io.



Plus they can also host binary packages, so you don't have to build the world, just your own stuff.

For some of us that matters.

They certainly are package sites, but they don't seem very like crates.io

I looked at random at the "quote" crate on crates.io and, since I've heard of it and it was on that front page, the "abseil" package from vcpkg

First thing I'm wondering is, is this the thing I thought I might need, or did I mishear somebody and I wanted a different thing? Crates.io provides me detailed information about the crate in one click. Yes, this is what I hoped it was, and here's a great description of how to use it. But on vcpkg there's a single line describing Abseil, and it's cut off for some reason with no indication how to read more. Maybe if I paid Microsoft money I'd know? No idea.

OK. Let's use assume we did want this, both are clear here, crates.io gives me the text to add to cargo to use quote in my program, while vcpkg tells me to invoke a slightly awkward command to get abseil, but either would become natural very quickly I'm sure.

Now, we need a bit more information. On crates.io in two clicks I'm looking at programming documentation for quote, explaining how I should use it with working examples. In one more click I'm reading syntax highlighted source code for the actual quote! macro, in case I'm curious how that works. I am suitably horrified, I definitely want somebody else to solve this problem for me.

But on vcpkg after a few moments with no idea I realise that the Octo-cat icon labelled "Star" is a link to a GitHub repo for Abseil, and this seems the only possible way forward. Alas, the GitHub repo also doesn't really document Abseil, but it does eventually produce a link to another third party site about Abseil, and on that site I get told to install Bazel, a build system that Abseil likes so that I can get "started" learning how to use Abseil.

OK, maybe Abseil is special. Not good news, but lets try something different. What does vcpkg have in the way of Hazard Pointers? It suggests libcds. We can again get to a GitHub, which provides us with a (HTTP) link to a doxygen doc site. Clunky but functional, at least it doesn't want me to install separate build tools. I could learn how to use this, although it lacks search and the examples are poor it is serviceable.

But you're right, vcpkg can include binary packages and so you don't have to build the world and if that is all that matters you're onto a winner.

I could reply about all the issues that make crates.io a non starter for many corporations, but then this would escalate into a Rust vs C++ and better not.

I'm very far from an expert, but Microsoft has been making some nice ecosystem improvements. Check out vcpkg if you haven't had a chance to yet

See my other post in this thread for some reasons making C++ "The One" language to learn.

You mention;

>I am average in many but not an expert in one

This is exactly why i am always wary when people give me a long list of languages they "know". They may know the superficial syntax but not the commonly used "idioms" of the language which is what is necessary for fluent expression in the language. This takes time and effort which i would rather spend with a single language and try to truly "master" it as far as possible. The situation is exactly analogous to learning "Natural Languages". You may be fluent in one or a couple while knowing a few introductory phrases/expressions in half a dozen more.

That it includes almost every possible feature ever posited in a language? /jk, sort of

It's kind of a double edged sword...

Although I've been doing C++ for about a decade now, the one thing that is making me somewhat wary of its future is the difficulty of versioning key components of the language. Sure there are tricks with namespaces to version things to get around ABI breaks (to a degree; this is a world of problems), but fundamental features of the language are set in stone in a way that is very unfortunate.

The latest I've come across is the "R-value lifetime disaster". Arno gave a great talk at cppnow this year [0] highlighting this and Arthur O'Dwyer gave a great rebuttal / follow-up that is also worth considering [1]. The gist of it is that have const& also bind to r values (T&&) causes information about the lifetime to be thrown away. In reality, the "universal binding" ought to have been const&&, as that encodes "can't modify this thing" and "it may not live longer than this function call". This is quite a footgun, but I'm not sure if there's a way to change it with some sort of "language epochs", especially considering that this will have to be exposed in modules / headers so that different "epochs" don't try to link to or use each other's code!

[0] https://www.youtube.com/watch?v=sb7cj-3l1Kc [1] https://quuxplusone.github.io/blog/2020/03/04/rvalue-lifetim...

The importance of the observation is radically exaggerated.

When the compiler can see both the call site and the function definition (such as when the function is inline, or a template) it is free to ignore ABI.

If there is a break, it will either be wholly backward-compatible, so that new code can still call old functions, or be a whole separate build target, like the jump from x86 to amd64, with no possibility of linkage mistakes. (There must be people reading here who don't recall the move from 32- to 64-bit x86. It was wholly painless for programmers; not so much for OS distributors.) Imagine building for ARM today; you are at absolutely no risk of accidentally linking x86 code.

Yes when you can compile from scratch it does not matter anymore, but as you mentioned it has mostly to do with software vendors (OS distros, proprietary apps, etc). There are things that are basically disallowed for upgrades in the standard library because certain things (e.g. class member layout, default vs. empty user-defined constructor, such as the register promotion issue when pair<> was '=default' from the empty constructor).

I think Marshall Clow gives a pretty good overview of the ABI issues at a high level [0].

[0] https://www.youtube.com/watch?v=-XjUiLgJE2Y

I looked at job boards last month and didn’t come across a single posting for c++ developers outside of gaming. What sorts of companies hire c++ developers and what do you build? Are the pay and career respects as strong as web focused options?

I really enjoy c++, or at least the subset I used for my game last year

The highest-paid programming jobs are all C++, and will be for a long, long time.

But job boards are not the place to look for those.

> The highest-paid programming jobs are all C++, and will be for a long, long time.

Not supported; argumentation by mere assertion.

> But job boards are not the place to look for those.

Yeah, we gathered that from the GP. Supporting your argument would require not just repeating where the proof isn't, but showing where it is.

The software development community is connected globally and there's doubtlessly a common culture which is shared between software developers which visit social networks like HN, github, reddit, etc. One aspect of this culture which bothers me in particular is the idea that learning programming languages is unconditionally good.

I've focused on C++ and Python, but never used the latter for big projects and even that showed. I had to reach for the docs more, I had to look into idioms or patterns more for Python whereas my C++ flowed.

While it took me maybe one or two weeks to become familiar with the syntax of a language and write reasonably idiomatic code, it took months to really grasp the ecosystem and more than a year of work in that language to use it like a native and develop expertise in it.

The languages which I've had to learn for specific projects, such as Objective-C, Java or C# have been mostly forgotten. There's a very strong correlation there with the size and length of the project. I think some knowledge is still there and I would be faster to reach competency if I had to use them again, but I would in no way claim to know for example Objective-C now.

Now that I haven't programmed seriously in about two years because of a role change, I can definitely see the impact on my C++ skills: I don't know much about C++17 and up and I've started to find code harder to grasp. Not individual pieces of code, but rather the whole, as if when I step back I no longer have an intuitive grasp about it. I find some language constructs ugly and confusing and no longer feel so attached to C++ or even programming surprisingly enough. Ironically I've been doing some data science stuff in Python, so my skills are pretty much the same there.

I don't like learning programming languages unless I also get something else in return for the time invested. For example I've found an interesting book about systems programming (Rust in Action), so I'll recap my systems programming and also learn some Rust on the side. Pure language books like Programming Rust, even if targeted at C++ programmers and otherwise good do nothing for me. I'd rather learn more about the software/hardware areas I'm interested in.

> One aspect of this culture which bothers me in particular is the idea that learning programming languages is unconditionally good.

Stated exactly like that, yes, that's probably not a good idea.

Stated like "learning new programming languages that are significantly different than the ones you already know is unconditionally good" - that's very close to truth.

The languages you named are Objective-C, C++, Java, C#, and Python. From my perspective, those languages are so similar as to be almost the same.

Learning Red, Io, (a) Lisp, Prolog, Smalltalk, Curry, TLA+, Coq/Lean (or any other theorem prover, actually), Erlang, or (a) FORTH will actually give you an experience that's significantly different than anything else you've used before, with accompanying new ways of thinking that you can apply to your other languages and projects.

100000%. As I mentioned in another thread on this post I was going to take a look at C++ again and since then started playing about on a little game. Almost immediately I approached the problem like Haskell and started passing data as GameState{} structs between pure functions. Using other languages for enough time has made me avoid global/mutable data like the plague and I _think_ I'm a better person for it.

I'd add an array language like APL or J to that list. Idris is worth mentioning, but maybe Curry+Coq cover that space. Maybe Icon too.

Concepts, Techniques, and Models of Computer Programming [1] with Mozart/Oz covers a lot of ground by itself.

[1] https://www.goodreads.com/book/show/772585.Concepts_Techniqu...

That may be, however I'm not looking for experiences when learning software engineering topics. Instead I want something that fits together with my existing knowledge framework and delivers significant benefits.

Programming languages are table stakes and they compete for attention with the things which do matter in a project, like the social aspects and project management, team skills, development ecosystem and domain knowledge among others. Having for example deep knowledge the kernel would be more useful to me than all of the languages in your list combined.

Agree with all your points.

>While it took me maybe one or two weeks to become familiar with the syntax of a language and write reasonably idiomatic code, it took months to really grasp the ecosystem and more than a year of work in that language to use it like a native and develop expertise in it

Very true. I am always mystified when people tell me that i should be able to "pick up" a new language in a couple of weeks. I find learning even a so-called "easy" language like Python somewhat "difficult". Unless i read/write a lot of Python code there is no way i can get fluent in it to feel comfortable with it.

Thanks for the mention of Rust in Action! I am curious about how you found you discovered it.

I like to browse the catalogues of various publishers that I consider of good quality and look for interesting books. Another one that caught my eye was "Rust for Rustaceans" (still in development), which admittedly is a pure language book, but it describes more specialised topics, which aren't typically found in regular books about Rust.

C++ is great, but requires a lot of work to get some things you get in Python for free, such as duck typing and monkey patching. These are really nice things to use in a web framework, which is why Python web frameworks seem to do so much more than C++ web frameworks (they do the same amount, but in C++ there's a lot more boilerplate to set up the framework).

I, and the company I was at, switched from C++ to Java in the 1990's, and garbage collection was a major productivity boost. Lately it's been Python and JavaScript. Has C++ come up with ways to help with manual memory management, to make it as convenient as garbage collected languages, or almost as convenient?

Programming in C++ today is very little like C++ in the 90s.

No one coding modern C++ feels any envy for other languages' GC.

Yes, modern c++ code wont have manually deleting objects in memory.

Julia has macros too yknow

Why C++ over Rust? I’m genuinely asking, not trying to evangelize.

I'm not the parent poster but I think this question might be more interesting in 10 years when rust possibly has a larger industry foothold? I agree and I am actively trying to move my career from C++ towards Rust but its slow and Rust isn't particularly heavily used outside of crypto, which is something I am not interested in, from looking at openings for Rust over the past year. I do think it is great that larger companies like FB/Microsoft are now starting to invest in the language though.

My biggest issue with C++ is that although it does seem to be adding lots of good quality of life changes with the recent standards for developers it has inherit flaws that without breaking backwards compatibility it can never be as safe as Rust. And I think C++ is probably right to not break backwards compatibility, it has too large of a user base that will most likely splinter, it reminds me of the python 2/3 problems.

If we are being honest, there is no actual competition between C++ and Rust. Rust is a darling of HN, but practically unheard-of outside these four walls. C++ is the workhorse of industry, and it will be for many years to come. The difference between last week's population of professional C++ coders and this week's is larger than the total number of professional Rust coders. That will be true next week, too.

At this point, it appears that Rust could well survive and become a mainstream language, eventually, but that is by no means assured. While that puts it well ahead of any other language created in this millennium, it is very far from ready to raise a family on.

Remember, Ada had far more investment and industry backing than Rust will have for a long time to come, but was wiped out. Fighter planes are coded in C++, not Ada.

I'm not sure where this perspective comes from. Rust is growing extremely quickly, far outside the HN bubble.

Rust is used by, and financially supported by, many of the learning companies in the technology industry: Microsoft, Google, Facebook, AWS, Dropbox, and others. It's being piloted for use in the Linux kernel and is already accepted into Android.

Unlike Ada, its development was never bootstrapped by public funds and so all of its growth is due to its practical benefits.

I don't know why fighter planes are the standard to reach, but Rust is even being used in aerospace: both Rocketlab and SpaceX have made public statements supporting Rust or are hiring people with Rust expertise.

Rust usage is growing pretty quickly, a lot like C++ at its age. "Extremely" is a meaningless term in this context.

"Used by <Big Company>" means much, much less than most people who mention it believe. The bigger the company, the more likely it is that they use literally anything at all you can think of, and the correspondingly less it means that they do. They might even be using it in a certain project deemed strategic. But we all know how many of even "strategic" projects at big companies end up canceled, even when they seemed to be a success. You can be certain that they are not using it for anything central to how the company makes its money.

It is more interesting when a $company uses $newtech where it will only have an income if the project succeeds. But you probably never heard of $company, otherwise, so have no way to evaluate how important it is.

SpaceX has said publicly it uses C++ for mission-critical work. Like other $billions companies, they do a lot of things. Saying they do Rust, too, makes them seem edgy in circles where people are likely to hear about it, regardless of how much they actually depend on it. So it is really hard to tell.

Absolutely valid points. I'm definitely inside the filter bubble wrt Rust. It will be fascinating to see where things will be by 2030.

For me it was exactly the other way around, focused exclusively on C++ for almost 20 years, and then eventually got fed up with where the language was going post-C++11 (basically: let's try to cram every feature from every language ever into C++). First I "branched out" to Python for cross-platform scripting stuff, then rediscovered C99, and now I'm keeping a close eye on the new small languages that have been enabled by LLVM. Of course I still also code in C++ when needed because a lot of libraries are written in C++, and most of my current projects end up being a mix of C and C++ code, but C99 is just so much more enjoyable that I prefer it now over C++ as the "top-level" language in a project, with the C++ parts wrapped away under C APIs.

TL;DR: I think it's not healthy for a language to try to do everything.

PS: Learning and regularly using other languages also feeds back improvements into my C and C++ coding.

C++ is moving a bit fast these days, isn't it? What I really like(d?) about systems programming and C++ is that the time invested accumulates and one realizes that they can achieve mastery or something close to it. If you look at JS for example, it's like starting over every 2 years.

See, that's where the "++" part of C++ comes in. They give you an extra year before you have to start over!

/s (in case anyone couldn't tell...)

At a 168 pages, I only had time to skim it, but this was much better than I thought it would be. He honestly addresses many of my complaints about C++.

In the discussion of variant, optional and any: - He bemoans that "The possibility of direct language, as opposed to standard-library, support appears not to have been seriously considered" - He acknowledges that "variant and friends address an important problem, but inelegantly." - He considers variant, optional and any a "stop-gap measure" - In discussion of a pattern matching library he acknowledges the need for "both closed sets of alternatives (algebraic types) and open sets (class hierarchies)." and explicitly says the aim is to remove the visitor pattern (whereas c++17 just added std library syntax for it)

In the modules discussion (9.3.1), he also identifies the problem that "[the hello world program] yields 419,909 characters for the compiler to digest". I wish he'd also address visiblity specifiers at a module level, rather than just at a class level.

In the static reflection discussion (9.6.2), he discusses the typical problem of iterating over members of a struct. This is indeed a point where C++ has not really progressed much since ANSI C.

The discussion of error handling in chapter 7 felt a bit lacking. My main problem with exceptions isn't performance, but that I can't determine if I've handled all error conditions. The idea of using exceptions for non-local errors and error codes for local errors is too vague. It also doesn't really make error codes much easier to use. For my money, I still think that using error codes and providing syntactic sugar for dealing with the common boilerplate is the best compromise. I can accept exception/panics when they are not supposed to be caught, but just cleanly terminate the application.

Maybe C++ will solve these problems in the future (C++23? C++26?), maybe not. In the meantime, the new languages on the block are attractive because they solve these problems _today_.

I find it surprising that anyone could imagine that the creator of C++ is unaware of its issues.

I’m sure he appreciates them better than almost anyone else and would be the first to acknowledge them.

But compromises have to be made to create a useful langague and path dependency means that sometimes the sub-optimal long term choice is still the right choice to make right now.

> I find it surprising that anyone could imagine that the creator of C++ is unaware of its issues.

While C++ adds a lot of new features, it does very little to solve the problems inherited from C. The lack of static introspection, a real module system and tagged unions are all inherited from C. I do think it's fair to think that if a problem is not addressed in 30 years, it just might not be considered important.

Adding tagged unions is not a sophisticated language feature. Fat pointers (c++20 std::span) also seems like a no-brainer. Maybe I'm biased by hindsight, but these features were implemented by contemporaries like Pascal?

Actually, the paper also contains a great section about fat pointers:

> The obvious solution is to supply an abstraction that holds a pointer plus a size. For example, in 1990, Dennis Ritchie proposed that to the C standard committee: "'fat pointers' whose representation will include the space to store the adjustable bounds at run-time" [Ritchie 1990]. For various reasons, the C committee didn’t approve. At the time, I heard the priceless comment: "Dennis isn’t a C expert; he never comes to the meetings." It is probably good that I don’t remember who said that.

We are on the early days of module system, but it kind of works, at least on VC++.

You can get tagged unions via std::variant.

It's more the attitude of various creators. Some have a jobsian "this is how you should do it"; others frenetic, "next time it'll be perfect", others, "you dont really need this!". Etc.

"but inelegantly."

Yes. Bjarne an co. are reluctant, with good reason, to prefer to extend C++ with objects rather than syntax. The reason being: if you've goofed with your object design, everyone can simply ignore the object, but if you've goofed with your syntax, then you've committed everyone for all eternity.

Dealing with variants via the visit() mechanism is pretty verbose, and I couldn't help but think that a nice bit of syntactic sugar wouldn't go amiss there.

I was interested in the new coroutine feature in C++. That would seem like a fantastic feature to use on microcontrollers because it implements cooperative multitasking.

But aye carumba, The tutorials I've seen on them have blown my mind. Overcomplicated much? I wonder if, at the end of the day, coroutines are fundamentally incompatible with the notion of a stack, and that you're always going to be trying to nail a square peg into a round hole if you try to do it.

The co-routines design is actually quite similar to C# and Kotlin machinery, although many don't realise it.



It gets a bit easier on them thanks GC, but in the end implementing custom co-routine types is of similar complexity level.

> I wonder if, at the end of the day, coroutines are fundamentally incompatible with the notion of a stack

Well it is with stackless coroutines (by definition) but they are a kind of state machine. Without a stack or heap as an escape hatch they are quite limiting (as in they aren't Turing Complete by themselves). Stackful coroutines are much more powerful and give you pretty much every kind of control flow you need (while still being strictly less powerful than continuations).

It is possible for a compiler to detect whether a coroutine should be stackless or stackful, in principle at least.

> Yes. Bjarne an co. are reluctant, with good reason, to prefer to extend C++ with objects rather than syntax.

I think you either meant to elide "reluctant", or to say "syntax rather than objects".

I think I'd like C++ much more if it had a proper package manager. I know there's Conan and a few others but having an official way to install a library would be so great. I recently got back into game programming as a hobby and dusted off some of my old C++ projects from 2010, and while I was able to get them up and running again (which I guess speaks for C++ as well) it was pretty painful and involved downloading and installing several packages by hand.

Using languages like Go, Python or Javascript feels much more seamless as you can just say "pip install ..." or "npm install" or "go get ./..." to install all your dependencies (there are pitfalls there as well).

I've seen this complaint a lot, but I don't get it. For C++, the system package manager (yum, apt, pacman) seems sufficient to install most anything I've ever needed. Are you programming under Windows?

My biggest complaints about C++ generally revolve around all the inconsistencies / special cases, and I believe these are mostly in the name of backwards compatibility. For any of the major compilers:

- Integer literals are 32 bits, even on 64 bit platforms. You almost always want a ssize_t, but you get an int, and int is almost always 32 bits. (let's dodge the religious war about unsigned vs signed)

- String literals are basically const char star pointers, but you should hold them in a string class.

- Even the syntax for declaring a variable is a total mess. Depending on details about foo (initializer_list, POD type, explicit constructors, etc), there are a lot of special cases in the following:

    foo x;          
    foo x();         foo x(1);         foo x(1, 2);
    foo x{};         foo x{1};         foo x{1, 2};
    foo x = {};      foo x = { 1 };    foo x = { 1, 2 };
    foo x = foo();   foo x = foo(1);   foo x = foo(1, 2);
    auto x = foo();  auto x = foo(1);  ...
For some of those, you can't even know what's really happening unless you know the specific implementation of the type/class. And as a special bit of trivia, one of those doesn't even declare a variable.

- There are a lot of special cases and non-obvious idioms around declaring constructors and assignment operators.

I think it's too much to remember all the rules, so most everyone is forced to find a subset of the language out of necessity.

> For C++, the system package manager (yum, apt, pacman) seems sufficient to install most anything I've ever needed

The system package manager installs globally and prefers dynamic linking. This makes it generally impossible to distribute software reliably without packaging it for the system package manager being used. Dependencies should be local to the project and prefer static linking to avoid deployment/distribution errors.

The talk at HOPL 4 by Bjarne: https://www.pldi21.org/prerecorded_hopl.5.html

The whole event and conference is full of other interesting talks too:



I recently wanted to get back into C++ but on closer inspection, found it so thoroughly modern than it didn't really tick the sentimental box I was looking for. So I starting writing C again, and it's been weirdly enjoyable.

I still think if I were a young programmer somehow in the position of having to make a career bet on a single language, it'd be Rust. But I'd respect anyone who picked C++.

A well articulated paper by a great thinker.

That said, switching from C++ to Go made my life so much easier and more enjoyable that I do not see myself going back to that language ever again.

I tried Go and I have an opposite experience. To me Go looked like a very limited, incomplete and non-principled language that makes easy things look easy but hard things ugly or (near) impossible. I put it on the same shelf as Python and Basic. Things like using product type instead of sum type for returning errors really put me off.

But that's probably due to past experience and personality type. I mostly enjoy working in powerful and expressive languages: e.g. Rust, Scala, C++.

// edit: oh, someone have already said that: can't love Rust and Go at the same time ;)

> Things like using product type instead of sum type for returning errors really put me off.

Can you share some practical use cases where the sum type has an advantage? Personally I find go's explicit error type, along with the convention of it being called err everywhere to be really helpful and clear when working through the control flow of a program.

What does a more "powerful and expressive" language give you day to day that golang doesn't? (Generics being the first obvious example, but I have to agree that there are a handful of use cases where they're useful)

A product type forces the language to have a special "invalid" state for every type like Nil, and this reminds me of all the problems related to null handling I know from java - like forgetting to check for null / Nil.

A product type also allows returning weird states: no error and no value, or both error and value. I strongly believe that invalid states should be unrepresentable, rather than allowed by the type system and then fought by discipline and tooling.

Also, if there is actually an invalid state for the result type, and your type system has a sum type here, it can implement the sum type by overlaying it, producing machine code that's just as nice as for old school C or C++ programs yet programs that have readable sum types. The actual best of both worlds.

Rust for example promises that Option<NonZeroU32> is the same size (four bytes) as u32, even though it has much more appropriate semantics for some cases. I can't accidentally end up with a zero where I wanted anything else, and I can't easily forget to handle the None case where there wasn't a non-zero answer.

The return types of fallible functions map naturally onto sum types. By using product types instead there is a semantic mismatch. You get an error and a value but only one of those is valid. So you need to follow certain code idioms to get back the sum type semantics whereas this is something the type system could handle for you. Go's reasoning for that might be that they didn't want to have the complexity of sum types in the language, which is fair but is a tradeoff.

There are probably dozens of us that really appreciate his clarity and writing and even his overall design goals for C++, but the language is so inherently loaded with historical baggage, that it is only pragmatic to use newer languages that learn from those successes and mistakes

However, I've heard, but can't confirm so don't quote me that it is impossible to appreciate Go and Rust at the same time.

Those newer languages will earn their share of historical baggage in time.

C++ has the distinct ad/disadvantage that it inherited 15-20 years of baggage from C, as well as carrying 20-30 years of its own.

>Those newer languages will earn their share of historical baggage in time.

For some reason this truth seems to escape most new language fanboys, in particular; the Rust crowd on HN.

Languages like Rust and Scala learned they lesson: they don't add features, but also remove or fix features. This is why you have editions or major versions, which are not 100% backwards compatible. E.g. Scala 3 comes with a major redesign of implicits, instead of adding a new way to do the same. Same for Python 2 vs 3.

The biggest reason C++ and Java accumulate historical baggage is fixation on near 100% backwards compatibility. E.g. Java 5 added generics, but had to allow using non-generic erasures (List instead of List<T>) so older programs could still compile and run. And now we have to live with this ugliness even in Java 16.

Of course dropping backwards compatibility causes a bunch of problems of their own and it is better to try to minimize the impact (Rust editions, Scala 3 vs 2) rather than do a big bang (Python 3 vs 2).

>The biggest reason C++ and Java accumulate historical baggage is fixation on near 100% backwards compatibility.

Exactly! My argument is that once a language becomes "successful", whether it is designed in or not, it is an inevitability. As an example all my code/knowledge/skill of pre-C++11 is still valid with any C++ compiler toolchain today. This allows me to accumulate new knowledge at a sustainable pace as my needs and applications demand it; the language adapts to my need rather than the other way around.

The key to editions is that they don’t “drop backwards compatiblility”. We have to keep lots of things around forever! They let you opt in to small forms of backwards-incompatible changes while retaining inter—edition compatibility. This means they are backwards compatible in the strict sense of the term.

There are a few other cute tricks (not all of which were in Rust 1.0) to enable this.

Rust's "raw" way to spell all symbols is clever. Maybe some day my function named weigh will be a problem because of a new "weigh" keyword. Rust gets to add the keyword but still talk about my function in new editions by just spelling the symbol awkwardly, as r#weigh. This forbids Rust from reserving such spellings (e.g. "r#weigh") as keywords themselves, but that would be so ugly nobody would want to do it. Overall the result is Rust 2021 could even make "new" a keyword if it wanted to, and the old code which uses that symbol name everywhere still works, it's just a little clumsy to talk to it from next edition code.

Still, I think it's worth remembering that the edition changes in Rust so far have been much smaller than many changes contemplated for C++ Epochs (or any hypothetical actual C++ feature similar to Vittorio's proposal in spirit).

C++ has a lot of problems, and understandably Epoch proponents want to do stuff like ban implicit narrowing coercions, or change how overflow works. Because of how sprawling C++ is these are surprisingly big changes to the whole language, and I don't think that you could pull off something like that with editions.

I have a hopeful note though. Maybe C++ can inspire a much more powerful tool than editions, somehow enabling backward compatibility for C++ while also allowing new C++ to be written exclusively in Stroustrup's "subset of a superset" that keeps most of C++'s strengths but loses so much baggage like implicit coercions everywhere. If it's possible, the C++ community have the right people.

Example, comparing C# 10 with C# 1.0, or Java 17 with Java 1.0, including the underlying runtime changes and multiple implementations during the last 25 years (for Java, 20 for .NET).

C# has grown quite large over that period however there are large areas of the language that you can safely ignore. Your code might not be as elegant but you won't get tripped up like you would if you don't know C++ well enough.

In which C# version have the foreach variables changed their semantics?

Just an example of a possible C# pub quizz question, I have other possible ones.

I think it was 4.0 from memory.

I'm not arguing that you don't need to think about your code. The early behaviour was what I would have expected, the change was sensible but it's a long way from what you have to deal with in C++.

My experience with C++ was a lot of study and practice before I started my first project whereas with C# I was able to dive right in to a substantial piece of work and learn the language along the way.

Another example on how learning the language along the way gets to unexpected results, memory leaks in event handlers, or how HTTPClient doesn't really handle connection pool the way it should in the .NET Framework variant.


There's plenty of people that will argue that Go's historical baggage is in the form of being primitive, and Rust already is a large language. That's the fun thing about these design discussions.

Oh, it's absolutely possible as long as your brain is flexible enough to appreciate both minimalist and maximalist language design. Same goes for C and Rust.

Honestly, I use go for things I wouldn't use c++ for even if I had the choice. Do I want to do some file wrangling, text manipulation, async or web api calls? Even the "nicest" of c++ libraries (manu of which are poor wrappers around a C library) are really poor ergonomically where go takes the biscuit. I definitely don't see myself writing gameplay code in go though

I wanted to like Go but to be honest it really seems to be trying hard to be unlikeable.

Rust has some weird corners, but it seems they're good at explaining things.

Go tries to make some things easier (though, sure, still easier than C++) but they make it in a opaque or weird way.

Some changes also seem to change too fast, but that might just be me looking from the outside

Reading some comments here frustrates me out how a lot of people still put C and C++ in the same play field. 20 years ago, when you could consider C++ as a "C with classes" that was almost OK, but today they are way too different to consider them as the same thing.

That said, personally, I am still comfortable and productive writing C code, but C++ has been a no-no since C++14. But that's just me and my point is: people should stop saying C and C++ are similar.

At 36 now, C++ has aged extremely well. Perhaps not to everyone's taste, but it remains an exquisite, high-precision tool one could do anything with. Boost, a set of libraries, is a good testament to how much can be accomplished given just enough ability to create abstractions, and few languages can compare with C++ in that regard - especially taking into account runtime costs (C#, for example, heavily relies on reflection).

As someone who has invested heavily in C++, and really likes the how modern C++ has evolved, I actually have a hard time imagining myself ever starting a new project in C++ again. It's not that I can't write very reliable code in modern C++, because I have and still do. It's just that the amount of effort involved in doing so is high compared to something like Rust. A lot of the cognitive load is shifted to the compiler. I've worked in so many existing C++ code bases where I had to spend my time tracking down bug after bug because the people that wrote it weren't very skilled at C++. Rust has its problems too (dependency tree bloat, slow compile times, steep learning curve, immaturity...), but one thing it does is makes all programmers much less likely to write bugs that aren't simply logic errors. And in a team, that's a HUGE win.

I have based my career on top of C++/backend/soft-real time systems.

I still have to read the full paper, thanks for the post!

Many people rant about C++, but, IMHO, overall, taking into account ecosystem, tools, etc. C++ stands as an almost unbeatable technology when you put everything together. The language has quirks, asymmetries and all of that. C++ lives the curse/blessing of C compatibility.

But since C++11 it is nicer to use and all the standards after it have been improving on it: generic lambdas, move semantics, structured bindings, string non-template parameters, constexpr and consteval, decltype, auto, concepts... and now the C/C++ ISO committees seem to be more coordinated: seems they are proposing subsets like attributes, lambdas or nullptr into C, directly, and bool and others. It is amazing what you can do with C++ that is difficult or almost impossible to do with other languages, and you have basically all C interfaces available, which are the base of so many libraries since C is basically how you interface native code from almost everywhere.

On the missing pieces I would mention that you need to use macros to have some kind of reflection for members and pattern matching and networking would be really nice to have. Also, resource embedding could be better (#embed and std::embed seem to be trying to solve this). Also, user-defined attributes for things such as struct MyType { [[serializable]] int myInt; ... } would be really nice and it works well in languages such as C#, Java and D.

Modules are still an experiment implementation-wise, but hey, they will improve on the side of hiding implementation details by a big margin and have a lot of potential.

As for the ecosystem, nowadays you have CMake (whose language sucks badly) and Meson (which I personally love). Together with Conan package management things have improved a lot since I started coding in around 2001.

Pack that with an IDE like CLion or Visual Studio + Resharper or lightweight IDE (Emacs + Lsp and the like) and you have an environment that is very competitive and whose code can be compiled almost anywhere. From ARM to x86, MIPS and even Webassembly.

That is why I think C++ is still the way to go if what you want is performance: you also have interfaces such as OpenCL/GL/Vulkan/SIMD libraries (though not C++ standard) where you can access hardware. Also, vendors and open source have things such as https://github.com/cginternals/glbinding or https://github.com/KhronosGroup/Vulkan-Hpp which help quite a bit and always oriented towards C++. It seems that C++ is becoming the natural child of C for inheriting graphics programming and some of the embedded area, though C is still king there. Or look at https://github.com/VcDevel/std-simd to access SIMD.

If you want GUIs, same, you have at least (but not only) Qt or WxWidgets.

Want to interface scripting? Pybind11, Boost.Python, WrenBind17 for Wren, Sol2 for Lua... and all things that interface to C work also if you feel brave...

I really think that when it is about getting the job done... C++ goes a long way towards the task.

This is my 20 year experience of C++, almost 13 of those years professionally. Now, back to read the paper. :)

Just started reading it, but I noticed that in the chronology, in 1979 for C with Classes “public/private” is listed. Was “protected” a later addition?

This document says that "the language was updated again in 1989 to include protected and static members, as well as inheritance from several classes."


Does anyone know if Stroustrup has spoken in detail on Rust, the current most likely long-term replacement for C++?


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

Taken from https://thenewstack.io/c-creator-bjarne-stroustrup-weighs-in...

> Pramod: Any newer languages like Rust or Go interests you?


> Bjarne: Yeah, I look at new languages roughly all the time. You learn something every time. It is interesting but as I said I’m more of a systems guy than the languages guys. I probably look less at languages than you’d think. I look at what I think is interesting, I try them out but what I really do is to look at what problems do my colleagues and students have and how do I solve them.

Taken from https://mappingthejourney.com/single-post/2017/07/29/intervi...

As for Rust being a long term replacement for C++, just think how C++ dominates the Apple, Google, Microsoft, NVidia, AMD, Playstation, Switch, HPC, HPF, games middleware, LLVM and GCC ecosystems, and how after 40 years there are domains C++ has failed to take away from C despite being a much better and safer language.

Rust and C++ will co-exist for many decades to come.

Wow, I had always believed this about him, and it turns out to be true:

> I probably look less at languages than you’d think. I look at what I think is interesting, I try them out but what I really do is to look at what problems do my colleagues and students have and how do I solve them.

He ignores prior research, and keeps piling disjointed ideas on top of each other in the hopes that some will stick.

Completely opposite to someone like Rich Hickey, who picks up all the years of research and tries to put it all together in a coherent whole.

I tend to appreciate the latter approach a lot more.

That is a very uncharitable interpretation of what Stroustrup said. It seems you had an opinion and retrofitted the interpretation of what he wrote to fit your opinion of him.

> Stroustrup: I probably look less at languages than you’d think. I look at what I think is interesting, I try them out but what I really do is to look at what problems do my colleagues and students have and how do I solve them.

> You: He ignores prior research, and keeps piling disjointed ideas on top of each other in the hopes that some will stick.

I'm sure I'm not the only one with that opinion.

The proof is in the pudding - just have a look at C++.

Linus won't touch it with a 10 foot pole.

It is telling that you did not provide a more charitable interpretation despite feeling so strongly about my comment. I wonder what a more charitable interpretation would be.

Not sure how this is relevant

It's a project started by Linus, and written (AIUI, at least in part) in C++.

Bjarne has the vote of 1 person at ISO, Rich gets to decide how Clojure looks like, it is not the same.

Yep that’s why Clojure is dominating the software industry. Not.

You must have very high opinions of PHP and COBOL.

The conversation was about technical merits, not popularity.

The perfect language used for nothing is not worth much. PHP and COBOL have a real impact on the world and therefore deserves credit. Would I program in PHP and COBOL if I had a choice? Nope. But that doesn't change the fact that PHP and COBOL are languages that have proven themselves in the real world.

What makes you think that rust is a long term replacement for c++? I'm neither a rustacean or a dogmatic c++ follower, but it'd pretty clear to me right now that rust isn't going to replace C++.

There is so much inertia in the field with both existing projects and new projects being written on C++, what seems more likely is you end up with a split akin to C vs C++

The success of Rust in industry depends on how it fares in the Linux kernel, IMO. C++ was never even considered for that.

If I was a young dev learning a systems language for the first time, I'd most likely pick rust.

C++ isn't exclusively a systems level language either though, lets be clear. Assuming rust eats all the existing C code in the various kernels (MacOS, BSD, Linux, Windows), that wouldn't mean it's replaced C++ at all - it would have replaced C.

C++23 is the current most likely long-term replacement for C++.

Applications are open for YC Winter 2022

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