Thriving in a Crowded and Changing World: C++ 2006–2020 [pdf]
stroustrup.com
stroustrup.com
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.
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 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.
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 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++.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Ada also has it since Ada 95.
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.
the evidence of all the code not written in C++ and Python suggests the answer is "yes"
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.
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;
https://levelup.gitconnected.com/cross-platform-mobile-and-w...
https://github.com/Microsoft/cpprestsdk
https://medium.com/@ivan.mejia/modern-c-micro-service-implem...
I think for Android development, the NDK support is much better and there you might be able to leverage C++ much easier.
This single phrase has clarified the workings of the C++ standards body like nothing else; When in doubt, add it in!
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.
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?
https://vcpkg.io/en/packages.html
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.
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.
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.
It's kind of a double edged sword...
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...
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.
I think Marshall Clow gives a pretty good overview of the ABI issues at a high level [0].
No one coding modern C++ feels any envy for other languages' GC.
I really enjoy c++, or at least the subset I used for my game last year
But job boards are not the place to look for those.
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.
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.
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.
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...
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.
>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.
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.
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.
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.
"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.
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.
/s (in case anyone couldn't tell...)
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_.
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.
https://devblogs.microsoft.com/premier-developer/extending-t...
https://kotlinlang.org/docs/coroutine-context-and-dispatcher...
It gets a bit easier on them thanks GC, but in the end implementing custom co-routine types is of similar complexity level.
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.
I think you either meant to elide "reluctant", or to say "syntax rather than objects".
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.
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.
You can get tagged unions via std::variant.
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).
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); ...
- 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.
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 whole event and conference is full of other interesting talks too:
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++.
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.
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 ;)
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 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.
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.
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.
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.
For some reason this truth seems to escape most new language fanboys, in particular; the Rust crowd on HN.
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).
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.
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.
Just an example of a possible C# pub quizz question, I have other possible ones.
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.
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.
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
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.
> 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.
> 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.
> 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.
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.
The conversation was about technical merits, not popularity.
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++
If I was a young dev learning a systems language for the first time, I'd most likely pick rust.
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. :)