[wolf550e]

It would really depend on what the project is (3d shooter game vs database server vs high frequency trading). But I think many projects can be broken into two parts:

One is a limited number of "computation kernels" (processing packets, processing transactions, computing a photoshop filter) that need to be very fast but can be carefully generated/handcoded in C or SIMD asm or whatever that has very simple behavior/API, for example it should not allocate memory.

The other part is the complicated part that has all the complex behavior (a lot of code, changing business requirements, opportunity for abstraction) that configures the kernels and feed data into them and interacts with the user and the network but takes a small part of the CPU time.

The second part must be organized so that it will not inhibit the first part in any way, so that means the second part can't use a language that won't let you layout stuff in memory in exactly the way you need or that has poor cffi performance.

The second part can be done in something as slow as cpython! (though it doesn't have to be quite that slow).

[blub]

You started with an absolute statement "C++ should not be used in 2017 for new projects" and in the following comments slowly but surely admit that the above statement is false.

It would be simpler next time to just state that C++ is not a must for all software. But we already know that, so maybe the whole discussion can be skipped.

[wolf550e]

You are putting words in my mouth. I did not say "should not be used". I wrote about my option and what I do. I did not mean this advice applies to everyone in every situation.

I think your approach is "default to C++ because of very broad support, write the cold code and the hot code in C++, optimize the hot code" and implicitly you also say "and damn the security and maintainability implications".

My approach is "use the safest and most maintainable language for all code that can tolerate the performance impact", so I would prefer to write everything in a higher level language than C++ and optimize using cffi, asm, etc. only the inner most loop.

Maybe modern C++ can overcome the weight of backwards compatibility and create a truly modern subset that is as safe and as pleasant to work with as newer languages. Then your approach would definitely be better. But I don't think we're there.

For example, I think of things like a web server, where the AES-GCM has to be assembly, the HTTP parser should be generated by a special tool and the rest should be in a memory safe language to avoid Cloudbleed. Can modern C++ be that memory safe language? If yes, I'm wrong.