Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

761–770 of 1001 posts

Re: A Sad Day for Rust

#761

Earlier quoted context omitted.

This is a bit Pollyanna. People aren't logic robots that start from first principles and then derive all knowledge from logical reasoning. People are emotional, irrational beings. Those of us who fancy ourselves rational are constantly involved in irrational motivated reasoning helping us maintain that desired worldview. Not to say we shouldn't try to live up to the ideal you set forth. We should do our best. But the…

People are not robots, but in terms of reaching agreement between humans, "emotion" is more or less just a difference in priorities, which is one of the ways reasonable people can disagree. If we agree on the facts and we agree on their implications, but we still disagree, it's likely because we weight things differently. Emotions are simply a large component for how we weight things.

Life might be easier if emotions were that simple. :-) I've worked with several people to help them overcome emotional baggage. It is quite challenging. It's true that many emotional differences can be eventually distilled down to a difference in priorities, but helping someone discover the essence of an emotional issue can take years.

Even mature people often can't reason their way out of a conflict on their own. When people feel personally threatened, sometimes no amount of simple reasoning will bring them back to rational thinking. Most of the time, the solution is to be a genuine friend--for the long haul.

Re: A Sad Day for Rust

#762

I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all. I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what…

> There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code.

It works both ways. You put something out there, you need to be ready for the response. I'm not a Rust user, but presumably there was a reason other than charity that he put it out there (show off his brilliance, use it to get jobs, I don't know - but it was something he did for his own benefit). If you don't like that, don't make your code available to others, and don't complain if others act in a way you don't like. There's so much posted on HN about "open source entitlement". Well, the entitlement seems to run in both directions. That's the simple the reality of the situation.

Re: A Sad Day for Rust

#763

Earlier quoted context omitted.

> If someone asks for feedback, sure, your points are not wrong. If they're actively asking me to use their software, isn't that soliciting feedback? If I say 'no, it won't work for me', I've apparently committed some egregious microaggression right? If I just say 'no thanks', what do expect the very next thing they say is going to be?

Who said they're actively asking you? I'd say most smaller open source (e.g., single dev) projects are "here's what I built, maybe it's useful for you too."

> Who said they're actively asking you?

>> Just because you made a software doesn't mean I have to use it or like it, and if you are actively trying to recruit me to use it then I am indeed entitled to complain about it.

That is what I wrote. That is entirely the context of what I said.

Re: A Sad Day for Rust

#764

Earlier quoted context omitted.

Some floss developers choose to work for free. That’s fine or even admirable. That doesn’t mean that everybody needs to. If a dev isn’t being paid then they should have the absolute right to refuse all maintenance or even just destroy the project. I’d keep my code closed source if there was a risk that it would start getting used and suddenly I’ve got an extra job for zero pay.

> Some floss developers choose to work for free. That’s fine or even admirable. Uh, yes. I agree. > If a dev isn’t being paid then they should have the absolute right to refuse all maintenance or even just destroy the project. Where in my post did I say they cannot quit? > I’d keep my code closed source if there was a risk that it would start getting used and suddenly I’ve got an extra job for zero pay. I'm with you.…

I absolutely read your post fully.

I disagree that there is an obligation to "resign gracefully". If people choose to depend on your code without some sort of contract then that is on then and you absolutely can continue to play the "I don't get paid" card if you so choose. The fact that the Debian maintainers don't play this card does not mean that everybody should behave the same as they do.

Re: A Sad Day for Rust

#765

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.

Why is it a problem for you if someone is willing to give their work to the world in a way that allows others to benefit from it? Why is that not enough? Why do they also have to keep doing more after that?

If you disagree with the notion of someone publishing their work under a free software or open source license being useful for the world, then please post an AskHN about it and you will have _plenty_ of material to convince you of this perspective. However, I think most reasonably clever people can already come to the conclusion themselves.

Re: A Sad Day for Rust

#766
post #105

Earlier quoted context omitted.

Forking is extremely aggressive, and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.

> Forking is extremely aggressive Shouldn't we disabuse ourselves of that notion? Forking a project to solve an issue is just that. We shouldn't attach any sort of emotional connotation to it.

Ah, emotion. Both the greatest strength and the downfall of humanity;

Re: A Sad Day for Rust

#767

Earlier quoted context omitted.

> Open source participants are volunteers and owe you nothing. Of course they do. It’s not legal for you to distribute software that puts others in harm’s way. You’re not allowed to give poisoned food to homeless people as long as it’s free.

Of course they don't. It is Free OSS. And you implying that the maintainer put someone's life in harms way is simply not true. And the LICENSE says - no warranty or guarantee whatsoever... Use at your one risk. And the homeless people analogy makes very little sense, excuse me for being blunt. You are comparing software developers who use FOSS to homeless people??? You are comparing someone's FOSS project on github t…

> And the LICENSE says - no warranty or guarantee whatsoever

Lol. That’s about as legal as saying you can’t be arrested because you’re a sovereign citizen.

Re: A Sad Day for Rust

#768

Earlier quoted context omitted.

All of this is second hand, where are the mean comments "making" this person quit their own project? Were they actual personal attacks, or just criticism of the code? If you can't accept legitimate criticism of your work, that shows a real lack of maturity. (The article didn't give concrete examples, so I don't know which is the case here.)

Here is an example of an actual comment. I believe the thread is deleted now: > "seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?" This is what I was thinking of when I wrote "far, far over the line."

The request is unreasonable, but is the second question not valid?

Re: A Sad Day for Rust

#769
post #57

This is a sad day for Rust. Situations can spiral out of control. Who started it? Who escalated it? You can't really define these because communication is sloppy and difficult, especially when there are cultural and language barriers involved. The only way to not get these situations to spiral out of control are a thick skin, forgiveness, and assuming noble intent. There have been times on here where I see discussion…

> I also wonder if expectations were unclear. It now sounds like the focus of Actix was on performance and creativity / cleverness and not on being a mature product. I never heard that before. Maybe even the author didn't even originally articulate it so clearly but discovered it through these discussions.

That's actually my main sticking point on this being mostly on the maintainer. From the actix documentation, releases, and promotion, I never got the feeling that it was _not_ meant for production. Even to the point of the comment "Microsoft uses this in production".

And suddenly, "It's creative/fast/research/whatever"? That really feels like trying to sidestep findings because you don't want to lose your spot in the techempower benchmarks. Even more so, when the documentation, etc. is not updated to reflect this new focus, and there's no announcements about it.

Re: A Sad Day for Rust

#770
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…

If you make your project public, does it by definition mean you are open to other people using your release? I think there's a difference between "Hey, use this project of mine," and "If you use this project, you're on your own..." I think a lot of these debates come down to this confusion. Some people assume the former (and expect some level of response), some the latter (and say it's as simple as forking if you have a problem). Therefore I think anyone who releases should - morally/ethically, not legally/license - state what which philosophy they are following.

It'd be interesting if people could release their projects "abstract" fork-only. So they could publish releases that would be vetted and merged into the downstream forks, but would never be released as a deployable itself.

Post reply on HN