Hmm. Can't say I agree here - at least not with the literal text of what you've written (although maybe we agree in spirit). I agree that _simplistic_ strong opinions about languages are a sign of poor thoughtfulness ("<thing> is good and <other thing> is bad") - but I'd very much expect a Staff+ engineer to have enough experience to have strong opinions about the _relative_ strengths of various languages, where they're appropriate to use and where a different language would be better. Bonus points if they can tell me the worst aspects about their favourite one.
Maybe we're using "opinion" differently, and you'd call what I described there "facts" rather than opinions. In which case - yeah, fair!
Even simple requirements can rule out languages for me. Like, if you need async or concurrency, Python is awful. If you need SQL in your code, Golang isn't great. If you are building a simple CRUD backend, Java is waste of time. If you aren't doing anything compute heavy or embedded, why even consider C++ or Rust. The list goes on.
But in reality it rarely matters. If you were only allowed to use Java as a backend and your competitors could use anything your company would succeed or fail based on marketing and sales. The backend doesn't matter as long as they both have the same features.
I understand developer preference and different languages make things easier and make programming funnier. Languages have different limits.
As you become more senior you realize getting around those limits is part of the magic. If you come on to a project where the existing developer wants to write the backend in javascript because that's what they know I would rather use Javascript then wasting time trying to push a more 'pure' choice. Because in the end I am capable of writing it and what we will be judged on is if it works to achieve an objective not if it was the best language choice when using differentiation.
I might personally love to kick off a greenfield project with Elixir, and it might tick all the technical boxes and meet the requirements. But then I have to pay a premium for senior engineers that know elixir or have to price in the time needed to upskill.
Or I could just do it in Rails where I can dip into a much larger talent pool and still meet the requirements. Much more boring but can get the job done just as well.
(Mostly .Net, PHP and Ruby)
See, we can all generalize. Not productive.
Only thing I ever saw from Golang devs was pragmatism. I myself go either for Elixir or Rust and to me Golang sits in a weird middle but I've also written 20+ small tools for myself in Golang and have seen how much quicker and more productive I was when I was not obsessed with complete correctness (throwaway script-like programs, small-to-mid[ish]-sized projects, internal tools etc.)
You would do well to stop stereotyping people based on their choice of language.
That's pretty much another way of saying that stuff becomes a whole lot quicker and easier when you end up getting things wrong. Which may even be true, as far as it goes. It's just not very helpful.
FWIW I very much share your exact thoughts on Rust skewing metrics because it makes things too easy and because stuff almost immediately moves to maintenance mode. But that being said, we still have some tasks where we need something yesterday and we can't argue with the shot-callers about it. (And again, some personal projects where the value is low and you derive more of it if you try quickly.)
What do you think all programming discussions about languages, typing systems, runtime, tooling etc. aim for?
EXACTLY THAT.
If it was as easy as "just give me thing" then programming would have been a solved and 100% automated problem long time ago.
Your comment comes across as "if only we could fly, we would have no ground road traffic jams". I mean, obviously, yeah, but we can't fly.
Your comment also comes across a bit elitistic and from the POV of an ivory tower. Don't know if that was your goal, if not, I'd advise you to state things a bit more humbly.
