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

951–960 of 1001 posts

Re: A Sad Day for Rust

#951

Post by tus88 »

kragen wrote: post #950
tus88 wrote: post #948

Earlier quoted context omitted.

Actually I agree, I wasn't trying to emphasize their feelings as much as question if there is really such a thing as a friendly fork. In reality it shouldn't matter and the concept be void, if someone forks your project and it is successful you should be glad you don't have to anymore and can do something else, as well as benefit from the improved software.

If you like what they added, you can merge it into your version unless they chose an incompatible license for their work. (That's one reason the GPL is so important: it prevents such incompatible licensing.) So if the forks continue unmerged, it likely signals some kind of difference of opinion: perhaps over technical quality, perhaps over tradeoffs, perhaps over licensing. The humans frequently turn such differences…

Fighting over "who gets to donate their time for free" is absurd. Unless you are one of those pretend open source companies that sell commercial versions and prevents certain cloud based usage.

Re: A Sad Day for Rust

#952

Post by floatboth »

mratsim wrote: post #879
floatboth wrote: post #752

Earlier quoted context omitted.

Oh, everyone likes cryptography and is reluctantly thankful that "blockchain" companies fund FOSS projects. But most people don't like "blockchain" because there's a lot of good reasons to dislike it. My reasons can be summed up as: "public blockchain" aka cryptocurrency is toxic — it's horrendously inefficient in the name of achieving censorship resistance, so people are literally burning fucktons of energy to make…

- I wouldn't conflate blockchain and cryptocurrency. Cryptocurrencies are one (infamous) use-case of blockchain technology. - I agree that cryptocurrency turf fights are toxic - censorship resistance does not equate privacy. The main blockchains today are actually fully transparent. The perfect crim currency is cash which is almost untraceable. - The energy burn is to achieve distributed consensus. I don't think ther…

> Cryptocurrencies are one (infamous) use-case of blockchain technology

None of the "other use cases" have been interesting in any way.

> The main blockchains today are actually fully transparent

So what? If the exchange between the cryptocurrency and real cash is not compromised, the only traceable thing is that some address which you don't know anything about got paid from another address which you don't know anything about.

Again, real world ransomware mostly uses Bitcoin.

> I don't think there is any distributed consensus algorithms that is not a tremendous energy burn today

Anything that is not trustless, even physical voting, should be vastly more efficient.

> Proof-of-stake […] Proof-of-spacetime

Yeah, when did Ethereum promise a switch to proof-of-steak? Where is that again? Has anyone actually proven the security of any of these alternatives?

Re: A Sad Day for Rust

#953

Post by kragen »

tus88 wrote: post #951
kragen wrote: post #950

Earlier quoted context omitted.

If you like what they added, you can merge it into your version unless they chose an incompatible license for their work. (That's one reason the GPL is so important: it prevents such incompatible licensing.) So if the forks continue unmerged, it likely signals some kind of difference of opinion: perhaps over technical quality, perhaps over tradeoffs, perhaps over licensing. The humans frequently turn such differences…

Fighting over "who gets to donate their time for free" is absurd. Unless you are one of those pretend open source companies that sell commercial versions and prevents certain cloud based usage.

Yes, but most things the humans do are absurd.

Re: A Sad Day for Rust

#954

Post by atoav »

bachmeier wrote: post #896
kelnos wrote: post #822

Earlier quoted context omitted.

I don't think "entitlement" means what you think it means. Unless you're arguing that people shouldn't feel entitled to be free of harassment, in which case I don't agree with you. Yes, if you put something out there, you should expect feedback, and assume that some of that feedback is not going to be very nice. But that doesn't excuse the people giving that feedback for being rude. It doesn't excuse the fact that th…

Well, I'm using the dictionary definition: entitled: to furnish with proper grounds for seeking or claiming something example: this ticket entitles the bearer to free admission Being an open source maintainer doesn't mean you're entitled to recognition or praise or deference. You're not entitled to put out low-quality software and have others pretend it's awesome. You're not entitled to make claims that are false and…

We all have to ask ourself which shape we want to give our feedback. You can factually say the same as the other guy, but send a very different message.

When you critizise someone for using unsafe blocks, there are many ways how you could go about this. This argument here is not about whether we are allowed to point out unsafe code blocks, it is about how we do it.

It is a tangible difference if your message is: "You are using unsafe there and it is not really needed, let me help" or rather: "You are using unsafe there without any reason, you idiot. Go away and never come back!"

And the thing is: only one of these messages will get you closer to safe code.

Re: A Sad Day for Rust

#955

Post by atoav »

vfclists wrote: post #886
manish_gill wrote: post #26

Earlier quoted context omitted.

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

Reasonable expectation does not equate to entitlement. So what is the person who finds the flaw supposed to do: 1. announce to all the other users of the library to download his branch with just the single fix 2. report it to the maintainer with a suitable patch, discuss it, and hope the maintainer applies it sooner rather than later. TBH the maintainer sounds like the boy with the soccer ball who ends the match and…

To me the maintainer sounds more like the boy who brought everybody cake and then left the party when the other boys started nagging about how their mothers would make much better cake and how his cake is all wrong.

Re: A Sad Day for Rust

#956

Post by slavik81 »

sigstoat wrote: post #655
PhaseLockk wrote: post #569

Earlier quoted context omitted.

> You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything. I was taught that part of being an engineer taking a moral responsibility for the safety of your creations. I know that the field has changed quite a bit, and that people in open source come from many different ba…

> I was taught that part of being an engineer taking a moral responsibility for the safety of your creations. almost certainly in the framework of being employed or contracted to do engineering work. go back and ask your teachers what they felt they owe people asking them to design things unpaid, in their free time.

> go back and ask your teachers what they felt they owe people asking them to design things unpaid, in their free time

As an engineer, your first duty is to protect the public, then your client, then your employer. You have that duty to the public regardless of whether you're being paid by a client or not, because it comes from practicing engineering, not from remuneration.

Re: A Sad Day for Rust

#957

Post by atoav »

jdbernard wrote: post #758
zozbot234 wrote: post #672

Earlier quoted context omitted.

Expecting a reasonably-quick response to security concerns is certainly appropriate.

In a free project where the author isn't paid? What if he's on vacation? What's the SLA there? Is it reasonable to expect him to cut short the vacation? If you want to be able to place expectations on the author, pay them and get a contract.

Then it is about communicating exactly this. Security and trust hinge on properly communicating what is going on.

Re: A Sad Day for Rust

#958

Post by atoav »

TrueDuality wrote: post #533
velcrovan wrote: post #211

Earlier quoted context omitted.

Backing up another level...it’s concerning to me when a language relies heavily on single-maintainer libraries for commonly needed functionality. If actix-web was this important, it should have been adopted by the community before now. Maybe languages need a way of setting the expectation to that if your library becomes essential to the community (and if licensing allows) the core developers are going to fork it and…

The developer actively fought against this for a very long time, even before the reddit shit storms. Yes the community could have forked the project and started independent development. I'd argue that forking and developing independently of the developer is as big of a middle finger as a developer taking their ball and going home. It just depends on who is on the receiving end. I don't think either side is right here…

Forking can be a middle finger — a schism, dividing the church to do it your way. Or it can be the most normal thing ever where no one would even bat an eye.

The distinction is if there is tribalism entering the discourse. If the reddit-community-tribe argues gathered around their digital fireplace how bad that one maintainer is, it will naturally become a tribe vs. maintainer conflict (a good way for tribesfolk to proof they are part of the tribe).

This is exactly what saddens Steve: it shouldn't be the "we know real Rust"-tribe against the heretic maintainer. If anything the "heretic maintainer" should be seen as part of the tribe: it is not in our interest to "win" but rather to convince and to take him with us.

I find it shocking at times how low people go just to defend their newfound beliefs within their newfound tribal community.

Re: A Sad Day for Rust

#959

Post by im3w1l »

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…

Let's say some charitable person hands out food to the poor. Only it's cooked with bad hygiene and people who eat it fall ill. People can and should warn tell each other to stay away. Even if his feelings get hurt. Even if he was only trying to do good.

I think this is a good metaphor because how bad the food is is key. If it's just a little bad he is doing a good thing. If it's a little bit more bad it's neutral and people can take it or leave it. And if the quality is really bad that's when people need to protect themselves and each other by dragging his name through the mud.

I'm not familiar with actix so I wont presume to say which category it falls into.

Re: A Sad Day for Rust

#960

Post by Traster »

infinity0 wrote: post #894
_-___________-_ wrote: post #352

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…

I don't like contempt culture either but there's a balance to be made here - if you let everyone do everything and encourage them all as special snowflakes that can't create anything crappy, a community will also go to shit. In this case it does sound like people initially were very nice and tried to give the author very polite suggestions on improvement, and it was only after the author being extremely dismissive[1]…

> initially were very nice and tried to give the author very polite suggestions on improvement, and it was only after the author being extremely dismissive[1], not admitting to his own flaws, not wanting to learn from others, and abusing his own power in shutting down valid discussion, that things turned nasty.

Yes, nice comments such as

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

and

> Never write rust code again

Post reply on HN