Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

Post reply on HN
Print view View original

571–580 of 1001 posts

Re: A Sad Day for Rust

#571

Post by eropple »

flatline wrote: post #412
eropple wrote: post #380

Earlier quoted context omitted.

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

> 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 hi…

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.

Re: A Sad Day for Rust

#572

Post by steveklabnik »

cle wrote: post #435
steveklabnik wrote: post #350

Earlier quoted context omitted.

Yeah, and interestingly, a lot of unsafe functions use "unchecked" in their names. The issue was that by the time this was recognized, there was too much Rust code, and there was no clear alternative that people universally liked. This kind of conversation is the definition of bikeshedding. I submitted an RFC and it... didn't go well. (I think I picked "trustme" though.)

I don't think it's bikeshedding. It does seem to be contributing to the dogmatism I'm seeing from the Rust community here, and this community reaction is a huge problem for Rust. So it matters.

Bike shedding is a structural description, not a value judgement. It’s about technical complexity, and changing a keyword is one of the most minimally complex bits of language design.

Re: A Sad Day for Rust

#573

Post by jhall1468 »

virtue3 wrote: post #450
NewsAware wrote: post #361

Earlier quoted context omitted.

Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep. Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Read…

It takes time to validate a PR, to test it, to verify it. He is not being paid for his time, he does not owe -anyone- his time. If you don't like the way a project is being run, fork it and own it yourself. I know that's harsh, and not idealistic, but it's the way people should really think about this. People take FOSS for granted, CONSTANTLY. And maintainers even more so.

And when maintainers respond to a significant amount of work involved in a PR for a bug with a note that they aren't interested because it's "boring" then they can be critiqued for being a jerk, because they decided to be a jerk.

If the maintainer had said, "Hey, I don't have the time to review/test/verify this PR so I'm closing it for now," the backlash probably wouldn't have been quite so severe.

Re: A Sad Day for Rust

#574

Post by joeblau »

I want to give a heads up to everyone who runs, or is thinking about running an open source project. If your project sees ANY notoriety and you are the maintainer, you will quickly find yourself in this situation. In 2013, I started a little side open source project and put it on GitHub which now has 5.2k stars. I've seen tons of arguments in my PR's over the previous 7 years. My project isn't even that large and I've seen lots of in fighting to the point where I've had to lock threads. The skills required for you to run a successful open spruce project are the same skills required for you to run a business. You're going to need people skills and understand how to de-escalate situations because once the community is large enough, there will be a lot of culture conflicts. The main challenge with open source is that if you're not getting actively incentivized (Paid for me) to maintain something that's super popular, it's easy to abandon it when things get hard.

Re: A Sad Day for Rust

#575

Post by CydeWeys »

manish_gill wrote: post #26
vunie wrote: post #6

I don't know how to word this so I'll say it bluntly (and probably bear the blunt of this community as a consequence): If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project. No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. Of course, you could…

> No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. It's not like he was getting paid to work on this, was it? And people do have a life beyond open source. People could have forked and worked on the issues themselves, but that's asking too much. Why do the hard work when you can just write a comment/tweet blaming someone else, right? Your comment is precisely what…

From a pragmatic point of view, it's very bad to have widely used libraries that are poorly maintained and that have unaddressed security issues. It's not entitled to not want that situation to exist.

If you create a project that ends up becoming such a security risk, you really should be doing something to address it, for the good of everyone. This could be as simple as adding more maintainers with commit access who will address the issues.

Re: A Sad Day for Rust

#576

Post by tadfisher »

kllrnohj wrote: post #503
BowBun wrote: post #343

Earlier quoted context omitted.

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs w…

> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. It is when they setup an open source project that has that appearance and is framed as being such a project. It is entirely the maintainer's responsibility to establish the type of open source project it is. If it was just a toy hobby project and that's all it was meant…

Open-source means freedom to fork, nothing more. But that's ancillary to the rest of your comment.

Re: A Sad Day for Rust

#577

Post by jimmydorry »

vunie wrote: post #6

I don't know how to word this so I'll say it bluntly (and probably bear the blunt of this community as a consequence): If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project. No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. Of course, you could…

Why should a project author dictate in what contexts their project can be used? It's on the coder to manage their dependencies and ensure they are a good fit for their needs... not the project author.

And what exactly are you contributing to this project author to match your demands of them immediately fixing flaws that are found?

Re: A Sad Day for Rust

#578

Post by stjohnswarts »

rckoepke wrote: post #392
BowBun wrote: post #343

Earlier quoted context omitted.

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs w…

> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. I mean, I'd say that it is a maintainer's responsibility to do some of these things. If they can't, they should allow another interested&qualified person to be the maintainer instead. I understand that it's their right to abdicate these responsibilities. It's not illega…

It's not their responsibility. If you want to use the software then use it, if you don't want to use their software then walk away. They don't owe you anything outside of what they are willing to pay with their personal time. No one forces you to use the software. It's open source and YOU are free to take the code and run with it if you don't like it.

Re: A Sad Day for Rust

#579

Post by School-Cotton »

zpallin wrote: post #386
School-Cotton wrote: post #299

Earlier quoted context omitted.

> it's definitely a maintainer's responsibility to make their code serve the interest of its users to the best of their ability No it isn't, unless those users are paying.

If that's the case, then why open source it at all? Just make people pay.

There are many possible reasons, and yes, one is because they might hope it's useful to other people. That's not the same as being "responsible" for such usefulness.

Re: A Sad Day for Rust

#580

Post by jhall1468 »

enumjorge wrote: post #505
Ygg2 wrote: post #342

Earlier quoted context omitted.

> They were hateful and virtrolous Who's they? Most of PR commenters were courteous. The last few were rude, but so was the fafhrd91. https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...

The parent comment still stands. Whether the maintainer was in the right or in the wrong, whether they were being a jerk or not, if he wasn’t listening to the community why not just fork the code? GitHub’s UI makes that super easy.

Just because it's easy to fork in the UI, doesn't mean it's easy to get people to switch. Some people are actually concerned about the community as a whole, rather than their own projects.
Post reply on HN