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

871–880 of 1001 posts

Re: A Sad Day for Rust

#871

Post by AnonymousPlanet »

UncleMeat wrote: post #764
AnonymousPlanet wrote: post #708

Earlier quoted context omitted.

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

Let me help you: > You can resign gracefully and let other people take over. If you put up a tantrum, you probably get your reputation burnt faster than a Google project gets when they suddenly pull the plug.

Where did I say I believe there is an obligation to "resign gracefully"? I said, that you will burn your reputation. Not that I think that is how should be. Just like a politician burns their reputation with something you or I might not find offensive. And that is where shitstorms come from. "I'm just minding my little own business down here" doesn't work once there's a spotlight on you. Do I like it? No. Do I get downvoted on HN for describing the world as something people take offence in? Apparently.

Re: A Sad Day for Rust

#872

Post by zzzeek »

munificent wrote: post #864
zzzeek wrote: post #612

Earlier quoted context omitted.

emotionalism is strongly linked to irrationality. once someone is irrational I'm not following how that can be reduced to a "difference in priorities". I'm an open source maintainer of some very popular projects. more in the early days, I was certainly irrational on a few occasions where someone called out things that I did wrong and I refused to see it. It wasn't like I had de-prioritized "making sure the code is no…

> I was certainly irrational on a few occasions where someone called out things that I did wrong and I refused to see it. I don't think that's a problem with the emotion itself, so much as which specific events trigger that emotion and how you chose to process them and react. Having fear does not make you lash out at users. We all have fear, often about similar things. It's having fear associating with a person calli…

I employ mindfulness on a daily / hourly basis in my own life and especially when dealing with the large number of requests I deal with every day.

In those times that I have not been able to respond politely or rationally, my lack of mindfulness as well as my own emotional reactiveness to certain stimuli (e.g. triggers) was at the core of it.

that is, if a request is not triggering strong emotion in me, I don't need to employ patience and mindfulness in order to have a reasonable and rational response. If a lot of requests are in fact triggering, this is what I would term "emotionalism", and I have to work much harder to have rational responses. Hence emotionalism is linked to irrationality especially for someone with fewer emotional maintenance skills.

emotion is not a "problem" any more than the urge to go to the bathroom is, however, both require proper training to be dealt with.

Re: A Sad Day for Rust

#873

Post by jhasse »

ckdarby wrote: post #441
ddevault wrote: post #38

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

> Open source participants are volunteers and owe you nothing. Equally, someone gets hit by a car while crossing the road. I don't owe them anything to go help them but society, morality and being decent are these unwritten rules that kind of do force you into owing something. Yes, I agree, volunteers don't owe anything but there are some unwritten rules that when broken should be frowned upon and I'd probably go as…

> Equally, someone gets hit by a car while crossing the road. I don't owe them anything to go help them but society, morality and being decent are these unwritten rules that kind of do force you into owing something.

In most countries they actually have written laws which require you to help in such a situation though.

Re: A Sad Day for Rust

#874

Post by wvenable »

mratsim wrote: post #606
oefrha wrote: post #85

Earlier quoted context omitted.

According to https://github.com/actix/actix-web , it appears that the author did accept the security concerns (when an actual use-after-free was found, but maybe not the previous, generic “unsafe oh noz” shitstorms), and wanted to explore some other way to fix the problem instead of accepting the patch as is. Just because there’s a patch that fixes the issue doesn’t mean the maintainer has to merge that patch.

The maintainer still shouldn't dismiss a patch + test case with "it's boring".

Why not? The only reason I work on personal open source projects is because it's interesting to me. Otherwise, why would I bother?

Re: A Sad Day for Rust

#875

Post by Izkata »

mratsim wrote: post #599
pcr910303 wrote: post #391

Earlier quoted context omitted.

Okay, I massaged the GitHub API logs[0] with jq to make a readable version of the issue history[1]. I was firstly (based on the blog post) feeling bad about the maintainer... but after reading the issue report, it turns out multiple people were working on the issue and the author responded... 'this patch is boring'. That's... certainly not good to people who are trying to resolve the issue. He even goes to threatenin…

Thank you very much. Are there some deleted comments that might have been missed? If not the conversation was civil until the maintainer refused a patch for a "boring" reason.

Not quite correct. That patch was never intended to be merged as-is in the first place:

> As a PoC

> Presumably this requires benchmarking/more exhaustive testing which I don't have time to do, but if someone wants to take the patch and get it merged feel free

Keeping that in mind, the "boring" comment comes off differently to me, like they got sidetracked from the original issue and he didn't feel like continuing - which is nearly the confirmation given in the second issue.

Re: A Sad Day for Rust

#876

Post by Gehinnn »

kragen wrote: post #865
cthalupa wrote: post #757

Earlier quoted context omitted.

>People could have forked and worked on the issues themselves, but that's asking too much. Forking projects should be a last resort. This is the "Taking my ball and going home" approach, and now we're splitting development efforts, potentially ending up with very different code paths where improvements can't be merged from one to another, etc. It might be the right thing to do in this situation - but people wanting t…

> Forking projects should be a last resort No. This was kind of true in the days of CVS and SVN. Now with DVCSs like Git, it's easy enough to merge in changes from wherever; this was the whole reason Tom Lord originally developed the modern DVCS. Git workflows commonly make a new fork for every bug fix. If other people don't want to merge in your changes, they probably don't think they're good enough. But that doesn'…

This is true for feature driven projects where features are added on top of exiting code and only some existing code is changed.

But you will have a very hard time merging two refactoring branches that both touch internal data structures.

Re: A Sad Day for Rust

#877

Post by unexaminedlife »

"I assumed that over time, the community would grow, and we’d encounter problems.

Today is the first day where I say to myself, okay, has that happened?"

I think it depends on how you define community. I used to think Rust was going to be able to go mainstream. Now I'm wondering if it isn't niche. In other words, infrastructure needs code too, but all of the code "at the edge" (ie. applications that interact with users) may not be the perfect place for Rust. And I feel like that's where the majority of code will be written. So, maybe to produce metrics on this I would start with "where is the primary activity", and discover within that niche whether or not Rust has positive trajectory in terms of "market share" of that category of applications.

Re: A Sad Day for Rust

#878

Post by dunkelheit »

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

This is the standard voice vs. exit dilemma. Rust community is, for better or worse, very worried about "fracturing the ecosystem" so they generally prefer voice. Well, some of these voices can get ugly.

Re: A Sad Day for Rust

#879

Post by mratsim »

floatboth wrote: post #752
mratsim wrote: post #582

Earlier quoted context omitted.

Probably related to the Reddit job ads when you read /r/rust. That said, blockchain companies using Rust take security very seriously. It also funds cryptographic research which has a huge need of memory safety, performance and the possibility to implement constant-time primitives. I don't see why the community of a language that focuses on safety and speed is not excited by having the language being adopted by commu…

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 there is any distributed consensus algorithms that is not a tremendous energy burn today be it physical voting (transports, broadcasts, special machines, security, ...) or CEOs and diplomats flying around the world.

- The energy burn is still concerning but Proof-of-Work is not the only way to solve the Byzantine General problem via economic incentives. You only need a "rare resource" that cannot be easily replicated to avoid sybil attacks (i.e. not an email address). That can be cryptocurrency (Proof-of-stake) or storage (Proof-of-spacetime)

- I don't think you realize the scale of drug trafficking and other unsavory endeavors that use cash.

- Mostly agreed on private blockchain but there are some industry-wide private blockchains that are starting to emerge (including UNICEF and FAO) with very interesting applications (identity of children refugees and managing food).

Re: A Sad Day for Rust

#880

Post by mratsim »

compiler-guy wrote: post #596
mratsim wrote: post #563

Earlier quoted context omitted.

They owe people who write PR basic courtesy, not refusing patches on ground that it is "boring".

"Basic courtesy" is one thing. Accepting patches because they don't find them interesting is another thing, is different, and not required. Giving someone the mere ability to make a PR is already a gift far beyond what the original author owes.

I'm not advocating for or against accepting the patch. I'm saying that the tone of the refusal is inappropriate.
Post reply on HN