I am not sure it is ever true that there are no doubts about C++ being "right." It might be "good enough," but it is a generally bad language that would not be my first choice for anything (I would sooner use C, but even that's not my top choice).
It's not about experience, it is about the language. Modern C++ is basically a motorized stone hand-ax. Even experienced C++ programmers are surprised by undefined behavior and unexpected semantics.
A significant amount of undefined (and unexpected) behavior in C++ is inherited from C, for compatibility. You'd sooner use C, and fall into undefined behavior quickly as well.
C++ is large and hard to master, but I don't think UB is the best reason to choose C over it.
I use both C++ and Scala on daily basis and there are just a few things I wish C++ had from Scala. On the other hand it is a huge time saver not having to worry about the JVM GC freeze.
C++11 has a few nice features, but it is really dragged down by low level issues. You talk about garbage collection like it is a problem, but C++ still does not even offer good garbage collection (not even optional garbage collection) for those situations where it makes sense. At least with Java you do not need to manually break cyclic references to prevent memory leaks.
As for closures, why would I want to specify which variables are captured? If I reference a variable from the enclosing environment, I capture it. If I mask the variable, I do not capture it. What point is there in explicitly declaring this? Frankly, the entire C++11 approach to closures is insane. Why add the extra syntax to explicitly declare how variables are captured, when capture by value covers all cases?
Since it has deterministic destructor and RAII is easy to implement, garbage collector is not needed. It works not only with memory allocation, but any other resource you need to release: mutex, serial port, window handle, file handle etc.
Also move schematics really helps with performance: create, copy & destroy can be avoided altogether. No garbage, nothing to collect. :)
BTW, Normally you should avoid "new" and "delete", only very special use cases need it.
Specifying the closure variables is optional and it is both for performance and encapsulation. You can specify "nothing", "everything by reference", "everything with copy", just some by copy or reference - mix & match.
If this is too much to start with then just copy everything with [=] and clean it up later if it turns out to be a bottleneck. The point is: you can save on cycles if you want to/have to.
If you think C++ is not a match for you, that's OK, there are plenty other languages.
You don't need performance all the time - some are OK with 400 queries/sec, others want 7,000 on the same server: http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...
"Since it has deterministic destructor and RAII is easy to implement, garbage collector is not needed"
This is kind of like saying, "x86 has CALL, PUSH, and POP operations, so there is no need for a language with subroutines! Just use inline assembly!" Garbage collectors are not strictly needed in any imperative language. The point of garbage collection is to enable programmers to think at a high level, without having to divert their attention to low-level issues.
"Also move schematics really helps with performance: create, copy & destroy can be avoided altogether. No garbage, nothing to collect."
Move semantics are a solution to an artificial problem. Sensible defaults like allocating objects on the heap and using references everywhere would have solved this problem and many others. Yes, I know that the C++ approach to programming is supposed to give programmers the power to do things for themselves, but that does not mean that the default semantics have to be brain-damaged. If code like this:
std::vector<int> vec;
Caused an object to be allocated on the heap, and created a reference to that object, move semantics would not be needed. To stay true to the C++ way of doing things you could have a special non-reference type. Note, of course, that this really needs garbage collection to work well, and that the garbage collector would be entirely optional (as Bjarne Stroustrup suggested): programmers wanting to avoid the garbage collector would use non-reference types and pointers to non-reference types.
"Specifying the closure variables is optional and it is both for performance and encapsulation"
I am not seeing how it makes sense for either. Specifying anything about how variables are captured is a pointless exercise. Variables should just be captured if they are not shadowed, and they should always be captured as copies. When programmers need to capture by reference, they should just create a reference and capture that. Introducing another syntax just to declare how variables should be captured, and then making another nonsensical default behavior (no capture at all), is just silly.
"You don't need performance all the time - some are OK with 400 queries/sec, others want 7,000 on the same server"
You know, it is not a very strong argument when the top result (in C++) is only marginally faster than the next best (in Java). The fact that another C++ framework happens to be much further down, below systems written in Java, Scala, PHP, and Lua, is also not helping you. If anything, that test shows that the cost of using a high level language is not so bad; fantastic performance can be achieved without having to fumble around at a low level, and low level languages like C++ are not a guarantee of good performance.
Google after benchmarking C++, Java, Go, and Scala:
"We find that in regards to performance, C++ wins out by
a large margin. [...] Scala concise notation and powerful language features allowed for the best optimization of code complexity."
Yeah, let's use a memory unsafe language, handle memory management by hand and just completely ignore the fact that no human being has ever managed to consistently write bullet-proof code in it.
Using software which automates memory management, engineered by the brightest minds on this topic, is for hipsters, right?
I guess you also roll your own crypto and implement stuff in assembler “for performance”?
Sometimes you need performance or there are other constraints, in which case your choice of language is very limited.
Automated memory management works, but not all the time.
And how about other resources? How you make sure your mutex gets released? Add a comment "please don't forget to release this one"?
How about file handle, temporary file, serial port, DMA, GPU, network port and other limited resources?
BTW, I think most of the brightest minds you mention use C or C++ on daily basis. :)
"Automated memory management works, but not all the time."
[citation needed]
"BTW, I think most of the brightest minds you mention use C or C++ on daily basis"
I doubt it. Most of the brightest minds I have met, at least in academia, use high-level languages: Python, OCaml, Lisp, Haskell, etc. They have more important things to worry about than whether or not it is safe to deallocate objects.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses"
Do you realize that almost everything widely used today is implemented in C, C++ or ObjectiveC?
All the operating systems (Linux, Windows, Mac, iOS, Android), most of the desktop apps (Office, Photoshop), programming languages (PHP, Ruby, JavaScript, Python, both Sun and IBM JVMs), browsers (IE, Chrome, Firefox), web servers (Apache, nginx), database (Oracle, MS SQL, mySQL, Postgres, Redis, MongoDB), Google's search engine, eBay, Bing, Facebook, most of the games, embedded medical devices etc.
"Do you realize that almost everything widely used today is implemented in C, C++ or ObjectiveC?"
Yeah, and we are plagued by the bugs and security problems made possible by those languages. Imagine how much more we could be doing if programmers were not spending hours trying to figure out where a dangling pointer was created.
Really, the popularity of C, C++, and related languages has little to do with the languages themselves. C became popular because of Unix, not because of its technical features, and Unix became popular because of its licensing. C++ became popular because of Windows, not because of its technical features; Windows became popular because of the Unix Wars and because of MS Office. If Unix had been written in Lisp or ML, we would be talking about how popular Lisp or ML are. For what it's worth, entire operating systems were written in Lisp at one time; their failure had nothing to do with their technical merits and everything to do with terrible marketing and bad predictions.
If you want to talk about how fantastic C or C++ is, try pointing to an overwhelming success story that could not have happened without the language. Altran Praxis has the lowest bug rate in the industry; they credit the SPARK programming language, which is well-suited to the formal verification techniques they rely on. The military planning system DART paid both its own development costs and several decades of research that led up to it; it was thrown together in a few weeks using Lisp. I have yet to hear that kind of success story from C++ programmers; the only thing I ever seem to hear about are squeezing a few extra clock cycles out.
If this were a popularity contest, we would still be hand-rolling assembly language. The same reasons that led programmers to use compiled languages apply to switching away from low-level languages like C and C++. Sure, people are still writing assembly language, but it is a niche. That is where C and C++ should be: a niche, mostly just for maintaining legacy code that is too expensive to rewrite in a better language.
