Why I think Rust is the "language of the future" for systems programming

Right, but we have C for that. I also doubt that Rust would be suitable for hard-realtime applications, due to the fact that it has garbage collection. Even task-local garbage collection is still garbage collection, and not what you want for hard-realtime applications.

Of course there's a bunch of different definitions of "hard realtime" floating around, and rust would probably be suitable for some of them. I fully expect that someone will reply to this with something like, "Well MY definition of hard realtime is playing movies, and Rust is suitable for that." :) But when I think of hard realtime, I think of applications where you must have absolute determinism.

Implying that you don't exactly even know the language, if it really is such a mess you think it is. I bet a bunch it really isn't.

> I actually cannot tell whether C++1 made it better or worse.

This really just shows the fact that you are clueless about C++ and what C++11 brings to the table. Whatever you think has no relevance. Not because your opinion would be less valuable, but because you can't be objective about something you don't understand. You just follow what you hear from others - often times those who are in the same situation. Hooray for circle jerking over how C++ sucks. This leads nobody nowhere.

This is a major problem with C++, but it's mainly a problem for people who don't write any C++.

So what does C++11 bring to the table? To mention some:

Safety - Standardized smart pointers, nullptr, better type-safety

Performance - Rvalue references, move semantics, constant expressions with constexpr

Concurrency - Standard facilities for threading, async, futures

Language features - lambda expressions, support for UTF8/16/32, uniform initialization

Libraries - std::chrono for various time handling facilities, standard random number engines and generators, hash tables, regular expressions, tuples

There's also plans to introduce more libraries to C++ next year, and evolve the language through libraries rather than the core language specification.

Many of the problems people face with C++ can be avoided, and people know it. Many of the problems in existing code bases are fault of poor design. (Blaming C++ for multiple inheritance because the designer shot themselves to the foot by not being competent at designing software is a prime example. It's not like the same functionality couldn't have been implemented via policy-based or component-based design for example. Easier to blame the tool than the user, I get that.)

Of course, those who use the language just avoid them and those who don't use the language keep bitching about them. Strange.

> Safety - Standardized smart pointers, nullptr, better type-safety

> Of course, those who use the language just avoid them and those who don't use the language keep bitching about them. Strange.

Dumb pointers are built into the language. They just look like an asterisk.

Smart pointers are, at best, something like `unique_ptr`.

So C++11 continues to have the error-prone variant as the default, and you have to import a stdlib thing and put some ugly incantation on every pointer in your entire program to finally get memory safety. But you expect those who use the language to "just avoid" broken features like dumb pointers -- the features that have dedicated syntax, the features that take 92% less typing and reading effort, the features that have been around for twenty-nine years.

Your argument is that C++11 is great because they tacked on a bunch of stuff to fix the core language, and obviously I should just ignore the core language because the other facilities are so great. In fact, you deride anyone who uses the core language as merely not understanding C++ well enough or creating "poor design"—even though multiple inheritance has built-in syntax and component-based design does not. (Rust has no MI, and its traits look like they'll map quite well to components. Hm!)

You are blaming the user for not using the tool in a way it was clearly not designed, because that other way happens to work better. Maybe it's not just me. Maybe, just maybe, this tool sucks and you're so used to it that you can't believe anyone else would possibly not want to use it.

I'm interested in Rust because it lets me do systems programming without having to avoid the entire core syntax because it's all broken, without having to worry that whatever I'm doing might be bug-prone but only hanging around because C did it, and without having to deal with rhetoric like this implying that anyone who doesn't think favorite tool X is the height of perfection must just not understand it well enough. I've had my fill of that crap from the PHP crowd.

A lot of go's compile speed comes from how simple it's syntax is besides the gains it gets from avoiding C++ dependency issues. Java's syntax while less complex than C++ is still complex compared to go's. And it won't have go's parse time savings.