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.

So it makes you think before typing and compiling the code?

Doesn’t look like a con to me :)

Here's a great life hack for you. Set a 15s delay whenever you type in an editor. That way you'll think more before writing code.

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.

Yup. It's easy to write a to-do app. What is hard is 10 years later of features and needing to add more. While also dealing with the architecture short sightedness and pitfalls. Anyone who has worked on legacy software knows, at some point, all architectural decisions eventually become architectural pitfalls, primarily because requirements and customers change. It becomes a point where, its not really the code that's the issue, its design and customers' changing requirements.

You forgot the /s