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

331–340 of 1001 posts

Re: A Sad Day for Rust

#331

Post by zelly »

jswizzy wrote: post #279
zelly wrote: post #252

That's okay, Rust should never be used for web anyway. I don't like the idea of Rust, C, C++, or Assembly for directly web-facing services. Any non-GC language should be a non-starter. There are literally (uncountably?) infinite ways you can have memory errors in a native program. The consequences of any of these can be devastating because absolutely anyone can access your endpoint. Notice the asymmetry: One small, u…

Depends on how you define web. IOT should be done in low level languages. but yeah I agree that a REST server is better of in something like GO, C#, or JAVA.

IOT is generally less of a target. I'm more talking about http endpoints to be consumed by browsers anywhere in the world. That makes the whole world your adversary.

Re: A Sad Day for Rust

#332

Post by GolDDranks »

jimbokun wrote: post #200
steveklabnik wrote: post #128

Earlier quoted context omitted.

You cannot get the full context from a single reddit thread; as I mentioned in the post, this situation is the product of multiple events. You'd at least need the posts from all of them, let alone that this is only one of the posts from this situation on reddit in the last day.

I think that's where some of the confusion comes in. You say: "Some people go far, far, far over the line." So some people are assuming this is just the maintainer responding badly to people pointing out problems with his or her code, but you are saying it went far beyond that into personal attacks?

There were some personal attacks on GitHub.

Re: A Sad Day for Rust

#333

Post by jwlake »

boutad wrote: post #180
jwlake wrote: post #74

Earlier quoted context omitted.

I honestly dont understand people being mad at this. Every dependancy I use I don't like 100% I fork and modify and then upstream changes, and if they never get merged, who cares? If there was a big user community that wanted different things, fork and have a seperate maintainer structure. Why drama?

Then you might end up with a bunch of different forks each with different fixes applied.

A huge number of npm dependancies I use are basically unmaintained, have tons of forks and multiple PRs with the same fixes. I choose the one I like and move on, the magic of github!

Re: A Sad Day for Rust

#334

Post by jimbokun »

steveklabnik wrote: post #219
jimbokun wrote: post #200

Earlier quoted context omitted.

I think that's where some of the confusion comes in. You say: "Some people go far, far, far over the line." So some people are assuming this is just the maintainer responding badly to people pointing out problems with his or her code, but you are saying it went far beyond that into personal attacks?

Yes, they did. I posted an example of a particularly egregious one elsewhere in this thread.

Yeah, saw that. Criticism of code should turning into personal attacks is never justified.

Re: A Sad Day for Rust

#335

Post by _wzsf »

fapjacks wrote: post #214

Man... Wouldn't it be great if this same attitude often seen in users of open source software was had by regular people toward civil liberties? Like where people just pile hate on the codifiers day in and day out, because they are owed their entitlements by birthright.

That's kinda how politics works. Sorry to have to tell you :(

Re: A Sad Day for Rust

#336

Post by lostmyoldone »

dashwav wrote: post #9

I can see where Steve is coming from about the difficulties of maintainer-ship - I only have a few projects that I am actively maintaining and obviously nothing close to the scale of a popular library. But at the same time I really think almost all of the blame in this case rests solely with the reception (or lack thereof entirely) of PRs/issues that are intending to improve the quality of a library that many people…

Publicising a project doesn't imply anything.

If people come to rely on your project, you are not more responsible.

I've been in the business since before open source was much of anything but a dream, and frankly, I wish a lot of more people would shutter their projects when/if they face these kinds of unreasonable expectations.

The vitriol and entitlement towards maintainers is sickening at times, and unless those affected close the doors, I'm afraid it'll continue to be ignored, and maintainers will continue to burn out.

Burn out is a real problem in the industry, and we really shouldn't help burn people out when it comes to work they do for free!

Re: A Sad Day for Rust

#337

Post by aprdm »

dbcfd wrote: post #302
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…

> 1. YOU are responsible for your dependencies. They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back. Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code. Sadly, that led to some…

Where does it say he has to accept patches ? Couldn't they simply fork it instead of acting like entitled kids ?

Re: A Sad Day for Rust

#338

Post by thramp »

zozbot234 wrote: post #230
withoutboats wrote: post #89

This situation is the sad and absurd result of two processes going on in the Rust community. The first is that the Rust community on Reddit is in a feedback loop of groupthink and outrage, making it into a powerful vector for harassment. The maintainer of the actix project had a particularly terrible experience of escalating harassment from the users of this subreddit, and its extremely sad. This has caused a lot of…

Didn't the Rust stdlib just gain a high-performance hash map recently? Is there a real case for using a custom implementation in reqwest? I could see Shnatsel getting a bit frustrated wrt. that choice.

The reason the `http` crate has a "bespoke hashmap implementation" is not because "performance", it's because _HTTP headers call for different behavior than `std::collections::HashMap`_. Some of the differences in behavior include:

- The map needs to be a multimap.

- Insertion order needs to be preserved.

While `std::collections::HashMap` is an excellent HashMap, it is not a good fit for HTTP headers.

Re: A Sad Day for Rust

#339

Post by vvillena »

bpfrh wrote: post #124
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…

The article was not about that, this is not about vetting anything. The problem was that PRs which would have fixed security issues where not accpeted. Do I expected perfect code from maintainers or a answer the next day? No, never Do I think maintainers/creators should merge prs in a timely manner, or ask for help if it get's too much? Yes, otherwise you have multiple forks and the project is not usable anymore.

If this is the issue, one of those forks will become the new mainline repo everyone contributes to. Expecting a maintainer to behave the way the community wants is unreasonable. Maintainers are not public servants.

I mean, anyone can fork it and become a maintainer, and create new guidelines and inclusive rules that ensure the project is steered in the "right" direction. Isn't it the case?

I understand the "we just want a better actix-web", but there are two conflicting concepts, "better", and "actix-web". The way I see it, "better" is whatever the maintainers think it is, and "actix-web" is a project belonging to its maintainers. No community should ever be entitled to try to steal that. They are welcome to build upon it and fork it. This doesn't mean they have to separate ways forever: some forks live happy parallel lives, as so many Linux patchsets have demonstrated over the years. Projects are free to be born, forked, cross-pollinated, merged together, even die, all at the will of their maintainers.

Re: A Sad Day for Rust

#340

Post by henrikeh »

steveklabnik wrote: post #301
cle wrote: post #264

Earlier quoted context omitted.

> And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment. It has connotations of recklessness at least, and explicit threat at worst. Is it really a value judgment? Coming from a formal PL background, I had just assumed that the "unsafe" keyword was referring to the PL concept of "safety", AKA "soundness", which has a specific technical definition, and not that it was necess…

You are correct. That doesn't mean that people will incorrectly interpret it, though.

Ada’s language is probably clearer and less loaded: checked and unchecked.
Post reply on HN