3 ms·
This smells a lot of the classic "Worse is Better" discussion [0]. Back then, it was Scheme people insisting on correctness and C people insisting on pragmatism
by skrebbel 5y ago
This smells a lot of the classic "Worse is Better" discussion [0]. Back then, it was Scheme people insisting on correctness and C people insisting on pragmatism. It's no surprise to me that Rust, a language with a heavy focus on correctness, attracts the correctness-over-pragmatism crowd.
The author is a "worse is better" programmer who finds themselves surrounded by "the right thing" people. I think the addendum the author adds a year later in the top comment is the right insight: fork away. This keeps the "the right thing" people happily obsessed with getting everything right, without the author being blocked on moving faster.
[0] https://dreamsongs.com/RiseOfWorseIsBetter.html https://dreamsongs.com/RiseOfWorseIsBetter.html (1991)
- couchand 5y agoI've found Rust programmers to be eminently pragmatic. The economics of bugs have been clear for decades: it is orders of magnitude more expensive to find and fix bugs after they've been shipped.
- purple_turtle 5y agoAnd, additionally, if someone is unwilling to fix known issues in PR - then they will definitely not fix bugs in it after it become merged. So for maintainers merging PRs with known issue is basically promising to fix everything not finished.
- DarylZero 5y agoTo the contrary, a developer is MUCH MORE likely to fix bugs in merged code that has users, than in an unmerged PR. It's the users that give motivation to work on the project. Working on a PR is like working on spec. Working on the development branch gives you direct access to the "payment" of users using your code.
- purple_turtle 5y agook, there are two different effects in action: - creators are more likely to abandon or ignore projects that have low popularity or are completely unused - creators are more likely to be burned out when there are piles of demands, requests, complaints etc