Many things in Rust are stuck in a “perfect is the enemy of good” state. There’s often consensus that some parts of Rust are lacking, but proposed solutions are not ideal, so there’s hope that a better idea will come later. But somehow better solution doesn’t come, and unresolved issues sit stuck years. In the meantime, Rust lives with whatever quick’n’dirty MVP it had at 1.0, or permanently nightly/unstable features.
The very high bar for landing new features in Rust is generally good, as the decisions that Rust has made are overwhelmingly very good. But OTOH I wish that Rust leadership could sometimes make a decision that an issue has been sitting stuck for 5 or 7 years, it’s not going to be perfect, and just go with some pragmatic approach.
Tony Hoare learned the lesson we all need to learn here while contributing to Algol 68, and described it well in his Turing Award lecture in 1980. Unfortunately, everyone only remembers the first part of what he said:
I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
But the next paragraph is just as important:
The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature. It also requires a willingness to accept objectives which are limited by physical, logical, and technological constraints, and to accept a compromise when conflicting objectives cannot be met. No committee will ever do this until it is too late.
Ahh yeah, maybe I should have mentioned in notes about that. I still find their attempts to correct organizational problems in a large open source setting interesting, found it worth sharing!
Many things in Rust are stuck in a “perfect is the enemy of good” state. There’s often consensus that some parts of Rust are lacking, but proposed solutions are not ideal, so there’s hope that a better idea will come later. But somehow better solution doesn’t come, and unresolved issues sit stuck years. In the meantime, Rust lives with whatever quick’n’dirty MVP it had at 1.0, or permanently nightly/unstable features.
The very high bar for landing new features in Rust is generally good, as the decisions that Rust has made are overwhelmingly very good. But OTOH I wish that Rust leadership could sometimes make a decision that an issue has been sitting stuck for 5 or 7 years, it’s not going to be perfect, and just go with some pragmatic approach.
Tony Hoare learned the lesson we all need to learn here while contributing to Algol 68, and described it well in his Turing Award lecture in 1980. Unfortunately, everyone only remembers the first part of what he said:
But the next paragraph is just as important:
https://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf
Clever title, but it means people aren’t going to read it because they think it’s an intro tutorial.
Whenever smallcultfollowing writes a tutorial, I read it :)
Yeah, I was going to skip it but I happened to look at the domain. I thought it was just a tutorial to basic move semantic stuff.
Ahh yeah, maybe I should have mentioned in notes about that. I still find their attempts to correct organizational problems in a large open source setting interesting, found it worth sharing!
That means you are not Niko Matsakis and didn’t author it ?
[Comment removed by author]