A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#831

Post by alfiedotwtf » Fri, Jan 17, 2020, 10:01 PM UTC

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?

Yes. I try not to use things built in C when there are other alternatives. Why? https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=use+after+f...

Re: A Sad Day for Rust

#832

Post by mumblemumble » Fri, Jan 17, 2020, 10:02 PM UTC

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…

To your first comment, I hadn't intended there to use 'implies' to mean logical implication. There's room in the vernacular 'implies' for "or maybe not."

Though I think that we can trot out logical implication in response to your second comment: Considering taking actix-web as a dependency logically implies that you have chosen to write your program in Rust. Or, at least, the only language I'm aware of being able to import Rust modules is Rust.

Re: A Sad Day for Rust

#833

Post by [deleted] » Fri, Jan 17, 2020, 10:05 PM UTC

dunnock wrote: post #688

kllrnohj wrote: post #503

Earlier quoted context omitted.

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

Your statement is false. They called for contributors many times, last time in August https://github.com/fafhrd91/actix-web/issues/1019 .. This was public and open message and is not the first time. Though while people are ready to open issues and complain, sometimes even supply patches and make big noise if they do not pass code review, there were nobody who could join to share responsibility in making decisions abo…

[deleted]

Re: A Sad Day for Rust

#834

Post by WalterBright » Fri, Jan 17, 2020, 10:06 PM UTC

steveklabnik wrote: post #796

WalterBright wrote: post #665

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.

Thanks Walter. I've been following along with your work, actually, though I don't know enough D these days to really understand it fully. Neat to see though!

I don't fully understand Rust, either, so we're even!

Don't worry about the haters. If I paid attention to them I never would have accomplished anything. People are always going to misuse a tool.

And some good news, the first stage of D's Ownership/Borrowing system was pulled today!

https://github.com/dlang/dmd/pull/10586

Re: A Sad Day for Rust

#835

Post by kllrnohj » Fri, Jan 17, 2020, 10:08 PM UTC

dunnock wrote: post #688

kllrnohj wrote: post #503

Earlier quoted context omitted.

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

Your statement is false. They called for contributors many times, last time in August https://github.com/fafhrd91/actix-web/issues/1019 .. This was public and open message and is not the first time. Though while people are ready to open issues and complain, sometimes even supply patches and make big noise if they do not pass code review, there were nobody who could join to share responsibility in making decisions abo…

> Your statement is false. They called for contributors many times, last time in August https://github.com/fafhrd91/actix-web/issues/1019 .. This was public and open message and is not the first time.

That thread is full of people trying to sign up and help. Either they all lied or nobody was accepted.

Re: A Sad Day for Rust

#836

Post by prepend » Fri, Jan 17, 2020, 10:08 PM UTC

pdimitar wrote: post #439

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…

Agreed 100%. May I add one point? The OSS maintainer should clearly, upfront, preliminarily, outline how do they govern the project: how much are they open to change the project's core values, how responsive on average will they be in terms of opened issues and PRs, roughly how often would they engage in technical architectural debates -- stuff along those lines. I feel many people get toxic if they had unrealistic e…

You can do this for your projects, but I don’t care if someone does this.

I’m grateful just to see the code and choose to use it, or not. If I think some random volunteer should do something, I’ll attach that suggestion with some money or a contract or at least a beer.

What I love about open source is that it’s a big place that has lots different people. It’s beautiful because someone can write code and never talk to anyone and their code is still good and useful.

Maybe a better, more truthful statement is “OSS maintainers will have better engagement with the community if they proactively manage expectations.” And if the maintainer cares about that, it will apply. But I think there are quite a few projects that don’t really care much about community.

Re: A Sad Day for Rust

#837

Post by yellowapple » Fri, Jan 17, 2020, 10:11 PM UTC

manish_gill wrote: post #26

vunie wrote: post #6

I don't know how to word this so I'll say it bluntly (and probably bear the blunt of this community as a consequence): If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project. No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. Of course, you could…

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

> It's not like he was getting paid to work on this, was it?

So? If I'm donating clothes to one of those coat drives, and the clothes I donate are tattered and covered with rodent feces, should the organizers of said drive not be upset with me? Especially if said organizers point this out politely and I respond with "lol you'll take what I give you, peasant"?

Re: A Sad Day for Rust

#838

Post by kelnos » Fri, Jan 17, 2020, 10:13 PM UTC

AnonymousPlanet wrote: post #683

GrinningFool wrote: post #308

Earlier quoted context omitted.

> Open source is not some backyard game anymore. It > involves companies and their commitment in form of > infrastructure and participation. I think this approach leads to sustainability problems, and discourages individuals from sharing their work in open source form. I make a project because I need it, and maybe it's fun to build. I generally share it because I think others might find it useful too. What I'm readin…

> I think this approach leads to sustainability problems, and discourages individuals from sharing their work in open source form. I make a project because I need it, and maybe it's fun to build. I generally share it because I think others might find it useful too. I don't believe that every little open source project is automatically held to the rules I described. But once your exposure gets bigger, you suddenly ent…

> But once your exposure gets bigger, you suddenly enter different waters.

I fundamentally disagree with this. Just because my exposure has gotten larger (possibly through no action of my own), it doesn't magically give me more resources, more free time, more motivation, a team of developers, etc. If people (or companies) want to depend on a one-person open source project for something important to them, then they should pay to fund it, either by giving that developer money directly, or by hiring people in-house to contribute to that project.

(Not doing so is just foolish and risky on the company's part, too: depending solely on an unpaid volunteer for an important part of your infrastructure is not a winning move.)

Also consider that more users generally means less free time for developing, and more time handling bug reports and support issues. If an open source project grows, it's absolutely critical for users to step up and pitch in, either with their own skills, or with monetary resources that can help the maintainer (who might have a day job) focus more on the project.

Maintainers do have a responsibility to decide what they want their level of involvement to be, though, and to communicate that. Potential users should have the information they need to decide if the project they want to depend on is well-supported and sustainable. They have no right to demand that the maintainer change their approach or level of involvement, however.

> But once you got into the limelight with your project and other people started depending on it, every misstep suddenly becomes a jackass move.

I really dislike the lack of charitable interpretation given here, and this just contributes to the "entitled user" image. The unpaid maintainer of an open source project does not owe anyone anything. Full stop. Users are responsible for their dependencies. I'll repeat that: users are responsible for their dependencies. If they are going to take on a dependency for that's given away for free and not do their due diligence to make sure it is reliably and sustainably developed, that's on them. If they're not happy with the maintainership and want to use it anyway, that's on them. Users do not get to tell unpaid maintainers how to maintain their software. If they want to be helpful and constructive, that's great, but anything less is rude and unwanted.

Re: A Sad Day for Rust

#839

Post by ampersandy » Fri, Jan 17, 2020, 10:13 PM UTC

nickbauman wrote: post #610

jupp0r wrote: post #250

Earlier quoted context omitted.

> Rust seems to be being used most by people who are interested in blockchain and crypto. What makes you think that? I don't believe that is true, it's like saying C++ programmers are mostly interested in high frequency trading.

Well then who are these people?

https://github.com/search?q=language%3Arust

You can easily find counter-examples if you look for them.

Re: A Sad Day for Rust

#840

Post by bpt3 » Fri, Jan 17, 2020, 10:13 PM UTC

kllrnohj wrote: post #806

bpt3 wrote: post #661

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

> 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. Of course it doesn't make sense, that was my point! In the same way it doesn't make any sense to do what you're doing, which is comparing the explicit statement of liability in the license to the social norm of how open source projects are framed & run. You misse…

No, everything is not just social norms, because there is no agreed upon norm or standard "framing" for open source projects (as indicated by all the disagreements here and elsewhere on this topic), leaving the actual license as the only concrete, agreed upon description of obligations and expectations between the creator/maintainer and users.