You are very fortunate: In my 20 year career, I've spent most of it surrounded by zealots, including at very well known firms. I am currently surrounded by multiple teams with extremely tight ideas of what languages they want to work in. All different ideas, yet they are working basically with the same constraints: it's not as if they ware doing very different work where another team's language would be unfit for purpose. The performance is similar, and they are basically in a culture war. They have passionate arguments listing why a different team's choice is all wrong: None hold any real water.

I am especially valuable because I am fine reading and writing any of the languages involved. The management likes that, but there's a lot of difficulties solving the tribal problem, as the leads are basically all crazy zealots, and it's not as if purging one or two factions of zealots would avoid further zealotry from the survivors. The fact that I can work across all their tech doesn't make me many friends, as my work across systems shows their arguments have little merit.

For most work, in most cases, most languages are just fine. The completely wrong tool for the job is pretty rare, and the winning argument in most places is "we have the most people that have experience with tool X, or really want to try exciting new thing Y", for whatever the problem is, and whatever X might be.

Most of the people who use Go and Rust do it for pragmatic reasons. That doesn't influence the culture of the zealots in each community.

You should search for headlines on HN that say "written in Go" or "written in Rust" and then compare that to the number of headlines that say "written in JavaScript" or "written in Kotlin."

To be honest, I agree with you, and I think this is the right approach to life if you have a strong preference for languages. I think this only gets a bad name when people aren't upfront about their preferences and skills, with a lot of people having bad experiences with a go zealot at some point.

I have to say that the median crate I interact with has the following readme:

" Version 0.2 - Unstable/buggy/slow unless you use exactly like the example - not going to get updated because I moved on to something else"

Rust is another programming language. It's easier to write code without a certain class of bugs, but that doesn't mean version 0.2 of a casual project is going to be bug-free.

It’s not that I don’t believe you, hut that I’m having trouble seeing how what you say could be true.

Rust projects immediately become “done”??? They don’t also having changing requirements and dependencies? Why aren’t everyone at the best shops using it for everything if it massively eliminates work load?

Not from what I've seen. The compiler is slow af which plays badly with how fussy the thing is.

It's easy to have no defects in functionality you never got around to writing because you ran out of time.

Having watched two entirely fucked up Rust projects get written off I think you need to get out more.

It's like a perl script you wrote on acid. It's done because you cannot enter that mindspace anymore and the code you created is like the output of an encrypted password with no path back.

Are you saying that Rust is always the right choice for any problem? If not what’s the link between the merits of any technology and the guarantee that the selection was not resume driven?

A sibling thread talks about language zealotry and this is a textbook example.

I didn’t realise that the only requirement for well-written code is to have an expressive type system and memory safety.

What a load of BS. Even if initial time saving was true because of "no bugs feature" and it is not. Any software product that serves real business needs usually constantly evolves. Most of the time is spent on planning new features and integrating those into existing architecture.

You forgot the /s