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

921–930 of 1001 posts

Re: A Sad Day for Rust

#921

Post by Ygg2 »

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.

He explicitly made the repo private over handing it to someone else.

https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...

Re: A Sad Day for Rust

#922

Post by Ygg2 »

oaiey wrote: post #675
Ygg2 wrote: post #354

Earlier quoted context omitted.

As a maintainer, I treat almost all PR submission with kind words. What actix developer did was, to pardon my French, inexcusable. Deeming security patch boring? Making your own `Cell`, implementing it badly and misusing it, because it's faster on some stupid benchmark site? If we designed cars like that, they would have no breaks, no gears and no cabin. Honestly, I think it's better Rust abandons `actix` asap. Befor…

The same "stupid" benchmark site let to dramatical improved .NET Core performance , re-engineered the .NET Server stack and even changed the C# language on the way. I do not know how the Rust community manages performance comparison, but the .NET bubble was broken by that page and resulted in awesome results for the platform. PS: just pointing out what the page achieved somewhere else. The discussion about the mainta…

That might be true for Dotnet.

But from what I heard, to get where it is, actix developer took some really bizzare shortcuts. E.g. hardcoding parts of response. On top of general unsafe usage.

I think the benchmarks are flawed, since they don't account for such "optimizations".

Re: A Sad Day for Rust

#923

Post by steveklabnik »

travisgriggs wrote: post #920
trunnell wrote: post #668

This seems to be a case of mismatched expectations. Many want Rust to save us from our current nightmare hellscape of vulnerability-ridden foundations. So actix-web comes along-- a Rust web framework that is faster than everything else including the C and C++ frameworks-- and people are filled with hope. It's fast and safe, right? But the actix-web maintainer says he built actix-web just for fun and to see how high h…

I am not a Rust guy (yet?). Are safe and super fast mutually exclusive? As I reas the article I sensed your explanation was probably the case. Did the many safety-making patches cause the performance to go down?

They are not mutually exclusive, though some people will try to suggest it.

Re: A Sad Day for Rust

#924

Post by ssokolow »

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…

However, everything has its downsides. For example:

> 1. YOU are responsible for your dependencies.

This contributes to the prejudice against `unsafe`. If I wanted to be a full-time auditor, I wouldn't be steering clear of C and C++.

Since I'm a responsible coder, I avoid depending on `unsafe` outside of `std` or the simplest of FFI wrappers with extreme prejudice, to the point where I consider NIHing an alternative or just sticking to a managed language with a more mature ecosystem, depending on the project.

Re: A Sad Day for Rust

#925

Post by mwcampbell »

ssokolow wrote: post #916
awb wrote: post #910

Earlier quoted context omitted.

> you either be receptive to security concerns or you clearly label your project as a toy project. Or, assume all OSS projects are toy projects unless stated otherwise. Usually the serious ones offer a support license for a fee, or are supported financially by companies. Otherwise, it's just someone building cool stuff for free. Also, it's probably fair that most OSS maintainers aren't marketing their projects too ag…

I think that https://actix.rs/ counts as an implicit "the author doesn't intend this to be seen as a toy project" in people's eyes.

One thing that nobody here seems to have mentioned is that, as far as I can tell, the actix.rs website was not created by the author of Actix itself. Just compare the writing on the website with the author's own postmortem. I don't know who wrote the website; I can't find an author's name or a Git repo for the site itself. But whoever they were, it seems that they, not the author of Actix itself, did the marketing that gave many of us our primary impression of what kind of project this is. If anyone reading this knows more about the history of the website, I'd appreciate any additional background or pointers to more details.

Edit: After running some git blame commands on the https://github.com/actix/actix-website repository (thanks Nikolay for keeping it there), it seems that the most eloquent marketing for the project was written by Armin Ronacher. I'm sure this was all done with Nikolay's permission, since it's under the actix GitHub organization, but my point is that Nikolay himself didn't say the things that have been quoted from the website, and they didn't necessarily reflect his own attitude about the project. So that might have caused some confusion.

Re: A Sad Day for Rust

#926

Post by hechang1997 »

p1esk wrote: post #805
_-___________-_ 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…

as soon as I saw the large amount of unsafe code, I stopped considering it at all So in that case you wouldn’t use any software written in plain C, right?

It is actually easier to introduce an undefined behavior in unsafe rust than in C, since rust use the guarantee that two mutable references living that the same time cannot aliase to optimize code.

Re: A Sad Day for Rust

#927

Post by kragen »

tzs wrote: post #919
kragen wrote: post #865

Earlier quoted context omitted.

> 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 was the whole reason Tom Lord originally developed the modern DVCS Shouldn't that be Larry McVoy? BitKeeper predated GNU Arch by a couple years.

I never used BitKeeper or TeamWare and consequently don't know how their capabilities were similar to or different from arch's at the time. Did you use them?

Tom had a pretty clear vision for arch which is more or less what Git ended up achieving. Everything he wrote publicly about it derived the feature requirements from his social agenda; he never mentioned BitKeeper, and I don't think he knew about it. He must have known about TeamWare, but I don't know if he had ever used it, and from the little I can glean, TeamWare lacked some very significant things crucial to what we think of as a DVCS today. But maybe I'm wrong about that.

Re: A Sad Day for Rust

#928

Post by kragen »

roca wrote: post #915
kragen wrote: post #869

Earlier quoted context omitted.

rr is only useful to people with a minimal level of knowledge, and in most cases to people who have stood in your shoes. Firefox is useful to any six-year-old with a cellphone. Maybe that explains the difference.

That could explain the difference between rr and Firefox, but it doesn't explain the difference between rr and all the other developer-oriented projects with toxicity issues.

That's true.

Re: A Sad Day for Rust

#929

Post by yawaramin »

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…

> 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 not be called out for it. You're not even entitled to people not trashing your work.

That's fine and all but you are entitled to control your own repo, its issues, pull requests, and related fora. You are entitled to set the acceptable standard of communications and if you don't like the way someone is communicating you are entitled to shutting that off.

See, entitlement works both ways: as a maintainer you're not entitled to a lot of things, but as users others are also not entitled to lots of things.

Re: A Sad Day for Rust

#930

Post by Matthias247 »

jimbokun wrote: post #96
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…

Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients: https://medium.com/@shnatsel/smoke-testing-rust-http-clients... Skimming this, the author doesn't really like any of them. Note, however, the long list of issues reported at the end of the article. Here is the first one I clicked on: https://github.com/algesten/ureq/issues/24 The maintainer is happy to get the report, and has an exchange w…

There is a difference in the bug reports: The ureq one shows a proven error - a crash. That's bad, the author acknowledges it and fixes it.

The actix issue does not show an actual error. It just tells that some internal code does not follow the usual Rust unsafe conventions, and that this might lead to a bug. It takes then some API exploitation by a third person to demonstrate how this could lead to a bug. At that point the author acknowledges the issue, even though any real world implication is still unknown.

Post reply on HN