Out of curiosity, isn't a focus on that kind of things precisely the goal of Rust? I understand your point, but this was software built for Rust, which has this kind of thing (safety, the right types, etc) as a primary goal.

From https://www.rust-lang.org/:

> "A language empowering everyone to build reliable and efficient software."

and

> "Why Rust? Reliability: Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — and enable you to eliminate many classes of bugs at compile-time."

So I can understand why someone bypassing this kind of things and then (for whatever, possibly understandable reasons) rejecting PRs to patch them because they are "boring" can be perceived as seriously mismatched with Rust's community. If someone finds this kind of thing "boring", is Rust really for them?

Note: I'm not saying he has any obligation to do anything. I'm just saying his attitude may seem mismatched with the community and goals of his chosen language, which is no small problem.

Are you kidding? Rust is a tool, not an ideology. You don't have to share in the beliefs of the tools designers to use a tool...

You can also write all your Haskell programs with all functions with type IO. You can use a hammer to paint portraits.

Just expect eyebrows to be raised.

Maybe he likes rust because of other things. He had a very successful project with rust, it seems weird to think that rust was not the tool for him.

"Who cares about correctness or safety?" one could ask. Well, Rust's designers for one. It's why they created the language.

Oh my. This was not about code aesthetics or some purely philosophical problem. It was about experimentally found undefined behavior that opened potential security vulnerabilities in the wild. The ”well it works fine so it must be correct” mentality is exactly what led us to this situation where the vast majority of critical net infrastructure code is full of vulnerabilities, the very problem that Rust attempts to alleviate in the first place. The problem with the existence of malevolent actors is that it matters little if your program works correctly in all common cases. Someone out there is going to be actively looking for the uncommon case and their goals may not align with yours.

Why would you possibly not? Increased correctness, no change in runtime behavior, and a resistance to code rot and mistakes on your next concrete change.

Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork.

That's the problem: how does the maintainer guarantee this? And when flooded with multiple such PRs, the task rapidly becomes overwhelming. If you have a robust suite of unit tests and a CI system you have better guarantees but still about as much work to ensure the new functionality is properly tested. That's not to say the maintainer's attitude in this case was excusable, but it's his project and this style of maintenance is definitely not for the feint of heart.

It's a bit disingenuous that you can accuse someone of being absurd for not doing something, and then mentioning in the same breath that you "might not want to" as well.

I'm merely saying that for the sake of pointing out that maintaining a project is a PITA and we should all really accept that.