A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#661

Post by bpt3 » Fri, Jan 17, 2020, 7:20 PM UTC

kllrnohj wrote: post #595

Touche wrote: post #551

Earlier quoted context omitted.

Read the license, it frames the project exactly.

The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis. Alternatively if we're going to just go strictly by the license then the maintainer deserved all the flames & flak he got. After all, it wasn't against the license, therefore he cannot complain about it. Just like that idea is unreasonable, so too is trying to hide behind…

> The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis.

You completely missed the point. At the end of the day, the legal obligations are the only ones, and both the Apache and MIT licenses very clearly state that the creator of the software has no obligations to any user.

Therefore, any other supposed obligations only exist in the mind of the person who has created them, and do not exist in reality.

> Alternatively if we're going to just go strictly by the license then the maintainer deserved all the flames & flak he got. After all, it wasn't against the license, therefore he cannot complain about it. Just like that idea is unreasonable, so too is trying to hide behind the license in this case.

Sorry, this doesn't make sense, because you're comparing an explicit statement of liability in the license to the social norm of not being a massive jerk.

Re: A Sad Day for Rust

#662

Post by pjmlp » Fri, Jan 17, 2020, 7:20 PM UTC

dcolkitt wrote: post #566

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. This is a nice idea, but in an era of one-button package managers it just doesn't work like that. You're trying to fight against New Jersey style. Which in the entire history of software has never been a winning approach. The reality is that for 95%+ of active software developers, done is better than perfect. Yes there may be a small subset of developers working on supe…

It sure does work like that.

Our package managers have in-house mirrors, only validated dependencies by legal are allowed on those mirrors.

Installing in 30 seconds is not allowed by design.

Re: A Sad Day for Rust

#663

Post by khazhoux » Fri, Jan 17, 2020, 7:21 PM UTC

kllrnohj wrote: post #503

BowBun wrote: post #343

Earlier quoted context omitted.

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs w…

> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. It is when they setup an open source project that has that appearance and is framed as being such a project. It is entirely the maintainer's responsibility to establish the type of open source project it is. If it was just a toy hobby project and that's all it was meant…

> It is entirely the maintainer's responsibility to establish the type of open source project it is.

On what basis does a developer assume this responsibility? You are saying that by uploading a library that works well, and whose presentation (docs, etc) are high quality ("professional") that the owner now has the responsibility to publicly state whether this is a personal project or not, and they must state their SLA and process with respect to accepting patches? No such thing.

> That's entirely the fault of the maintainer. They set all that up. They established the expectations of the project.

If the maintainer says "I shall provide X amount of service" but then does not, that's on the maintainer.

But if a user likes a library and starts depending on it without checking if the library is "properly maintained", that's on the user. How can it be otherwise?

Re: A Sad Day for Rust

#664

Post by lallysingh » Fri, Jan 17, 2020, 7:22 PM UTC

AnIdiotOnTheNet wrote: post #619

lostmyoldone wrote: post #587

Earlier quoted context omitted.

The opinion that the software isn't that good for the problem is cheap to state, and unless the circumstances are exceptional, I would argue it quite reasonable to see it as entitlement. If someone is terribly dressed according to my taste but brags about how amazing the garb is, I'm not going to tell them how they are wrong unless absolutely necessary because of exceptional circumstances. Neither does most people wh…

> If someone asks for feedback, sure, your points are not wrong. If they're actively asking me to use their software, isn't that soliciting feedback? If I say 'no, it won't work for me', I've apparently committed some egregious microaggression right? If I just say 'no thanks', what do expect the very next thing they say is going to be?

Who said they're actively asking you? I'd say most smaller open source (e.g., single dev) projects are "here's what I built, maybe it's useful for you too."

Re: A Sad Day for Rust

#665

Post by WalterBright » Fri, Jan 17, 2020, 7:23 PM UTC

Steve, you have done a fantastic job. Don't let these issues get you down.

As an indication of that, I've been implementing an ownership/borrowing system for D. I expect to see some of the same issues you brought up. But for the people that want to use it correctly, it will produce the benefits. And that's what I care about.

Re: A Sad Day for Rust

#666

Post by temac » Fri, Jan 17, 2020, 7:24 PM UTC

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…

While I 100% agree with you, project having chronically technical issues are bound to get a bad reputation.

So what is "missing" is a common way to discuss about that kind of issues, as a community, while staying civil and not in a way that is worse than the initial issue. In some cases the end-result could be the kind of the same (if most users flee), but the goal is obviously to improve the ecosystem and if managed more appropriately, it is possible that some maintainers are wanting to improve their software to the state of the art.

Re: A Sad Day for Rust

#667

Post by Wowfunhappy » Fri, Jan 17, 2020, 7:24 PM UTC

oaiey wrote: post #660

Wowfunhappy wrote: post #614

Earlier quoted context omitted.

> Open source participants are volunteers and owe you nothing. I can't agree. Not for all participants. Let's take Linus. He's in charge of the Linux project, which thousands (millions?) of people contribute to every day. If Linus suddenly stopped merging any and all patches—but refused to officially step down—what do you think would happen? Oh, the project would more than survive—someone would fork it and that would…

Linus is paid to carry that responsibility. Others are not.

True, but for the reasons I detailed above, it's not the payment that matters. Linus could also probably make more money on a different project, but he's committed to Linux.

Re: A Sad Day for Rust

#668

Post by trunnell » Fri, Jan 17, 2020, 7:24 PM UTC

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 he could get in the TechEmpower benchmarks. So he took license to use a lot of unsafe Rust code to improve speed. He apparently was not trying to make the world's best web framework, one that is safe and fast. Just one that is fast. Oops, expectations busted.

Everyone is to blame. No one should believe that all Rust code is perfectly safe, and we need better ways to know which Rust crates are trustworthy. And the actix-web maintainer could have taken more responsibility for setting people's expectations that the project prioritized speed above security.

I love the Rust Book by Steve Klabnik and Carol Nichols. But I think Steve is off base in this post when he implies that Davidoff is wrong about unsafe code increasing a library's security risk. Of course unsafe poses a risk. Of course it's legit to avoid libraries with lots of unsafe code, especially unnecessary unsafe code. Actix-web was taking a lot of risk, more than people expected.

Re: A Sad Day for Rust

#669

Post by aidenn0 » Fri, Jan 17, 2020, 7:24 PM UTC

bpt3 wrote: post #661

kllrnohj wrote: post #595

Earlier quoted context omitted.

The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis. Alternatively if we're going to just go strictly by the license then the maintainer deserved all the flames & flak he got. After all, it wasn't against the license, therefore he cannot complain about it. Just like that idea is unreasonable, so too is trying to hide behind…

> The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis. You completely missed the point. At the end of the day, the legal obligations are the only ones, and both the Apache and MIT licenses very clearly state that the creator of the software has no obligations to any user. Therefore, any other supposed obligations only exist…

> You completely missed the point. At the end of the day, the legal obligations are the only ones, and both the Apache and MIT licenses very clearly state that the creator of the software has no obligations to any user.

There's a word for people who only fulfill their legal obligations: Assholes.

Re: A Sad Day for Rust

#670

Post by strbean » Fri, Jan 17, 2020, 7:25 PM UTC

endothrowho333 wrote: post #21

> “Why Reddit is like this” is a whole other essay; I think it’s built into reddit’s structure itself. Classic Eternal September. Around 60k subscribers, the cultural identity starts degrading, as the amount of "old guard" is outmatched by "new blood." Therefore, the old "monkey see, monkey do" phenomenon, where new users would slowly mimic the culture of the prevailing older users to "fit in," is replaced with new u…

Psh, do you even know what time the narwhal bacons? /s

I think Reddit is interesting because its design is more resistant to Eternal September than other communities. See the trend of creating r/TrueX when r/X gets Septembered.

Unfortunately, this hits diminishing returns when more and more obscure subreddits need to be created. Tons of oddly specific niche subreddits have popped up and completely gone to shit in a flash. I think we're nearly due for the next migration (maybe a federated alternative?).