The serious answer here likely has several components:
- Some people and businesses have invested a lot in languages that governments are now trying to deprecate. When someone is told that their assets may be stranding, and please move on to
, they’re likely to get … grumpy. Both they and the government may be correct here, even if they’re at odds—they have different scopes and concerns. - Differing values. See e.g. Cantrill’s “Platform as a reflection of values”.
- Rust highly values correctness, which will feel like a straitjacket to a lot of people.
- It also moves as much error detection as it can to the compilation stage, which won’t sit well with people who want to get something out the door ASAP and then find the bugs as they happen.
- So it also encourages tackling complexity early rather than kicking the can down the road, which again isn’t to everyone’s preference.
More than half the points are just good engineering practice directly embedded in the language.
It tells a lot about the state of programming in general with the pushback we see with memory safe languages.
I’m down with Rust and I can’t wait for official support for embedded Rust in chip manufacturers, because until then, very few clients will be okay with using unofficial Rust cargos for their products.
Yeah, that’s the correctness focus. Some people dislike it as a straitjacket, some even take it as a personal insult because they see it as a skill issue. They, the good devs, shouldn’t be held back like that (spoiler: they aren’t as good as they think they are).
Personally I like that aspect of Rust, but I also write Python with a typechecker and a loong list of enabled lints in ruff. I can get the happy path done without it, but having just the happy path often isn’t good enough.
Enforced correctness helps a lot with confidence for those of us who know we sometimes make bad assumptions or forget some nuance or detail. But it will be absolutely infuriating for people who can’t stand being told they made an error, even one of omission.
