C++ moving to a 3 year standard cycle is a much bigger 'threat' to rust. But really, the fact that there's so much actual investment in improving mainstream languages from various well-funded sources is probably a rising-tide-lifts-all-boats kind of thing.
Yes, I do agree that the situation is improving across the board.
But as an industry, we need practical solutions that are available now, even if somewhat flawed. We need languages we can use today, and know that the code we write today will still compile fine next week and next year, if not a decade or more from now.
Modern C++ is getting pretty good at offering this, while offering far a greater degree of safety. Go isn't bad, either. Scala has its drawbacks, but it's often a reasonable option, too. The key thing to remember is that all of these languages have offered developers a stable target, and they are seriously usable in the present.
Given the announcement of Swift, and given that Apple will very likely deliver on it by the fall, we very well could see it becoming a major player during 2015.
The safety benefits that Rust could theoretically or potentially offer are virtually useless to huge swaths of the industry as long as the predictability of a stable release just isn't there. The longer this wait goes on, the better the competition becomes, and the less relevant Rust will unfortunately become in the long term.
> But as an industry, we need practical solutions that are available now, even if somewhat flawed. We need languages we can use today, and know that the code we write today will still compile fine next week and next year, if not a decade or more from now.
By this logic we shouldn't invent any new programming languages at all. There's no such thing as a "practical solution that's available now"; everything takes time to develop.
> Modern C++ is getting pretty good at offering this, while offering far a greater degree of safety. Go isn't bad, either. Scala has its drawbacks, but it's often a reasonable option, too. The key thing to remember is that all of these languages have offered developers a stable target, and they are seriously usable in the present.
You aren't going to use those languages if you want memory safety without garbage collection. Because they can't offer zero-overhead memory safety without breaking existing code.
