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

971–980 of 1001 posts

Re: A Sad Day for Rust

#971

Post by rowanG077 »

fluffything wrote: post #949
rowanG077 wrote: post #736

Earlier quoted context omitted.

That's an interesting way too look at it. But that's not how it works in practice. Almost no one in industry is going to write proofs for their unsafe code. It didn't happen for C or C++ and it won't happen for Rust.

This is how it works in practice for the Rust compiler for the Rust standard library, and for a lot of foundational crates in crates.io. (Pretty much every well reviewed crate in cargo crate review either does this, or does not contain any unsafe code at all). We also have tools that change for this for very large projects (e.g. cargo-geiger), and tools that help you test your proofs (e.g. cargo-miri). For some unsaf…

I didn't say it no one will do it. I said almost no one. The Rust compiler is about as far from a normal project as can be. I would like to see this changed but really I have never even seen a proof requirement when looking at Rust jobs. Not even once.

Re: A Sad Day for Rust

#972

Post by jsjohnst »

zelly wrote: post #389
jsjohnst wrote: post #55

Earlier quoted context omitted.

I don’t have the full picture here, but the source article implies that folks weren’t just complaining, but also offering PRs to fix the issues, which were rejected. That feels less like entitlement to me and more like bad stewardship of the project, but again, most of my info is biased by source article.

I don't get it, why didn't anyone just fork it and outcompete the original one?

Had I known in time, I might’ve personally.

Re: A Sad Day for Rust

#973

Post by zelphirkalt »

I liked actix and did a little free time unfinished project in it, when it was updated frequently. Ultimately I lacked the energy to read anew the tutorial and update my code. Still, I liked to use it and think it probably became better over the time I did not use it.

I don't know what kind of licence actix-web had. Seems to have been some open source license and not a free software license, according to the "postmortem" readme file, where the author says: "I am done with open source."

What stops anyone from using a fork to develop further? Did the license not permit that?

If somehow that was not permitted or not possible, because no one created the fork before it was moved to "private repos", then I think the author did something quite childish , taking away the possibility for others to continue developing the software, just because he is fed up with enduring the criticism. "You don't like how I run the project? Meh, I'm going to take it all away from you!" (That's how it sounds, when you move a repo to private after and because of criticism.) Ideally any author, who works on an open source project, knows, that they give up some control over the code and would not act this way.

I do not say, that the shit storms were justified or good in terms of their social aspect. However, if all of this managed to make actix-web safer, then at least that aspect was a good result.

Re: A Sad Day for Rust

#974

Post by twic »

jeltz wrote: post #171
steveklabnik wrote: post #139

Earlier quoted context omitted.

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

Yes, that comment was not ok but as far as I have seen that is the only comment which keeps getting quoted. All but a handful of people seem to have been civil.

This! It is utterly disingenous - in fact, it is simply lying - to characterise users' interactions with the maintainer here as harrassment, or abusive, or entitled.

Re: A Sad Day for Rust

#975

Post by ckdarby »

jhasse wrote: post #873
ckdarby wrote: post #441

Earlier quoted context omitted.

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

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

"I wasn't aware someone got hit. I thought it was an animal."

What the law says & what people do :P

Re: A Sad Day for Rust

#976

Post by twic »

atoav wrote: post #955
vfclists wrote: post #886

Earlier quoted context omitted.

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.

It's more that he bought a cake, but it wasn't cooked in the middle, so there was a chance people could get food poisoning, and the other people at the party pointed that out and suggested ways to cook cakes more consistently, but the author really likes cooking soggy cakes, and he's never got sick from it so it must be fine, so he left the party and told everyone the others were mean to him.

Re: A Sad Day for Rust

#977

Post by twic »

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?

Not so much mutually exclusive as "safe, fast, easy, pick two", at least sometimes. It can take a lot of design effort to come up with a safe and efficient way to do some things, so it's often tempting to do something unsafe and efficient and hope it works out.

Re: A Sad Day for Rust

#978

Post by Cladode »

Animats wrote: post #518

I have been complaining about Rust's "unsafe" for years. There's too much "unsafe" code because there are things that you either can't express, or are very hard to express, in safe Rust. I've pointed out partially initialized arrays and backlinks as key trouble spots. Both are potentially fixable. I've gotten back complicated excuses for not dealing with these design problems. There was a serious denial problem in th…

    there are things that you either 
    can't express, or are very hard
    to express, in safe Rust.
This is true (and in some sense inevitable by Rice's theorem) but it is unclear what can be done about this. Bear in mind that Rust's design constraints are

- decidable (indeed fast) type-inference/type-checking

- simple typing system

- you don't pay for features you don't use

It is easy to get rid of unsafe blocks if you throw complexity at Rust, e.g. use dependent types and / or theorem provers, but all the obvious ways of doing this immediately violate the constraints above. Doing it within Rust's constraints is an open research problem.

   potentially fixable.
What would you use as an objective, measurable criterion that we can use to decided whether a purposed fix is in fact a fix? If you have a concrete design proposal that works (in particular w/o destroying Rust's fast (bidirectional) type-inference/type-checking and the simplicity of Rust's types), and evidence that it's widely applicable (i.e. doesn't just allow to type some trivial edge cases of back-links and partially initialised arrays) that would easily publishable in top PL conferences (e.g. POPL) and a working prototype would help towards getting this into Rust.

I would be happy to help with implementing & writing up such work. I have quite a bit of experience with sub-structural types a la Rust. I have spend some time thinking about this problem space, but didn't manage to crack it. I have an incoming PhD student whom I could ask to help with this.

Re: A Sad Day for Rust

#979

Post by iforgotpassword »

nindalf wrote: post #826
iforgotpassword wrote: post #799

Earlier quoted context omitted.

Well they didn't find any specific issues. Just the overall code looked not up to their standards as well as how the maintainer dealt with feedback. What do you suggest one does in such a case? Every time I stumble upon shitty open source code, am I supposed to fix it and if the maintainer refuses the patches, patrol the internet and try to prevent anyone from using it?

> they didn't find any specific issues The linked article specifically mentions that a specific soundness issue had been found and a fix had been submitted as well. If they had done nothing, it would have attracted no comment. If they had allowed another maintainer to review and merge, it would have attracted no comment. But they went out of their way to denigrate the people who called attention to this issue, called…

> The linked article specifically mentions that a specific soundness issue had been found and a fix had been submitted as well.

True, but I (and I think the other comments) referred to the top level comment here, which is a guy who just felt the code was smelly and avoided it, without having discovered anything specific.

> Your tone suggests that you don't want any part of this, so you continue along that path.

Been there, done that. The amount of excuses and other bullshit is not worth my time and effort. If the project is on github I still do open issues providing repro or at least a stack trace if possible. But if you have your own bug tracker where I'd need to sign up first (most likely going through email verification) you've lost me. Same for when you start requesting I do a git bisect even though I provided steps to reproduce or start giving excuses for why this isn't an actual bug and I'm holding it wrong. I'll just stop replying immediately.

Re: A Sad Day for Rust

#980

Post by Funnnny »

p1esk wrote: post #824
mumblemumble wrote: post #816

Earlier quoted context omitted.

At the risk of projection, that comment reads to me as an attempt at playing gotcha. It's not necessarily that unsafe code is categorically bad and nobody should ever use software that is written without strong static guarantees. It's that, in a language like Rust that has such a high level of compile-time checking, and whose community places such a high premium on it, relying heavily on unsafe becomes a red flag. It…

relying heavily on unsafe becomes a red flag. It implies that the author of the code has a tendency to play fast and loose It does not imply that. It might mean that the author knows what he's doing. Or not. We don't know without auditing the code. defeat the ostensible purpose of choosing a language like Rust in the first place The OP didn't try to choose a language - they tried to choose a piece of software that so…

> We don't know without auditing the code

or when you really audit the code, find a problem, submit a patch and then the author dismisses your patch as "boring"

Post reply on HN