[_callcc]

As a younger programmer, speaking honestly, it seems to me a significant part of the motivation behind Rust evangelism has to do with distinguishing yourself against older colleagues who have 20+ years of C systems programming experience. When you find yourself in a field that's supposed to be new and fast-moving, yet you're stuck in a junior position waiting for the old guys to retire, potentially for years, as if you're a journalist or academic or something, it's not hard to see why people look to develop a different skill set.

[notacoward]

I get the same impression, and not just from Rust. It's pretty common for most new (or newly-popular old) languages. There will always be a certain percentage of programmers who are less out to solve problems than to look or feel better than other programmers around them. What better way to do that than in a language nobody else at your company knows? Nobody to correct your style, or your use of a deprecated idiom. More glory for writing a library that didn't exist yet in that language than for improving one that already did. You get to write the early blog posts and tutorials, maybe even a book, secure yourself a permanent place at the conferences, etc. The Javascript community (like the Ruby community before it) is full of people who came from Java for those kinds of reasons. There's a similar migration path from C/C++ to Go and now Rust. A long time ago, you might have found emigres from Pascal/Modula/Ada to C.

There are many reasons to move from an older language to a newer one. There are good reasons, and there are bad reasons. I think language designers and evangelists generally do a good job of focusing on the good reasons. It's unfortunate when such advocacy tips over into FUD, but I suppose it's inevitable too. Nobody likes to see their investment devalued because their favorite vehicle to fame and glory lost out, even if the alternative really was even better.

[jcranberry]

I think there's some of that, but a large part of it the very strong user-first ideology in applied CS. Not that I'm critiquing user prioritization (at all), but the problem of categorizing what's unnecessary overhead to be handled beneath the hood by tools and what should be left up to the developer to handle is a problem that has no unique solution/is highly context-dependent.

I think younger programmers' frustrations with old, difficult (and sometimes useful) tools along with their drive to modernize everything occasionally drives them to misdiagnose something as "legacy bullshit that isn't user-oriented enough" vs. "a powerful tool which is still necessary with limited uses".

[ricardobeat]

How does this all relate to language safety?