C++20 has been approved
twitter.com
twitter.com
Nowadays I am using C++ mainly for the high-performance libraries, and only if I can't archive the same in jit-ed python, cython or rust.
The Java strategy of being very conservative about what you add to the frontend would have done C++ a lot of good after C++11 (or even before that).
Sticking to plain C has the advantage of probably being the subset of C++ (I know, it’s not technically a subset) that’s in widest use.
Is it not? I thought C++ was explicitly a strict superset of C?
More importantly, though - the syntax is not what matters. The languages are very very different in idiomatic use. You just don't write programs the same way with C and with C++. And the gulf between the two only expands with time. A decent C program is almost certainly a poor C++ program, in terms of idioms, utilization of library facilities, and sometimes even in terms of performance (!).
Look at for ex. what const means in each, or auto. Or variable length arrays (feature that doesn't exit in C++). Or designated initializers that C++ didn't have for a long time.
Here is a good list of differences: https://mcla.ug/blog/cpp-is-not-a-superset-of-c.html
There are plenty of legal C programs that aren't legal C++ - if for nothing else, then because C++ has more reserved keywords which are perfectly legal identifier names in C.
E.g. this is legal C but not legal C++:
int template = 10;
I prefer using C++ like "C but with cin and cout" and I informally call it C+ :)
And C tends to reinvent object oriented programming with each library so you might as well use language defined classes.
So I don't really see the point.
You don't need to use stuff like concepts, or "showing off how smart I can be with template libraries" (looking at boost), but C++ has a lot of features that make it much more productive than C.
Garbage collection, big runtime, and non-zero-cost FFI are acceptable trade-offs in many areas of programming, but they are deal-breakers for domains where C (or Rust) is necessary.
Rust is somewhat similar to C++ in the feature set, but not in complexity. Rust's features are more orthogonal, without duplication and backwards-compat warts, and you get hand-holding by the compiler.
Technically you could be right about complexity vs. feature set, but from the POV of someone that's using a simple language, the two don't look that different. One does help you avoid certain errors, although whether that counts as hand holding or hand slapping is in the eye of the beholder.
* creating more work for yourself, and
* introducing bugs in your code.
Don't do that. Use C++ as C++.
Java lost a lot of mindshare to C# and Kotlin due to that "strategy".
C# still doesn't deliver on all platforms where there is a JVM available, and has yet to even offer something as portable as Swing across all those platforms.
Kotlin really only matters on Android.
In fact right now we are having issues with .NET RFPs, because everything that comes through the door are Java related RFPs.
There was a 8 year gap where C# users could use stuff like enumerable operators while Java users were stuck in the stone age of writing loops for collection manipulation in a high level language ...
I have been working with Java, .NET and C++ since they exist, and C# being more feature rich than Java doesn't help if the libraries or OS support that a customer needs isn't there.
I think you'll find many people outside the HN crowd also appreciate their approach over trying to appease the kinds of customer needs that involve keeping 25 year old binary only jars running.
To me .NET Core is a shining example of that
To this day there are plenty of libraries that are yet to run on either Core or outside UNIX.
Plus not everyone is happy how the whole Core, .NET 5, .NET Native, Reunion, UWP, CoreRT, Xamarin, MAUI, Blazor is being managed.
A language alone isn't enough.
And to your second point.. I mean you're comparing concepts at very different levels of a stack. Your list includes a language runtime, a web framework, an OS specific application format/framework?
It's like saying "Java, HotspotVM, JavaFX, Tomcat, Android APK, Vert.X"...
In reality it's ".NET Core and .NET Framework".
And while there have been some growing pains as the term .NET became overloaded, it's always been clear .NET Core is where they want people to be, .NET Framework exists because migration to a new platform wasn't going to happen overnight.
Every year there's more and more .NET Core compatibility, they've done a good job with .NET Core so more people are willing to use it (and port packages to it)
https://docs.microsoft.com/en-us/dotnet/standard/choosing-co...
Yes, the future is .NET Core, however pretending that outside Windows it can match Java offerings just reveals a complete lack of knowledge of all kinds of platforms that have Java support available for them.
Guys like PTC, Aicas, Gemalto, microEJ doing embedded real time Java, selling M2M devices, IBM and Unisys mainframes, 80% of the mobile world (even if it is an adulterated flavour of coffee), smartcards, blue ray players, healthcare and TV settop boxes, kiosks and plenty of other use cases.
.NET is catching up with 25 years of Java doing cross platform development, while anything that came out of Redmond has been mostly Windows only for 20 years.
.NET Core only supports the three major mainstream OSes, zero support for anything else, and has the growing pains of a platform where plenty of third parties are yet to release anything on Core.
Sitecore just released their first version on .NET Core earlier this month, and I don't see anyone rushing to upgrade.
Doing WPF, Forms? Good luck with many GUI component libraries.
Apparently the designers are going to miss .NET 5 for full stability.
The beautiful thing with being a polyglot consultant is that I don't have to convince myself that I am using the best stuff as "Developer X", I just use whatever stack the customer asks for and then move on.
This is true, but this level is support for the majority of use cases. I do personally find it very annoying that refuse to support 32-bit Linux tho.
> has the growing pains of a platform where plenty of third parties are yet to release anything on Core
This was true a few years ago, but certainly isn't now. I honestly can't even remember when I last tried to use a library that didn't have dotnet Core support.
Also worth noting that anything built for dotnet framework 4.6.2+ (4.6.2 was released in 2016) will run just fine under Core CLR.
Here is another example, Oracle drivers for .NET Core only support a subset of their capabilities on Core.
I can keep feeding examples of stuff that is actually relevant for Fortune 500's, which Microsoft keeps out of their .NET Core marketing or just hand waves as yet another porting effort, as if we didn't had better ways to spend our money.
But yeah, why compete with the rest of the Fortune 500 that hire top talent to build out new systems...
when you can pay a "fixer" who prides themselves on self-flagellation keeping legacy systems with no source targeting platforms designed for computing as it existed decades ago (that only exist because of gross mismanagement and a general view of development as a cost center)?
What's interesting to me is someone would actually try to hold this up this dance as something the rest of the tech industry should aspire to uphold lol. Maybe because it makes for less "war stories" deep in the bowels of decade old systems with no documentation successfully migrated to the latest Jenga block in their leaning towers?
Imagine if other fields worked like this
"Our materials science company prides itself on only releasing plastics that can be molded using what was state of the art 20 years ago"
"Our competitor Macrohard insists on occasionally releasing new plastics that are stronger and cheaper to develop with, but we cater to those shops that refuse to invest in techs who know newer processes!"
I have no idea what on earth you're on about... you didn't bring up anything I didn't know as far as places where various JVMs live.
This just reads like another distraction from the topic of language direction just like your last comment trying to confuse web frameworks and language runtimes...
Why is .NET Core supposed to be blindly chase platform parity with JVM down, especially down to embedded devices?
You realize the JVMs used on embedded devices aren't the same ones used on desktop right?
Like there are C# frameworks for embedded development on microcontrollers, why on earth would that be .NET Core's domain? Do you think HotspotVM is running on those smartcard microcontrollers?
-
Your entire comment you seem to be under the impression .NET Core exists to be a drop-in replacement for the JVM for every usage.
Which is especially strange because you're using JVM as a generic term for every JVM in parts of your comment, which would maybe be comparable to the CLR at best (but still be an odd comparison to make)
If anything you're speaking to the strength of C# and a product like .NET Core, they're not chasing the same goals that skewered the development pace of Java.
The C# team is not worried that their language standard changes might be hard on people embedded runtimes in smart cards or 25 year old binary only jars
The same mentality is why C# paid the price to break backwards compatibility on generics back in the 2.0 days, and enjoyed a much more powerful implementation going forward in perpetuity.
You're free to feel one approach is better than the other, but it's non-sequitur at best (and disingenuous at worst) to start spouting off about how the JVM runs on smartcards and so that means .NET Core is supposed to be matching that in a conversation about language growth...
Yes, C# the language is better designed than Java the language, while .NET the ecosystem is is tiny spot of Java the ecosystem.
When I mention JVM, I mean any implementation, I don't mix Java with Hotspot.
And yes PTC and Aicas sell full Java SE compliant implementations for embedded development.
The only embedded options for .NET are Netduino, hardly market relevant, and Wilderness Labs, which doesn't cover at all the kind of industrial deployments PTC, Aicas, microEJ and Gemalto are doing.
I work with Java and .NET alongside each other since they exist, so I know pretty well the pros and cons of each platform, specifically outside the implementations that people mix with the language.
C# doesn’t break too many things while it evolves. Example: https://docs.microsoft.com/en-us/dotnet/api/system.collectio... That class was introduced in .NET 1.1 way before generic, still present in the most recent .NET Core 3.1.
They sometimes deprecate higher-level stuff, but very conservatively so. E.g. asp.net web forms (2002) is deprecated, while windows forms (also 2002) is still supported.
Forms designer is still broken on .NET 5, and it might not make it to the final release.
Yup, for better or for worse, Java will be the COBOL of the 21st century.
Aside from that, the average 21st century developer would have a meltdown trying to use C.
Java is stable, and evolves with a huge amount of thought (they employ theorists to model the impact of changes to the Java language even.)
The benefit of this is a long-term platform, and an excellent implementation. Due to this Java has become the platform where the majority VM research is done, which means Java has many excellent state-of-the-art garbage collectors and a JIT a level beyond that of C#.
Unfortunately this isn't enough to make up for the latency hit from not being able to directly stack allocate things like C# allows (especially with its recent addition of Span<T>).
Java does better than direct stack allocation - it does automatic scalar replacement instead.
To be fair, Java has a lot to recommend it. For one, there are, of course, an incredible number of packages available to build off of. But I find it incredible that the language that replaced finalizers with phantom references still says pointers are too dangerous for programmers.
JVM is not the best in all areas.
I guess that this is a question of taste.
What for you is "less verbose" for me is more confusing to read. I like to see the types as they complement variable naming. To avoid typing a few letters the code will for ever require me to double check the types with help of the IDE.
I have worked in medium sized corporate companies. The code base is quite big and one of the 20+ development teams may get transferred a project from another team (does not happens super-often, but it happens) or they may create pull-requests for bug fixes (this is more common).
Clear and easy to understand code is life saving. In one of the companies I worked for a Javascript team send a -1 instead of a "-1" the cost ramped up the hundreds of thousands of dollars and our clients were not happy about it. Rollback mechanisms were used as fast as our clients detected revenue problems on their own customers.
And the tests did not got the error as the values is used at the integration layer between our clients and us.
I see safety an increasing value as our programs control more and more money and more and more services. And, I have to admit, I feel more comfortable with more verbose code.
I have no experience with it at the corporate level. There, I have seen, it mixes a lot with .NET. So, I guess that the corporate equivalent to Java is "C#/.NET".
I spend some time several years ago with C# in Unity3D, thou.
I really liked the C# language. I found the Auto-Implemented Properties a neat compromise between encapsulation and verbosity (Verbosity has no value if does not add information).
Java is trying to be everything to everyone and that is a mistake. I liked Java more in the past, and I would have added just a few things from the past iterations of the language (e.g. Modules is a good idea that actually simplifies the language and moves much code to "frameworks" instead of being part of the core language).
C# seemed more focused on its initial style were Java is stretching all over the place.
var a = new ArrayList<T>();
not:
var a = o.getThings();
That is a very good point. I find the diamond operator more of my taste as it requires you to think if you want to expose ArrayList or List.
List<String> list = new ArrayList();
But, as you point, the second example removes information that will require to spend time to check types each time that someone reads the code. I do not like that.
I use auto-complete and I type quite fast, so, I do not see to write code as a problem. I spend most of my time understanding the functional needs, looking for better patterns or algorithms to implement performance-critical sections or finding names for exposed APIs that state clearly its function when I "write code". But, most of the time, I am just reading my old or other people's code to just change a few lines or decide on a local refactoring.
Here, the first is much less verbose, but still clear:
var x = new Dictionary<string, MyComplexType>();
Dictionary<string, MyComplexType> x = new Dictionary<string, MyComplexType>();
var x = y.GetStuff();Java type declarations can be 20+ characers - just scanning through the code and having to skip all that junk makes my eyes more tired reading through. Types are implicitly deducible when you know the codebase 90% of the time (and should be added when they are not), and if you don't know the context you will be slow no matter what.
Yes. When I was younger I worked in solo projects. I knew my code almost line by line.
In my last decade, in middle sized companies, nobody knows all the hundreds of micro-services code. And code changes while on vacation, that can be 6 weeks of the team working without you. That is not ideal, but in such a big code base it is difficult to have everyone reviewing all the changes on a single micro-service, impossible to have all 20+ teams reviewing all of each others code.
Different problems need different solutions and code styles, I guess.
Why do I mention? Because until now .NET Core still doesn't have anything like Swing across all supported platforms.
MAUI might do it (Xamarin renamed), or you might just get Blazor running on WebWidgets.
I rather have Swing if the alternative is running Blazor that way.
Not counting community toolkits here, just what is available out of the box.
If we look at programming languages as tools, it makes sense for them to get out of date and new ones taking their place, with all the lessons learned.
So its possible that programming languages like C++ that keeps extending their own life through adding features (while keeping weaknesses), will ultimately cost the community/industry more in the long run.
They did add those features eventually (Java 8) - about 8 years behind C# (since C# 3.0)
Part of me thinks that this is how it should be. Extending a language constantly while providing backwards compatibility can lead to some awkward syntax too.
Just gonna drop this here: Nicolai Josuttis “The Nightmare of Initialization in C++” [0]
- No checked exceptions
- Properties (I wish Java would add this to the core language instead of relying on things like Lombok as it shouldn't change the IR and really is just syntactic sugar)
- Partial classes. This really isn't in contrast to Java because Java has nothing like it. But it is a neat feature for partial code generation;
- LINQ. Java eventually added streams but last I checked it still had performance issues and IMHO LINQ is just cleaner;
- Conditional compilation. This is really a huge oversight. One of the huge benefits of the preprocessor in C/C++ was conditional compilation. It's great than C# included it. It's bizarre to me that Java hasn't.
- Async/await. Honestly I still find C#'s version of this more awkward than Hack's. Experience has taught me that whenever you spawn a thread, you've probably made a mistake as subtle mutlithreading bugs are the devil and cooperative multitasking like you have in Go, C# and Hack is usually far safer and sufficient most of the time. Still, C# is still better than Java here.
- C#'s reified generics vs Java's type erasure. I think it was the right decision to break backwards compatibility here (and I don't usually say this). This was pretty early too (IIRC generics were added in C# 2.0).
But all that being said, I still think Java has a large mindshare and install base than C# by a mile. it's not sexy so it gets less attention on HN but Java is still massive.
As for Kotlin? Much like Scala I see this as nothing more than a curiosity. Android developers seem to like it but I think it's a tiny fraction of Java still.
Java is massive for legacy reasons, but would be nice to have some statistics regarding new projects. The last two companies I've worked for had backend teams using Kotlin so I've been assuming this is also preferred by backend people. Could well be that this has was an anomaly though.
I mostly develop for Android so my own perception is obviously biased, as Java is pretty thoroughly erased from this world now.
Anything else on the JVM is nice to have, but isn't where all the goodies are.
Google has a special interest in getting rid of Java, hence Kotlin.
In fact, it is going to be fun to watch how they will keep up with the pace of the JVM, because when the majority of key libraries move to modern Java, many of them will stop being compatible with D8/R8, forcing Android developers to use pure Kotlin libraries.
Then JetBrains needs to think how to make use of Java libraries that use the new FFI, virtual threads, inline classes, generics, SIMD vector types, while keeping the language compatible with what ART is capable of.
See virtual threads vs async/await. Java's version is going to be better.
You can block the caller thread waiting for the task. Deadlocks are possible with this approach due to synchronization context shenanigans, but they’re easy to fix, VS debugger is quite good at multithreading.
Another method, you can run whatever dispatcher on your main thread, in modern .NET that’s usually Dispatcher.PushFrame.
Also, if the async method returns no values, you don’t need to change the call chain, you just need to catch and handle exceptions.
I feel like a lot of languages these days trend towards "kitchen sink" languages that toss in everything and the kitchen sink in the name of clean looking code. IMHO this tends to sacrifice language elegance. This is probably why I tend to like languages like Java/Go/Clojure.
The C preprocessor can make it way to easy to break code, for example when it is used for feature flags and/or multi-platform support. If you have N feature flags, you have to compile 2^N different programs. Multiply by M for supporting M platforms.
It also makes it impossible to check whether source code can be compiled. The text inside a
#ifdef FOO
...
#endif
Dependency injection can be made messy, too, but that takes more of an effort. You can also test injected code in isolation. That may take some effort, but those preprocessor messes only could be tested as part of the entire product.
As I said, I can see why they wanted to get rid of that. Not adding a same replacement may not have been the best choice, but I am not sure of that. Programming culture also had to change, and that sometimes requires drastic action. Apple also did that in the Mac by not providing any text mode (forces programmers to make windowed applications) and by removing cursor keys from the first keyboard (forces programmers to provide a good mouse interface)
I rely miss checked exceptions on .NET, specially with libraries that provide zero documentation about their exceptions.
Most things shouldn't even have getters and setters apart from your @Entity classes.
People put scare quotes in seemingly at random these days - are you suggesting it's possibly not their strategy and actually they're lying? What do these scare quotes mean?
But of course, I'm sure Oracle is a big reason too.
But my experience for instance when having to do stuff in C#, Java or Python is that when I'm looking for advice on the internet, stackoverflow, etc etc... 80% is reaaalllly bad, in the sense that if it were C++ everybody would be screaming "wtf don't do that this is insane" and write 12 blog posts and 40 twitter flamewars about why this is a bad idea and you should never ever do this... but apparently the "tolerance to bad code" is much higher in other communities.
But give them five years and they would generally not be able to write a C++ compiler.
You won't find that as much for for Haskell or Clojure or Brainfuck but that doesn't make them better languages or less tolerant to bad code.
An extensive standard library is not the same at all as an large base language size. Adding a million books to a language doesn't make it more complex, adding a million words and verb conjugations does.
Also I think many aren't aware how powerful Python actually is.
It's not "full" in that it can't express the types of many language features well enough that inference works. Something like the attrs package needs to use a kludge[1] to communicate types back to a validator.
https://github.com/python-attrs/attrs/blob/4f74fbaca3cc12911...
I would agree that the Python ecosystem is as complex as the C++ language.
I would not agree that the Python language is as complex as the C++ language, or that they Python ecosystem is as complex as the C++ ecosystem.
I will agree also that the Python language has very comprehensive first-party tutorial and reference documentation, but that doesn't add to the complexity.
pretty sure that's only a factor if you need to deal with Python 2
Generally, yes for Python (definitely for 2, async shook up 3 a bit), C (barring a few genuinely legacy things like trigraphs), Go, Lua, and I think probably at least 2-3 times a year for anything in Java 12 and earlier.
C++ is the only language I use regularly that I am certain I don't even know of, let alone know or use, all the features of.
Have you really used all of these Python features (from https://twitter.com/raymondh/status/1280988785841278976)?
__class_getitem__, __init_subclass__, __prepare__, __qualname__, __slots__, __spec__, __annotations__
__subclasshook__, __abstractmethods__, __text_signature__, __index__, __loader__, __mro__
I've been writing Python for years, but I've never even heard of half of them.
All Python-like languages have the same or similar mechanisms (for example, a method resolution order whenever there is multiple inheritance) and they are usually not explicit and not customizable.
Hell, the very defaults of C++ will interact badly with other features and proceed to shoot you in the foot, as Chrome somewhat recently reminded us (https://chromium-review.googlesource.com/c/chromium/src/+/16...).
You need an 8x6 matrix just to know what the compiler will or won't generate (https://i.stack.imgur.com/b2VBV.png) and then you need to know exactly what the defaults will do and whether that breaks your object entirely and you need to override those defaults.
I teach Python to scientific programmers. There are a lot of little details and corners that aren’t as obvious to experienced developers. Just like any language.
But, critically, you won't find anything other than __slots__ and __index__ (and maybe __subclasshook__ if the code you're working on was from someone who drank the ABC koolaid back in the day) in "normal code" - they're there for people who want to hook into language internals, the kind of thing you'd usually find #pragma'd in C++.
With C++, on the other hand, you run into this kind of complexity just trying to solve "ordinary" problems. And it bears repeating, the "safe subset" between projects is different. It's not the only language with this problem (Common Lisp suffers greatly from it), but it's the one that offers the least in return and breaks the hardest when you get it wrong.
I'm still holding out some hope that Stroustrop releases a new edition of "The C++ Programming Language" with the features from C++14 onward.
Is anyone aware of a library for another language that's as fast as Eigen?
I think it'd be difficult to argue one way or another: Eigen gives you flexibility one way (custom kernels) and Python gives you another (interactive debugging and easy visualization). Cython/Numba make it even more muddied.
However, the idea that you should learn and use "all of C++" is a mistake to begin with. It's something that sort-of happens with C, but doesn't really make sense with larger languages.
Specifically, remember that C++ is _multi-paradigmatic_ - you can write more object-oriented code, functional code, highly templated generic imperative code, or, well, C-style code. The standard library also now has something for everyone, and there's no reason to know _all_ of it.
On the other hand, many things which used to be difficult to write and required some deep "voodoo" or a lot of boilerplate are easier and more straightforward these days.
It is quite marvellous in a way, almost a statement of "we don't want design, we just want something that compiles". It has worked out remarkably well in practice.
Doesn’t really make sense why you’d want to anyway. Why would you want to use all of any language? C++ offers so many features because of its extraordinary flexibility and application to a wide range of domains. Unless you’re writing an app that is a game that also trades high frequency transactions on the financial exchange, while performing physics simulation and 2-D vector rendering, all while serving up a Web server, it would not make sense why you need to use all of the language. It’s perfectly fine to find those parts of a language that you are personally interested in.
We write our code such that it minimizes the amount of effort to read it, under the assumption the reader knows the language.
This way, it makes sense not to use a library for something that can already be cleanly expressed by the language because this introduces additional mental overhead for the reader.
Yet is doesn't make sense to avoid modern, simplifying language constructions, as we can assume these are known by the reader.
This unwritten contract is jeopardized by an overload of language features, as suddenly we may want to avoid certain features considered complicated. Hence, the notion of optimal code becomes more subjective.
And there are definitely things that these features provide that are impossible in C.
I remember starting out with Python and only knowing a subset of it, but as soon as I started writing real apps that interacted with the larger Python ecosystem, I found myself having to learn the full language (or at least a lot more than I did writing my own isolated code).
C++11 introduces hugely useful stuff. I would much rather have it than C++03, c++98, etc.
Whenever I come across things introduced in 14 or 17, I usually evaluate it and say, that addition makes sense, maybe it should have been there sooner. But I am not actively seeking out that information. So I am never up to date.
It is a big contrast from a few decades earlier, where you would expect to use very few new features from the standard for a period of many years. That is also the expectation the C standard gives: it hasn't changed substantially since 1999, and even that you could call relatively minor since 1989. But I still think they are doing a good job with modern c++, even if these old expectations are no longer the case.
I agree in general, but still, some of the newly introduced features are actually awesome. Here’s ones I’m using almost every day.
C++/11: initializer lists, range-based for loops, strongly-typed scoped enums, raw and UTF8 string literals, thread_local, thread synchronization classes including atomics, alignas
C++/14: binary literals
C++/17: if constexpr, std::string_view, better static_assert
And in C++/20, pretty sure I gonna use std::span and std::bit_cast.
In C++ we don’t pay for features we don’t use. I’m totally fine with other people getting the features they want (despite finding them unreadable and overcomplicated), I simply don’t use the stuff I don’t like.
The classic example is C++ ranges' pipe operator. If it was implemented in language, like OCaml and Elixir do - There would have been no need to write range adapters - the error messages and debugging could be much better than 100000 line template implementation. - debug build would be fast as well - compile times would not suffer
Implemet-it-as-library is often a leaky, brittle abstraction. That's the reason LISP, with its proclaimed magic capabilities, didn't take off.
The C++ committee seems quite academic at moment. Last time I read C++ performance report, all I could find was some old advice like "use list if you want insertion"™. They didn't mention difficulties in using realloc in vectors. They didn't mention inefficiencies in stl HashMap implementations due to iterator invalidation constraints. They didn't mention exceptions requiring dynamic storage and RTTI. Note that many of these problems are not yet fully solved with move constructors.
At the same time they are also less academic than required. Given how they managed to put pipelines into an ugly template library without any of the considerations I mentioned above.
I can't help but I feel similarly towards all standards committees. The JS standards people are still unable to deliver a standard library, and a "use strict"-like flag that enables easy tree-shaking.
If anyone here is in C++ standard committee, you owe us an answer.
The TR18015 (Technical Report on C++ Performance) goes into details on most of the above (and much more) and it was written in 2006. The only thing missing is a discussion of hash_map as it wasn't part of the standard yet.
We all know the negative parts, any C++ related thread is always full of people repeating them over and over. What about some celebration time for now? A huge milestone for the language has been reached with C++20, can we share something positive about it for once?
A good meta programming language would be one that's as easy to program as a general language. lisp, nim, etc...
But, at least, you no longer have to iterate over arrays with size-1, (size-1)-1 etc these days. We have variadic template expansion, we have the (ugly, still not decent design, but useful) std::integer_sequence , and better still - we have pretty strong constexpr capabilities.
I do meta every day, meta-meta often, and triple-meta occasionally. The rules language for my Expert System is a true meta-language, because I designed it to (among other things) specify the manipulation of computer languages. So its domain knowledge is about the nature of computer languages and how to automate their assessment / analysis, transformation / re-engineering, translation, and generation.
To give a real-life example, we used our Expert System to automate the translation of complex compiler front- and back-end code from a proprietary system language to C++ for a major computer manufacturer. The translation rules don't really care what the code is doing; they care how the code is doing it. The compiler team created new templates and classes to provide the functionality their system language had that C++ doesn't, and we adjusted our translation rules to ensure that the translated code invokes those templates and classes in a clear, effective, efficient, and readable way.
I have a lot of experience with many different types of metaprogramming (cl macros, Rust macros, template Haskell (and Typeable/Generic), ... even CLR code generation) and C++ templates are better than everything I've used other than Common Lisp once you really understand them. A really common C++ theme I see is people that don't understand things railing against them (I used to be in this camp myself, so I can identify with the sentiment).
Templates allow you to choose at will between nominal/structural subtyping (in a way), perform type-level logic, generate code that can be thread-safe or lock-free at the caller's whim... They are very powerful, much more than most devs realize, and if you understand C++, writing them is not difficult.
The "really understand them" part is, of course, the hard part. You need to understand the core language and the template language to be effective with them. I can see why even some experienced C++ developers shy away from templates.
The attitude with templates seems to be that if something is at all possible with hacks then there doesn't need to be any language support added, even if it would be vastly simpler to read and write and probably to compile. I don't think that works out well.
Generally I find the best use of templates is the most basic: you want to write some code that operates on duck-types. As long as one is able to control themselves and pick the right use cases for maintainability, templates are simple enough. In my experience, this is very doable.
Concepts are also a really cool way to rein in which types are accepted as a template parameter and have a lot of potential to make templates easier to understand and teach. To me, this is the most exciting c++20 feature.
I certainly understand metaprogramming, but navigating very dense C++ templates is one of the most complicated things I've had to do in my life. One or two levels of abstraction and you will lose your ability to hold everything you need to solve a problem in your head, and after a few dozen lines the source code is unreadable.
> You need to understand the core language and the template language to be effective with them.
this is a bug.
I also don't really see how requiring understanding of a language to generate that language could be considered a bug - every macro system carries that requirement. C++ just happens to be (much) more complex than most languages (and I do agree that a large amount of that complexity is probably not necessary).
I should be more clear about what I meant on the bug. C++ templates force you to understand the entirety of the language at once and hack around its edges because it doesn't support actual meta programming. It's hard for me to come up with a concrete example, but my experience writing some advanced compile-time evaluation with SFINAE patterns left me forgetting how things worked within minutes of typing them. Compare to say Rust, where the generics implementation is much cleaner and macro system better flushed out and easier to read/understand. Or the LISPs where your macro is just more LISP code.
And not for nothing, templates destroy compile times. They take a long time to write and edit and make everyone else using them work slower. All told, templates do not make it easier to write C++ except in trivial cases and first-order abstractions.
I do agree that you can go insane with templates and have a bad time. You just have to choose well. However if you have a problem with there existing other problematic code in the same language (that may be separate from your code), then C++ is maybe not the best fit. There's a lot of C++ out there.
C++ templates are just a compile-time lazily-evaluated Lisp.
As always, the criticism of C++ comes down to "programming is hard, let's go shopping".
If you don't want to learn and you just want to do the bare minimum to keep your 8 hour coding job, there's already plenty of languages that nail this niche. C++ obviously is not for you, just move on and don't make a redundant comment.
https://people.redhat.com/~rjones/bitstring/html/Bitstring.h...
I find it much more pleasant to write, e.g., ODBC client code in C++ than in C, and templates have a lot to do with that. I'm not an expert with Lisp macros or other reportedly superior meta-languages, but I will say that when I write generic code in C# or Java, I really miss the power of C++ templates.
Template syntax is pretty awful, and accomplishing what I want can involve some really strange idioms, like SFINAE. The ergonomics are slowly improving with type deduction, constexpr, and now concepts.
Nowadays C++ and a powerful multi-paradigm programming language quite straightforward to use if you forget the word “C” in its name.
If would be a good instructional language if people didn’t fall into the lazy “a horse is a king of animal” OO trope.
Oh yes, that would really be awesome if that's the case. Wikipedia has a section regarding "Compiler diagnostics" when Concepts are used, the precision of the error message demonstrated is SO MUCH better than what you get with templates!
https://en.wikipedia.org/wiki/Concepts_(C%2B%2B)#Compiler_di...
Code example:
std::list<int> l = {2, 1, 3};
std::sort(l.begin(), l.end());
In instantiation of 'void
std::__sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = std::_List_iterator<int>; _Compare = __gnu_cxx::__ops::_Iter_less_iter]':
error: no match for 'operator-' (operand types are 'std::_List_iterator<int>' and 'std::_List_iterator<int>')
std::__lg(__last - __first) * 2,
...
... // continues for 50+ lines
error: cannot call function 'void std::sort(_RAIter, _RAIter) [with _RAIter = std::_List_iterator<int>]'
note: concept 'RandomAccessIterator()' was not satisfiedD is far more powerful, especially when you consider that it's had working constraints for (?) something like a decade now.
Simple example, try to express this in C++ without a windows full of syntax-soup (https://d.godbolt.org/z/Toc8ob), the template constraint is one line, and I can pass anything into a template using alias be that templates, a string etc.
Passing strings into a templates is a very common trick for generating code at compile time in the D standard library, although it wouldn't work in C++ due to how slow C++ can be to compile some times.
https://www.youtube.com/watch?v=QM3W36COnE4 Here's an example of parsing regular expressions in C++ at compile time. Code here: https://github.com/hanickadot/compile-time-regular-expressio...
It certainly has a lot of warts, but over the past decade, it has become easier and more straightforward to write code in various styles which used to be possible-but-a-pain (like functional programming), or not quite possible.
So with C++ you get performance + backwards compatibility + paradigm flexibility for the price of difficult, sometimes ambiguous syntax, some historical baggage you need to ignore, and slower compilation time. It's a decent tradeoff IMHO.
Specifically, regarding C++20:
* std::span is the best thing since sliced bread. How was this not in the library already? Cuh-razee... https://stackoverflow.com/q/45723819/1593077
* I'm happy that ranges support is inside the language. I can now `sort(my_container)` rather than the clunky `sort(my_container.begin(), my_container.end())` for example. And there are a bunch of useful lazily-evaluted range views. I only wish more of the ranges library could have been added. And I hope the compilation of ranges isn't too slow.
* Modules can now start replacing include files. Initially, this will only be a theoretical possibility, but within several years, no longer will your compiler have to deal with 100,000 lines of text or so per translation unit: It will be like in Java and other languages, where it's just your current file that needs to be compiled and the rest is already compiled. Of course the transition will not be smooth (feature macros, conditional compilation - not obvious to me how to replace them when using modules), but this is a good direction. We could see faster compilation times and content suggestions in IDEs.
* Expanded constexpr support means we can do more work once, at compile time, rather than repeating it at run-time (e.g. dynamic memory allocation - so you can have constexpr std::vector).
* Coroutines are something interesting which I am not familiar with (except the very rough general idea of different control flows being switched between. I can at least say it's interesting to look into.
* libfmt string formatting - Yes, yet another way to format strings: printf-style, iostreams, and now the "Python style", I guess you could say? It combines some benefits of both of the previous ones.
* std::source_location - you know how, if you're writing some error-handling function, you usually need to wrap it in a macro which gives you the filename and line number? Well, that's going away now. I know it's just a minor thing, but I hate having those macro'd error handlers.
* You can now tell the compiler to use a generated equality and comparison operators; this saves you boilerplate. Although in the C++ tradition, this capability is defined in a somewhat convoluted way under the hood.
RAII is a damned useful idiom too, makes writing safe code that much easier.
Tooling for C++ is pretty damn good in all the usual platforms
Most of the abstractions (E.g. iterations) are zero cost as opposed to additional functionality like shared pointers or resizable vectors.
At any rate, the definition of “zero cost” isn’t “it’s the same as a raw pointer”. Rather, it should be read as “its cost is the same as the equivalent functionality rolled by hand”. Shared_ptr implements a ref counting mechanism, which, absent a real GC, is necessary for actual shared ownership.
That's why shared_ptr has horrible performance, the spec requires that the control block is thread-safe. Perf tanks due to the atomic load/stores. If you roll your own with a standard load/store you'll see significant performance increase which means it's definitely not zero-cost.
This is why Rust explicitly went with Arc/Rc[2] so you don't have to pay that cost(although ambiguous ownership I would argue is a pattern you should try to eliminate anyway).
[1] https://en.cppreference.com/w/cpp/memory/shared_ptr
[2] https://doc.rust-lang.org/std/rc/struct.Rc.html / https://doc.rust-lang.org/std/sync/struct.Arc.html
It is true that the ref count is kept atomically, which allows accessing two distinct shared pointers that happen to point to the same object from different threads. This is pretty much a requirement to support the baseline distinct object thread safety (aka "as safe as int), but it is not what the unqualified "thread safe" normally refers to.
/pedantic
Anyway, it is true that with shared_ptr sometimes you might end up paying for what you do not use, but doing otherwise would have made any use of shared_ptr in threaded applications extremely unsafe so it was felt that in this case the cost was worth it for a vocabulary type object.
What kind of definition is that? Zero cost is exactly that - 0 cost, the same performance as if you were not using the abstraction. The alternative to an abstraction is not "my hand-rolled implementation of said abstraction" - it is not using the abstraction, at all (but using lower-level mechanisms to achieve the same goal). 0-cost is used to tell people "you will still achieve the same performance by using the abstraction - and you gain additional benefits (safety, readability etc)". If I can get better performance with raw pointers, then smart pointers are not zero cost (it's still a good idea to use them instead of raw pointers! Just, let's stop pretending they are zero-cost)
If you pass a unique_ptr it has to have redirection through a pointer, so it isn't quite zero cost.
However, since the entire point of using a smart pointer is to control the ownership I'm not that bothered.
It has a null check on destructor (and a delete of course), which is good enough for "zero cost" to me
I guess it is more complicated than i thought, but i think it is fair to compare them pointers too. Because most of the time you will probably need to store it as a pointer
i.e. there is no way to end up with faster code that does the same thing, without using the abstraction.
This is the very definition of zero cost abstractions.
IMO, C++ has the following huge benefits.
1. Ambient performance. If you need a fast program and don't have a tight loop you can optimize, C++ makes ordinary behavior fast.
2. RAII is a very clean and understandable design paradigm.
3. The idiom of using "const" everywhere plus widespread copying of values makes "spooky action at a distance" way less common when doing OOP or imperative programming.
I could go on about the bad parts, but the good parts
1. lambdas
2. constexpr
3. threads
These additions did make C++ feel a little more modern.
Finally we got modules, concepts will put an end to the fame of endless kilometres of error messages and compile time programming almost allows for static reflection.
Highlights for me:
- Type deduction -- basically using auto for variable declarations.
- Move semantics makes RAII actually usable since you can make heavy / important objects but then move them elsewhere and still have their lifetime be automatically managed. I use this in my game engine to wrap physics bodies etc. so that they are automatically removed from the scene when the component containing them is dropped (I'm using an ECS). A neat thing also is you can delete copy constructors and force certain types to be "move-only."
- Having been in C-land for a bit, I'm appreciating the ready availability of std::vector and std::string again. Also std::array is awesome.
- Lambdas are amazing. I often make simple control structure utilities in my modules that accept lambdas, and they are often inlined. I don't often do lambdas where I 'save them and call them later' -- they are mostly immediately called. This makes it safe to use reference captures.
As for C++20 I am mostly interested in seeing how it goes with modules Also the `requires` keyword will simplify some of my uses of `enable_if`.
A lot of the good stuff is also due to ecosystem and tooling vs. just language. My game works everywhere now: native macOS, Windows and iOS, but especially web due to Wasm! It also has an immediate mode API for rendering UI in Wasm, which I use along with some simple reflection to get an automatic entity inspector: https://m.imgur.com/dyUtL8f The entire gameplay code fits in like 700 lines: https://gist.github.com/nikki93/5893543a5e3d76a7858d54b74a4c... You can see how I don't do any pointer stuff or manual recource / memory management there at all.
Tbh in many cases with precompiled headers it almost feels like it builds about as fast as webpack. And then my "publish" is a simple rsync of static files to the server.
Another tooling / ecosystem thing lately has been godbolt.org which is wonderful for seeing immediately the asm that ur code generates. Which then makes you realize how good optimizing compilers for C++ are these days. I don't think other languages have come so far. And then with godbolt.org you can learn which constructs produce what code.
I'm using entt for the ECS: https://github.com/skypjack/entt you can see how it encourages the use of POD structs and non-OO code for the most part. It feels good to use C++ in that style as a C with the above features. I just basically don't use vtables / RTTI anymore. I do use templates a fair amount.
I do concede that this enthusiasm may have a lot to do with having had experience in C/C++ already for a while. If I was completely new to the language it'd be a lot harder. The backwards compatibility lets me keep all my experience (even if the point isn't to write exactly like how I wrote before, but to understand the motivation for the new features). I've also dug into Go, Rust, Nim, Common Lisp, Haskell, ... but weirdly modern C++ has been the best combination of ergonomics, control, and portability. Especially for Wasm you really just want deterministic resource management. I'd probably still combine it with Lua or JS for scripting eventually.
You do have to invest a lot of energy into learning the language and caring about the details, but I think C++ is very well positioned to reward you for that investment, and you are also rewarded continuously and early.
And this is the "Vanilla" version of the features. In C++17 and C++20, there is all kinds of goodies like concepts and modules that I'm personally excited about.
Hate it all you want, but it's an amazing language.
In fact, it's the one major feature I'd love to start using right away that I know would be immediately useful, but the compiler support isn't there yet. According to this [1], Clang has partial support [2], while GCC has no support at all.
* RAII
* lambdas
* templates
* function overloading
* operator overloading (used judiciously)
* inheritance and interfaces (used judiciously)
* an extensive standard library
* exceptions (depends on the project)
For me, the advantages of C++ over C are obvious and IMO there's no reason to use C except for legacy projects or platforms which don't have a C++ compiler.
Of course, C++ has lots of warts and things to complain about, but OP asked for the positive things :-)
But the module spec feels a bit weird ( https://isocpp.org/files/papers/n4720.pdf ).
I mean, "import M" should create a M namespace with the imported symbols. Here, it's more like "from M import *" in Python.
Evidently, the complexity of finding the same namespace in multiple compilation units has been considered acceptable for C++ modules because it was already handled decently.
But assuming I lose my sanity again and decide to go back to doing C++, which resource would you recommend for properly catching up the last 15 years of C++ changes?
Effective Modern C++ by Scott Meyers (esp. for the chapters on smart pointers).
Arthur O' Dwyer's "Mastering the C++17 STL"
David Vandervoode and Nicolai Josuttis etc.'s "Templates the Complete Guide"
The first chapter of "Elements of Programming" by Stepanov, and maybe the rest if you want.
I think also, just kinda glancing over the spec.
Bjarne's paper on the evolution of C++ from 2006 to 2020 is also important I think: https://dl.acm.org/doi/10.1145/3386320
As for talks, https://www.youtube.com/watch?v=XS2JddPq7GQ is great for value categories and move semantics
https://www.youtube.com/watch?v=St0MNEU5b0o&t=6s also move semantics, and also part 2 of that if you want
I'll add more talks here in a bit!
And honestly if you've liked C, you can get far by just starting with that then slowly adding things you want. I think the first things one may end up reaching for are std::vector / std::string etc.; then being able to attach methods to types, then some templates, some auto, some lambdas. The old vtables / RTTI approach I basically never use anymore.
Superficially, there's also co_await vs .await.
And, really, async/await is a subset of the C++ feature; you'd want to compare against generators, which aren't yet stable in Rust.
That makes Rusts solution sound better. But in reality things are a bit more differentiated. Both solutions are not zero cost abstractions for various use-cases. And depending on your use-case one or the other solution might end up being better.
From the user perspective, a big difference is that Rusts `Future`s are lazy (will only do something when polled), while C++ coroutines and the `task` frameworks on top of them are not. Besides influencing the way concurrency can be performed within these environments, this e.g. also has an impact on the stack usage of the solution (Rusts Futures can require a terrible amount of stack just to create the final composed Future).
Then there is the "interface" question. As far as I understand you can have virtual coroutine functions on classes the same way that you can an other functions. But you can't have the same in Rust at the moment. The "async-trait" crate gives you that ability again - but with the drawback that you now have a mandatory allocation (instead of the often elided one in C++).
Overall C++ coroutines are a lot more flexbile than Rusts async/await. The behavior can specified by overriding the promise type, storage type, behavior of co_await, etc. You can make a generator out of it, but also an async function. Rusts async functions are targetted purely at the async function use-case - which might make them a bit easier to understand.
Even within that use-case they are more constrainted. E.g. with C++ coroutines you can do things like "thread-hopping" - `co_await method_that_moves_me_to_other_thread()`. Rusts executor idea wants you to resume your piece of work on the same task (which imho think is nearly always a better idea!).
Another difference is that Rusts "resume/Waker" mechanism is designed for a multithreaded environments - it will take a needless performance hit in a pure singlethreaded shared-nothing environment(think Seastar). With the C++ solution you might be able to avoid that - but at the cost of the framework and language not providing you any thread-safety at all.
I was very critical of the C++ coroutine design as the extension interface feels very ad hoc and not built from first principles and because of the hard to avoid memory allocation, but people that know better than me seem to think that it is usable in practice with good performance.
I do believe that thread hopping is quite important in case you need access to remote data and want to avoid mutual exclusion.
They do seem quite beautiful and useful in theory, but I will be very curious to see how much they're adopted.
For sure! I expect some marquee libraries like ITK to adopt them as soon as it’s prudent (meaning when they can sunset support for older compilers), but most people won’t be using them.
I mean, most people don’t have to even really write templates code...
void f(auto x) { }
void f(Sortable auto x) { }
So yay, these are improvements, and welcome just like improvements to any legacy system always are. Kudos to the "maintenance programmers" of language design.
I really hope that Rust compiler team will investigate in great depth the expert changes in C++20 and backport the relevant stuff into rust
But many performance gains will be automatic e.g http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p072...
Rust's memory model is by far its most significant advantage over C++, and it cannot be added to C++ without breaking all backwards compatibility.
In addition to that it also protects against the majority of multithreading issues - which is something not even available in managed languages like C# or Java.
Well I see your point, the reality is that this statement is also true of rust itself!
The features it gets now are all mostly on the roadmap since quite a bit and neither surprising nor do the feel like a huge pile of "everything I can imagine" thrown together.
Rust is several order of magnitudes away become such clogged like C++ is, and also its feature acquisition accelerates slower than the one of C++. The only thing slower than that acceleration is probably its compile speed, but here C++ isn't really better. :)
From observing both since a bit I just really got the feeling that rust adoption of things was more thought out to fit the existing language and ecosystem, not 100% perfect, but much more fitting than what C++ did, i.e., mixing in every thing they could get their hands on, while some actually made things better, a lot just do not go well when being together.
In my modern C++ projects, I only really need to know std::move and std::unique_ptr.
The real question to ask is how much complexity one's willing to pay for memory safety. I'm willing to pay it, but with open eyes about the complexity cost I'm paying.
If you're switching to C++ because of performance, you should have probably picked C++ instead from the beginning.
Who says on must know and use all the features of a language (especially the monster like C++) to write good code / software. Check what you really need for your particular task and be happy. I've found modern C++ a breeze to use as long as I do not pretend to be a language guru. Writing some sophisticated STL like libraries is highly specific and involved task and person/s doing that are not doing much of anything else so they would know all the of relevant C++. Using those libraries however is way way easier, the code looks pretty clear.
I use modern C++ to write various business servers. To me it is a single tool or two with clear and relatively easy subset of a powerful language. When I compare it with the monstrosity of some standard "modern" back-end stacks/toolsets C++ is starting to look like a small fish.
English is full of words I don’t use on a daily basis but that doesn’t make it bad.
(Not picking on python btw, just using a prominent example of an alternative path)
I suspect it was not because of C++ but me mentioning a monstrosity of some modern back end stacks. I think people get attached to the way of doing things and it becomes akin to religion.
The issue was that there's no language level definition of module implementation and layout so every build system may need to handle every single module implementation differently. The standard body decided to publish a technical report on this issue to ensure some level of interoperability across module implementations.
(it already does but in a dev branch version, not very handy as it requires a full reconfiguration of the environment variables to switch between this and the normal GCC)
The status is here: https://gcc.gnu.org/wiki/cxx-modules
"[...] because nobody programs in C++ — everyone programs in their own unique subset of the language. If you are told a program is written in C++, that leaves the following questions:
Does it use, or eschew, exceptions? Does it use, or eschew, C++ RTTI? Does it use operator overloading? Does it use, or eschew, the STL? Does it use, or eschew, C++11/C++14/etc. features? Does it use templates? Does it use virtual functions? Does it use multiple or virtual inheritance? Does it use static objects with constructors?"
I doubt that we will see clean modules that are free of preprocessor shenanigans, especially when writing any non-trivial portable library. I am no prophet, but I currently assume that unless we get hygienic module friendly macros and better conditional compilation on a syntactic level than dumb textual #ifdef, modules will only end up adding complexity in practice.
Also I belive that macros do not escape modules by default. That's a huge improvement.
Bjarne Stroustrup: C++ | Lex Fridman Podcast #48 https://www.youtube.com/watch?v=uTxRF5ag27A
https://developercommunity.visualstudio.com/idea/387315/add-...
I hope this also means the MSVC team had a change of mind regarding this very unfortunate blog post which IMHO did more damage to C than anything else in the last 20 years:
https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...
Here C++ has an edge over C, because it offers the language features for memory safe array and string manipulation, and most C++ compilers do offer bounds checking support, enabled by default in debug mode, and selectively in release if one so wishes.
Ideally, Swift, Rust, Ada, .NET Native would have replaced all use cases, but we are far from that ideal, so 2nd best solution, C++ for the time being.
Note that Apple and Google also reduce to the minimum the usage of C, and equally advocate C++ instead, alongside their managed languages for their OSes.
So yeah, you get C11 in the box, pity that the OS APIs are a mix of C++ and their own languages.
It's also interesting to note that Microsoft is only using header-only C++ wrappers, under the hood it's all plain old C-APIs via COM (because it would be a bad idea to expose C++ APIs in system DLLs).
The usage rules for C++ in Google's Fuchsia are so limited [1] that it is essentially a "C with classes", and it also has the rule that all shared libraries must have C APIs. I really don't see the advantage of using C++ for the underlying implementation compared to plain C if C++ has to be stripped down that much, and the public APIs are C APIs anyway.
[1] https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/...
Header only libraries are a stop-gap solution until modules are fully done, then good luck with those C bindings into .NET metadata used by UWP.
Regarding Android and Fuschia, C++ with classes is still better than plain old unsafe C and if you cannot see the safety that C++ brings into C, then one more reason why those companies are on the good path to remove C as an option.
- Exceptions, RTTI, thread_local, Statically constructed object all require runtime support and are problematic in a kernel so it is not surprising - Virtual inheritance: almost litterally nobody uses it. - initializer lists require static storage which is also problematic in a kernel - operator overloading and trailing return types are a stylistic choice, but at the end of the day they are a tiny bit of C++
Things that are allowed: actual OO classes inheritance (including multiple inheritance), virtual functions, RAII, templates (no restrictions at all), lambdas, all the recent goodies. I.e. all the things that make C++, well, C++.
So it is way less restricted than other guidelines I have seen for well known C++ projects.
That is a misconception from developers that don't understand C ABI == OS ABI, on OSes that happen to be written in C.
There is no C ABI on IBM and Unisys mainframes, Android, ChromeOS, WebAssembly and plenty of other OSes written in other languages.
OS/2 SOM, Windows COM and UWP are ways to achieve a compromise regarding how to expose a C++ ABI in a language neutral way. And stuff like gRPC also allows for something similar with inProcess calls.
Many of those better languages depend on LLVM, so no C++ is not going nowhere for the foreseeable future.
In fact they seem more focused on bringing Rust like capabilities to C++ static analysers, than anything else.
JVM has always been native by the way, for those that bothered to get hold of commercial AOT compilers, like PTC, J/Rockit, Excelsior among many others.
It may also have contributed to a lot of software developers moving to Linux, which has always had great C compilers.
Some features listed as supported are in their experimental versions still but it’s coming along pretty well.
https://www.stroustrup.com/tour2.html
> The ``tour'' is a quick (about 240 pages) tutorial overview of all of standard C++ (language and standard library) at a moderately high level for people who already know C++ or at least are experienced programmers. It covers C++17 plus a few likely features of C++20.
I will add that it's a good way to have an overview of modern C++, you can then go deeper on some topics with more specialized resources. It's a good read IMHO, with a good pace.
If at some point you're looking for more specific resources, I would suggest to ask on the C++ subreddit. I found people there to be helpful.
On another note, Bjarne is 70 year old and he is still very active in c++ new features, very impressive. That gives me a hint that as a software engineer, I can be productive for many years to come as long as I keep studying.
I also hope Linus still maintains Linux kernel in the next 20 years.
1. Adoption by users, including the larger, sluggish, corporate ones (and I'm being lenient with 8 years).
2. Transition from headers to modules.
Yeah, this one is likely to take a while...
C++xx new features and improvements are good. But they come very fast and that futureshock is causing the fever that is containerization "solutions".
I'm going to bet you haven't tried to use an older distro in the last decade and have kept up to date. Trying to run software from outside your repos that's written with the latest features is a serious problem on even mildly old distros. It wasn't such a serious problem with the slower rate of development 2000-2010. GCC 4 spanned an entire decade.
I get that on the big corporate server side there are different reasons for containers; for scaling, deployment, and all that jazz. But on the desktop, or in academia, it's the primary reason. It's futureshock and containers are the fever.