Comparing languages with constraints which were laid in bedrock 30 years apart is fairly uninteresting. C++ is constrained by its compatibility with C, and always will be. Even C++17, which will be the biggest shift in the language ever, won't change this.
I see very little evidence that most programmers actually care about the advantages Rust the language, as specified today, brings. I'd contest that these days the biggest reason competing languages like Go, Rust, Python, PHP and Java often trump C++ is less to do with the language, and more to do with these languages having sizeable and fairly decent standard libraries. Programmers want to get shit done.
The C++ standard library is tiny and has seen fairly paltry growth over the years, with only modest introductions in C++11 of things like regex and threads. If a set of filesystem, HTTP, networking, and serialization libraries were part of the standard, and well implemented, we may well see a different landscape.
> more to do with these languages having sizeable and fairly decent standard libraries.
Rust actually has a pretty small standard library. Since we have a package management system so early in the lifetime of the language, we're leaning on that rather than having a large standard library.
HTTP is welcome, but I'll take logging, JSON, XML, unit testing, and a database interaction layer before that. Most of those are types of "serialization", I guess, but I'll go ahead and be a little more specific.
And a type-safe dependency injection framework wouldn't be the worst thing in the world either.
HTTP is a continued pain point for C++ I find. It falls in to an impossible valley of "too simple for anyone to have bothered writing a really good standalone library" and "too complex to write myself". I don't see anyone jumping at the chance to build a HTTP request state machine built on top of nothing but the standard library when the standard library has no standard solution for efficient asynchronous operations or task scheduling.
I'm not saying it's not needed, but there's a huge chunk of the C++ world that doesn't do web development. The other things I mentioned are more generally useful. In particular, XML support probably needs to come before HTTP support.
Not that I'd turn my nose up at standard HTTP support.
I recommend the libraries from CodeSynthesis for your XML and database needs. The documentation for both is superb, and the APIs are crisp and modern. JSON I'd go with either JSON Spirit (boost header dependency) or JsonCpp (git version[0], since there hasn't been a release in 3 and a half years. 1.0 was tagged recently though)
For webdev I've personally used CppCMS, which is of good quality, although it is a framework and not a toolkit (it's MVC and the views want to use inheritance, has its own networking and template framework etc)
I know there are libraries out there; I was talking about getting more things standardized so programs can mix and match these libraries with fewer translation layers. For example, boost spirit is a bit out there for most projects.
It's tricky and there is no one-language-to-rule-them-all because they have up- and downsides.
C++ has the advantage of an incredible amount of code written in over the years that mostly works. It also executes fast. It's also easy to find developers for it. With the new addons to the specification it's even possible to write readable code with it.. However, it has a stupidly long, verbose and feature creepy standard (well over 1000 pages), which results in no developer reading it. Because of it's design, compilation times tend to take long (as a ridiculous amount of headers are included even in the most simple applications).
Go is pretty much the opposite. It has a lean and readable spec (on purpose) and a fairly common canonical syntax without much discussion about it. Because it's relatively new, there is not much written in it however. It has some specific strengths, like a concurrency implementation that abstracts most of the process/thread/mutex stuff. With this, it does appeal to new projects that don't depend on libraries written in other languages. There is no point in porting multi-million SLOC applications to Go though, as that would be incredibly time-consuming. It has the potential to surpass C++ in a few decades though, as it operates in the same domain (systems programming).
Python is a versatile scripting language. It has nice syntax and is incredibly flexible at manipulating data. Add to it the well documented, feature-rich standard library. With it you can evaluate data with incredible flexibility and it has a fairly complete feature set for general programming tasks that span multiple OSs. The downside is that it's slow in execution and needs the interpreter along the scripts. Especially for smaller tasks and simple automation it is the first choice however because of it's small footprint in constraints (you can just edit and drop a scriptfile anywhere on a Linux system and it works).
Java.. I'm not entirely sure what Java does well. I hear praise for the JVM, but generally I get the impression that it is plagued by legal issues, alien looking GUI tools, more than verbose syntax and it also has a stupidly long specification (almost half of C++'s). Maybe someone can shed light on this one. Tools maybe?
The C++ language specification is only ~450 pages, the rest of the ~1200 or so pages is the standard library specification.
> Java.. I'm not entirely sure what Java does well.
* Package/module system is dead "drop your JAR here" simple.
* Humongous standard library.
* Oracle provide a really powerful free JIT (probably still one of best for real world performance when it comes to JITing static languages)
* Standardised language specification (like C and C++)
* A well specified, really simple bytecode that other compilers and runtimes can target.
* It's a newbie friendly, procedural, object-oriented language that encourages 'patterns' that make developers feel comfortable and that they know how to tackle problems (whether it's the right way is another matter)
* Relatively safe, meaning there is less to learn (no pointers, memory management, arithmetic overflow etc).
I'd disagree that Go is a systems programming language in the way that C++ is a systems programming language. As in, I'm not sure you would implement a garbage collector in Go. However, both Go and the typical processor are evolving, to that may change over time.
To be fair, if I were wanting to find all matches for a regular expression in a given text file, I sure wouldn't use C++, even though C++ is certainly capable of doing that.
I see very little evidence that most programmers actually care about the advantages Rust the language, as specified today, brings. I'd contest that these days the biggest reason competing languages like Go, Rust, Python, PHP and Java often trump C++ is less to do with the language, and more to do with these languages having sizeable and fairly decent standard libraries. Programmers want to get shit done.
The C++ standard library is tiny and has seen fairly paltry growth over the years, with only modest introductions in C++11 of things like regex and threads. If a set of filesystem, HTTP, networking, and serialization libraries were part of the standard, and well implemented, we may well see a different landscape.