[bayindirh]

People love to think that C++ is only used in systems programming, the thing is C++ is used everywhere.

FORTRAN is being developed and improved, and new code, most notably in scientific domain, is still being written.

What Rust did to C++ is what clang did to GCC. Wake the giant up. Rust will go nowhere, but it's the same for C++.

Thinking that C++ will just fade to black is wishful thinking.

[kosolam]

Since C++ still evolves and changes, I guess greenfield C++ projects in the future can limit themselves to a subset of the newer improved language thereby C++ will continue living by that way as well.

[steveklabnik]

The C++ community is talking about evolving in the following ways in this space:

  1. contracts
  2. profiles
  3. successor languages
  4. borrow checking

The idea of a "subset of the language" is one that's often talked about, but there seems to be an explicit rejection of the idea of a subset, at least by several important committee members. It's not clear to me why this is the case.

[kosolam]

I’m not sure why you’re getting downvoted. The committee members have clear interest to keep things as they are. However, from a practical perspective I suspect that “subset lang” will happen. One just needs a linter or compiler flags to do that.

[steveklabnik]

It's all good, I have too much karma anyway.

The thing is, there's a difference between a true subset and "some flags that reject certain things." Because that creates a number of different sets that may relate to each other in a variety of ways, some subsets, some overlapping.

But beyond the specific definitions here, "profiles" is that sort of approach, so something like it will happen, probably. It seems to have a lot of support.

[ryandrake]

"Subset language" is already an option. The developer can choose a safe(r) subset of C++ to constrain themselves to. Many (most?) C++ shops already do this, and go to varying lengths to enforce that only their blessed subset is used. We don't really need a committee to create a new "subset language" to accomplish this.

[bayindirh]

C++ already passed that line with C++17 and newer iterations. Not only it evolves way faster starting with C++17, the modern code looks sufficiently different that it needs relearning some parts of C++ from start.

I've written my biggest project with C++11, and C++14 was just out back then. Now, I plan to reimplement that project (and improve it), again with C++, but I need to look at so-called "modern C++" to do it correctly and in a more future-proof way.

...and I'm glad I have to do that, because while I love (old school) C++, seeing it evolve makes me happy. Because systems evolve, software scale evolve, and most importantly hardware and ways to get maximum performance from it evolve.

There's no need to write old-school C++ anymore. All these features are developed for a reason, they shall be used.

[pklausler]

What new scientific applications are being written in Fortran?

[aragilar]

Fluid dynamics codes are still being written in Fortran.

Notably, there are still improvements happening in the Fortran space, and there's been a bit of revival of sorts. There are still features in Fortran that make it nicer to write in than C++ (and while I'd hoped rust might be a good Fortran replacement, I feel rust has taken a different path, and remains no better than C++).

[pklausler]

New CFD codes? Links?