any reasonably good eng culture recognizes that the language is often the least important aspect of engineering a solution.

A rust engineer that knows why the borrow checker exists and can safely do unsafe operations likely will do fine in C,C++, Go, Java and many others.

That was before. Now they can pay attention to even the least important things.

I am constantly seeing one job posting in the past 6 months looking for Elixir engineers that already shipped production code...

As someone who did this for "low-latency min-allocation Java", the answer is that I have the need for this X now but I'm confident they can adapt to whatever comes later. The truth is that anyone on my team can become proficient in this given time, but I'd rather get someone who can juice the machine by showing up with existing knowledge and we'll all get ahead faster with them. I wouldn't fire someone in order to get this person for various reasons (some obvious, some not).

> rather get someone who can juice the machine by showing up with existing knowledge

This doesn't feel like a sustainable way to build engineering org. You only get N chances for such 'juicing', what do you do when you need to juice but don't have open headcount. You have to come up with a strategy for that anyways, so why not implement ' want juice but no headcount' strategy and expand your hiring pool.

I've also found that people who sell themselves as "Rust/SAP/Java engineer" seem to have a huge bias against anything else which makes sense since they've built their careers selling themselves as experts in a particular niche.

There is a niche of Rust SAP Java engineers? Wow :)

yes its the next big thing.

We're a small prop shop. I don't need to do sustainable in the way you're thinking. And I think we might be speaking at cross purposes. I want someone with a skillset. I'm going to hire them for that skillset. That doesn't mean they only have that skillset but that's the thing that provides utility.

oh got it. Thank you for the clarification!

Some part of the answer here is that we aren't a company that only works on our own products or research - we have a bunch of client work as well. But yes, "low-level" language could be used here as well.