Some people have to write C/C++. Kernel developers, for instance. But most people who write C/C++ in 2015 don't really have to. For every low-level game programmer or RTOS embedded systems use case you'll cite, I'll cite an unforced error that occurs 5x as often, such as "we wrote our custom database engine that only ever runs serverside in C".
"But most people who write C/C++ in 2015 don't really have to."
While greenfield projects might be able to start with a new language established products have quite a lot of inertia. Any production environment needs to factor in personnel training (or, hey, fire the tens of C++ developers and replace them with equally skilled Rust developers who are as famimiar with the domain requirements as the last lot..) and the costs and risks in architecture changes. Switching languages might not be even then feasible, given a common big ball of mud structure with computational modules, UI and domain logic cooked together into a delicious mess.
Even if the long term costs of a codebase written in Rust were, say, the tenth of the costs of a similar codebase written in C++ often the product development costs are not that large percentage for established ISV:s.
When the next greatest browser gets written in Rust, then industrial users start paying notice.
Why would I care of how organizations develop software? Because I need to get paid and I work inside an organization... I write C++ to earn my living, I don't want to write C++ home for fun.
So at home I wouldn't write C++ any way and at work I really don't have a choice :) - Of course, peoples situation vary.
On the other hand, Rust is not ready -- either from a stability or library perspective -- in 2015, most likely. What are you recommending the C/C++ programmers go to?
If you are using C or C++, it probably means you cant use those you have pointed out.
People can port Python and Ruby stuff to Go for instance and have advantages doing it, because the logic was already suited for managed languages.
But for C and C++ stuff is unlikely.. and for Rust the other possible option.. its kind of a productivity killer compared to C (even with the headers nonsense).
Its always a matter of tradeoff, and its not a casuality that C are alive and kicking til this day.. the language really has its strenghts.. and while every new lang in town claim they are the next C killer, well, in real life is much harder to make such a claim, and its not just because of the "old code that has to be maintained".
I know you are a security focused person, but security and safety is not the only one reason we choose a language to start a new project.
So until a really strong contender shows up (i particularly dont think Rust is it, but im sure there is a golden niche for it), they will still be with us, til we brake the current computation paradigm and algol and lisp langs doesnt make sense
Yes, because you remove a whole class of errors that might be exploited. Might be hard, might even be impossible, but they are there waiting to be taken advantage of.
Interestingly enough, very high performance java is a bit like rust. Almost all memory safe, except a few (10-100) lines off crazy unsafe stuff.
Of course it is possible that your C code has no memory issues and is verified to be safe, but I would not bet any money on it.
Also at the moment custom code is the last entry point for a hacker, but once all other things are hardend its the last guaranteed leak in the ship.
I also understand where C semantics can lead to faster code than e.g. java today. But I suspect that edge to disappear within the next 3 years. Just like java is going to make heterogeneous compute easy its also going to improve streaming over memory for speed where needed.
You know, I don't know if even kernel developers need to write in C/C++. Sure, those are the languages in which most kernels seem to be written, but couldn't kernels be written in, say, Lisp or Forth and have almost as much performance and at least slightly more security?
That's quite bold.