Comparing Rust and C++

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.

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.

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?

Regarding the futures:

These are futures that you only can synchronously wait on (like what is currently available as std::future). However there is no possibilty to attach continuations that run when the value of the future is available. E.g. like the C++17 concurrency proposals, C#'s `Task` type or Javas `CompletableFuture`. These all rely on storing some kind of callback or closure inside the Future. That's not easy in Rust because it leads to situations where ownership is no longer obvious. The continuation might need to capture objects that are still needed locally (so you need something similar to Rc> ). In the most simply example's the continuation needs a mutable reference to the Future itself whereas the Future-producing operation also has one. And if you have possibilities that the continuation could run on another thread/executor than the calling thread (which is possible with the other languages) things get more complicated.

Regarding asio. You don't have to deep dive very much here: Simply consider boost::asio::async_write(socket, buffer, [](error_code, bytes_transferred) { /* Do something with the result */ });

You need some mutable objects (like socket or the object that contains socket) locally AND you need acccess to them in your continuation. This will only work "safely" with garbage-collected or ref-counted types and these do still not seem to work for interfaces.