On the reverse side of things, trying to find a C++ dev is usually harder than finding people who want to write Rust.
I was _really_ tempted to take a C++ job at some point but I held out.
But not the other way around.
Smart pointers? Just Box, Rc, Arc and Refcel.
Move semantics? It's just another name for ownership.
Sure, the OOP stuff are different, but okay, that in and of itself shouldn't hinder you.
https://en.wiktionary.org/wiki/bikeshedding
If you think the differences between C++ and Rust are "unimportant but easy-to-grasp issues" then you may not know enough about either/both to contribute to the discussion.
We're talking about differences so impactful and well-recognized that everyone from Google[1] to the NSA[2] is advocating for using Rust to reduce the unsafety compared to C++. Are you saying all of them are bogged down in bikeshedding?
[1] https://security.googleblog.com/2022/12/memory-safe-language...
[2] https://www.nsa.gov/Press-Room/News-Highlights/Article/Artic...
But I'm a bit confused by your statement. There's a lot of overlap in the domains that C++ and Rust serve. Isn't it a good thing for job candidates to have an interest in learning about other approaches to their work? To understand what makes C++ better or worse than Rust in difference circumstances?
Why would a mere mention of Rust be a red flag?
This red flag cultural trend is blinding people to nuanced thought.
docker run --name docker-nginx -p 80:80 nginxIt would be a red flag if you were interviewing for react and decided to bring up vue or svelte or angular or whatever else as well.
It’s not like it’s only this C++/Rust type deal that is being picked on. Although I would suggest that rust fans tend to be particularly ardent and loud at the current moment, so interviewers may be far more turned off of you as a person just for bringing it up. Interviewers probably felt this way about people bringing up Python 20 years ago (Python devs of yore were WAY WAY worse about their “HAVE YOU HEARD THE WORD?!” Than rust devs are today), blockchain 7 years ago, etc.
Anyway. As an interviewee, I’d probably try to avoid being the one to bring up alternative technologies.
But nowadays it seems like one has to 'turn on' an interviewer and avoid a minefield of forbidden words to get a job. If a workplace is to become a toxic cult-like environment being policed against such thoughtcrimes as being curious and interested in technology for its own sake I think one would be fortunate to be passed on after an interview to enter such a place.
...why?
Seriously, why on earth? I don't follow this train of thought at all; if they demonstrate proficiency within the scope of the position, why does it matter if they also happen to know other technologies?
"Oh, Alice? Yeah, she was a great candidate, unfortunately she also had experience in Vue, so there's nothing we could do. We decided to hire Bob, who has 3 years less experience with React, but fortunately that's the only stack he's ever heard of."
If anything, it's a sign the person is interested in learning, most great devs I've met were not proficient only with a single technology. This sounds completely alien to me.
Nobody is saying to not expand your knowledge. You’re assuming it of this because it’s literally your only argument, but it’s an unfortunately shitty one, as most logical fallacies tend to be.
Nobody said “don’t have wide experience” but you. What I did say was “I’d probably avoid being an ardent fanboy toward an irrelevant to the interview tech stack”. And that “it’s most often best to leave irrelevant digressions to the interviewer”
Again, you go ahead and give out all the shit tier interview advice you like. For people that actually want jobs, probably try to stick to what’s relevant.
Could I imagine a scenario where it's a non-sequitur? Sure. Not really "don't hire this person" worthy, though.
Rust is hardly a random choice. You can debate its merits for some domains, but replacing C++ in most of the places that C++ is used is exactly what Rust was built for and is widely recognized as doing well at.
> just because
If your engineers are pitching a technology with no more basis than "just because", I can understand dismissing them out of hand. But ask yourself if that's actually what happened, or if they gave specific reasons justifying their proposal and you dismissed them out of hand anyway.
Even if you disagree with the reasons, or agree with them but conclude they are outweighed by other arguments, either of those is totally fine, but dismissing them as "just because" is not an effective way to make technical decisions as a team.
You go ahead an interview however you like, but generally, giving your interviewer a feeling that you plan to shake up their tech stack because you feel like it isn’t going to go well.