Sidenote, i think a lot of the tech crowd forgets how much industry will lag behind popularity, for a whole bunch of good reasons. My shop uses Rust, and all our hires are aimed at Rust, and it's still not easy - there's not a ton of people who know Rust. We would have a ton of candidates in Python, JavaScript(Node), even Go. Hell even PHP.
The fact is that applicants tend to follow jobs, so you get a chicken-egg problem. New languages have a huge hill to climb in adoption and it takes years for companies to build up large codebases in new languages to result in a large job pool.
Take any previously popular, old and uninteresting language and know it well - and you can get jobs for years and years and years to come. There's just a ton of code out there written in it that needs support, extension, etc.
I always recommend learning Rust but it is certainly not a must.
But for Rust, looking for language experience might be the right choice since the learning curve is relatively steep and takes time. Unless, of course, the company is okay giving 2 months to just learn.
Yea, this is our opinion. Our options are limited due to the smaller talent pool, so the time it takes for devs to "spin up" is something we consider. We can't hire a full team of devs who take 2 months to spin up. We can, maybe, do 5 young devs and 5 seasoned devs.
I've personally found that devs who have experience with C++ are almost a direct shoe-in. They know all the concepts and the transition seems easy, especially since they're already interested in Rust. Having hired a few dynamic language folks though, they have a higher barrier to entry with Rust. A lot more concepts to learn.
We have a large codebase in Rust. We're hiring devs who want to use Rust. Why is that "doing something wrong"?
edit: Maybe you think we require full Rust mastery on hiring. We don't. Though we make it clear that work on a Rust codebase is ~~expected~~ required, and familiarity with generalized concepts like static/dynamic dispatch are important. We hire young Rust devs all the time.
I don't mean saying something like "our tech stack is in Rust." More like "3-5 years experience in Rust" under the job requirements.
It's not hard to learn a new language or train it in good engineers. If you're limiting your candidate pool based on particular language experience you are severely limiting the growth potential of the business. That's just been my experience.
And if your reasoning is something like, "Rust is hard and it's going to take N weeks to onboard a dev to contribute and we can't afford that" then it's an even bigger red flag about the engineering capacity of the business and state of development.
I think i addressed this in my edit. We are not doing this.
I learned Rust (and C++!) at my current job, with Java being the only statically typed language i knew before that.
Unless you have reason to believe that a significant fraction of otherwise smart and capable static-language programmers will just never be able to learn Rust. I have no idea if that is true or not, and it would be interesting if it was.
I believe i said exactly this. Specifically i said:
> We're hiring devs who want to use Rust.
Which seems clear to me. My edit also addresses new Rust devs. Our requirement is that you want to work in Rust. Which shouldn't be shocking or controversial.
> My shop uses Rust, and all our hires are aimed at Rust, and it's still not easy - there's not a ton of people who know Rust.
Which rather implies that you are trying to hire people who already know Rust. You then asked rhetorically:
> So we should hire to bring on people who want to work in PHP, and then force them to use Rust?
Suggesting that you saw this as the only alternative to hiring people who already know Rust. I was pointing out a third possibility which i thought you had omitted.
So i wouldn't agree that this was exactly what you said. But, of course, i am very happy to hear that this is what you are doing!
The "hard" parts of Rust are the usage of lifetimes in generic heavy code (especially combined with function traits in order to be generic over closures), object pinning, and soundly operating in unsafe. Those are advanced topics to be sure, but they are not something you would expose a newbie to in the early days of onboarding.
Rust is a good language in many ways - generally well-designed, innovative, aimed at some under-served but important use-cases, very educational to learn, and surrounded by a lively community.
But only a tiny fraction of the world's work and innovation is being done in Rust. There is a huge amount of interesting stuff happening in other languages. There is also much more work available in other languages - even interesting, well-paid work.
Reasons to learn Rust right now:
1. You need to learn a low-level systems language, for use on a platform that Rust supports; i think Rust is a better bet for many uses than C++ already.
2. You have copious time to invest in learning, and ownership type systems are the most interesting or powerful thing you don't currently know.
3. There is some specific piece of software you want to get involved with, and it's written in Rust.