[adkadskhj]

Disclaimer: Rust fanatic

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.

[duped]

If you're hiring for specific language experience you're doing something wrong

[jatins]

Would be true for other languages which are more or less similar enough that knowing one is enough: Java, JavaScript, Ruby, Python et al.

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.

[gravypod]

A great example of this is Jane Street. They write "all" of their software in OCaml. They have a 2 week up-to-speed course about their tools and language. I don't expect it to take too much effort to get up to speed in any language if you're already a programmer. You might. It be peak efficiency but you'll get pretty good faster than you think. The static friction force makes it not feel that way

[adkadskhj]

> 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.

[adkadskhj]

This statement is so odd. So we should hire to bring on people who want to work in PHP, and then force them to use Rust?

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.

[duped]

What I mean is that hiring for particular languages is a massive red flag to me in job listings.

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.

[adkadskhj]

> 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.

I think i addressed this in my edit. We are not doing this.

[twic]

You should hire people who know a statically typed language and prepared to learn Rust.

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.

[adkadskhj]

> You should hire people who know a statically typed language and prepared to learn Rust.

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.

[twic]

What you said was (my emphasis):

> 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!

[johnwheeler]

Not true. Rust is significantly different from mainstream languages and has a greater learning curve due to the borrowing system.

[duped]

It's not that hard to learn nor is it significantly different. The borrow checking rules are very simple and something that even novice C/C++ programmers follow, implicitly or otherwise.

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.