>Almost any alternative option is better.

This is a naive comment. C++ is a very good option for a wide range of scenarios where trying to shoehorn some other trendy language in its place would be at least the same level of headaches to just learning proper C++ development. And you can also depend on C++ stability and future availability, which also makes choosing its latest high-level constructs a wise option over other new languages that compete to also offer new idioms to the programmer. C++ isn't perfect, but neither is any other language. If you really know C++, it is a logical choice for many new projects across many platforms and environments.

Well, please tell me what language will be good for developing a specialized image processing system. Considering all good libraries are all C++ and maybe have Python bindings. deterministic destruction + templates + low-level memory management + the ability to ascend to full java-like OOP with interfaces really do make it my favorite language.

Yes it has weird syntax and ugly default behavior, but that's a price for backward compatibility.

"This is dubious. Care to elaborate what you mean by that?"

I meant mainly the existing status quo as you elaborated in the following sentence.

"there's never ... a need to start a new project in C++. Almost any alternative option is better."

I agree that for a lot of things C++ is the wrong language. For some use cases, such as libraries supporting real time graphics on multiple platforms, I'm not yet sure if yet there are better options (well, there is C but I'm pretty sure that arguing which is better of those is a matter of taste and experience).

Since new C++ projects are being started today, reality contradicts your beliefs. Which one will win, I wonder - reality or dogma?

That something is being done today doesn't imply that it needs to be done today.

I expect the companies that are starting new C++ projects today to be put out of business by competitors using better languages.

"I expect the companies that are starting new C++ projects today to be put out of business by competitors using better languages."

I don't think that's how software business works. I'm pretty confident there are niches out there where even COBOL would be a just fine implementation language if it provided end value for the user.

Domain understanding, network effects and marketing seem to trump bleeding edge most of the time.

That's not to say there are no situations where selecting a better language would lead to far better outcomes if there is time pressure and the language is viable choice with the technical constraints of the project. I'm just highly skeptical that this is a rule that works in general.

For an extreme example where this rule starts to look dubious, embedded systems - are there any better languages even available?

Many embedded systems support Java or higher-level languages. OCaml might be an option; Ada or Rust certainly would be.

The problem with all of these, with the exception of Rust and Ada, is that it's hard to do things like, get at pointers directly, for example. For all of the abstractions OCaml and Java bring, there is an often large performance penalty to pay, and when you're pass producing an embedded product, that's money you're leaving on the table because you're asking for more compute power than you actually need to get the job done. Ada is usually a pretty good choice, but it's hard to find developers outside of the defense industry; Rust on the other hand is often view (perhaps rightfully so) as still experimental and unproven.

> For all of the abstractions OCaml and Java bring, there is an often large performance penalty to pay, and when you're pass producing an embedded product, that's money you're leaving on the table because you're asking for more compute power than you actually need to get the job done.

In my experience the performance differences are often grossly overestimated (particularly if you compare equivalent development times). And increased development time or higher defect rates aren't free. What you say is true for a particular niche, but I think that niche is pretty narrow (and in that niche I think the risks of Rust, while real, are smaller than the risks of C++).

Alternative explanation: things are done a certain way due to technical constraints and market forces which you don't know about or choose to deliberately ignore.

Entirely possible. But this is not "reality vs dogma"; it's one person's (or group of people's) judgement vs another.

At least in the storage space (which gets essentially no press on HN), I have come to the finding that the vast majority of core product codebases are C/C++. For the niche they fill, it seems really unlikely that even the still experimental Rust would replace them here.

Dropbox has re-written their storage layer in Rust https://www.reddit.com/r/programming/comments/3w8dgn/announc...

That said, they're the only one I know of, so your point still stands, generally.

> I'm using "never" rather than "rarely" very deliberately here

True, we could also have used FORTRAN.