[jakear]

Did the patches obviously maintain the exact same behavior? If so, why should the author care about them? If not, it’s not the author’s responsibility to ensure they’re correct patches, but it is the author’s responsibility to ensure their package is correct. If it was correct already (not sure about this, but it seems it was very popular and used in production, so I imagine it worked well), they have no responsibility to vet incoming patches that do nothing besides change internal workings for the sake of changing internal workings.

I don’t write Rust, I write TS. If I produced a package that was had a clean and correct TS interface, but internally was filled with dirty dirty `any`s, I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s.

[the_af]

> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s.

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.

[solidasparagus]

> If someone finds this kind of thing "boring", is Rust really for them?

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...

[the_af]

Agreed on all counts: Rust is a tool and you don't have to agree with the tool designers. It's just bizarre to ignore precisely the aspect of the tool that singles it out, the reason it was created to begin with, the one thing this tool is very opinionated about.

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.

[cosarara]

> is Rust really for them?

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.

[the_af]

I don't disagree. But a tool can be successful in adoption and still not be correct from a technical point of view.

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

[Sharlin]

> If it was correct already (not sure about this, but it seems it was very popular and used in production, so I imagine it worked well)

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.

[eropple]

> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s.

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.

[flatline]

> no change in runtime behavior

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.

[eropple]

In many cases, you're right. But here, specifically? If somebody goes through your code and annotates it with types, TypeScript is gonna scream if it doesn't build clean and is going to emit the same code it did in the first place. This is literally complaining that somebody might write helpful documentation for your system and that you'd refuse to merge it. It's a pathologically bad statement.

[virtue3]

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

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.

[eropple]

It's not disingenuous; I have a number of open source projects on my plate already. I probably can't take on more. But if somebody hands me, for one of my projects, a set of typings that compiles clean in TypeScript (and, seeing as how it's a compiler, that's a really trivial thing)? I'd be literally-not-figuratively out of my mind to not say "thank you" and take them. Failure for another maintainer to do so means that they are a business risk for me that I should not entertain.