A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#321

Post by nevi-me » Fri, Jan 17, 2020, 4:45 PM UTC

ddevault wrote: post #83

dashwav wrote: post #73

Earlier quoted context omitted.

> 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 anything in the slightest. I don't think the anger is directed at there being security issues, the anger is directed at the fact that even when security vulnerabilities where found and patched, there was major pushback even getting those patches merged into the library.…

>the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care" Yes, but that's not what they said. They were hateful and virtrolous, which is never appropriate. Fork it and fix the problems, create a new library which has the same API but is more sound, promote an alternative library in its place, offer to lend a hand in ma…

Counter: what about the tension and potential community split when a fork starts getting popular?

I was there (as a user who closely followed development) during the nodejs > io.js split. While it worked out in the end, it felt like a bitter battle at first. Node survived by chance perhaps.

We have our async-std vs Tokio right now, I'd imagine having another split (at least in opinions and preference) on actix would still keep tension high.

Re: A Sad Day for Rust

#322

Post by birracerveza » Fri, Jan 17, 2020, 4:45 PM UTC

tus88 wrote: post #285

birracerveza wrote: post #267

Earlier quoted context omitted.

I don't know man, the emotion unveiled by your comment shows a deep anxiety in the C community that Rust is going to replace you.

Actually most of us would welcome a "better C", it was just obvious from the outset rust wasn't it. Rust with unsafe - as dangerous as C in the hands of a amateur, as comprehensible as poorly written machine code.

You are just not used to Rust's syntax. In my experience, Rust is much more readable than C, but that's probably because I actually wrote Rust code that is used in production while I only have a theoretical understanding of C.

It's only a matter of experience with the language.

And as the blog post mentioned, `unsafe` is actually necessary to interface with other languages, including C. Without that there's no way it would be able to catch on. Sure, it's a footgun, but it's probably the only one and, again, necessary. It's all about developer responsibility. Maybe to improve the situation we could make it so that when you add a crate cargo explicitly warns you about how many `unsafe`s there are.

Re: A Sad Day for Rust

#323

Post by Brave-Steak » Fri, Jan 17, 2020, 4:46 PM UTC

Brave-Steak wrote: post #218

All discussion I saw about the issue was quite civilized. https://old.reddit.com/r/rust/comments/epzukc/actix_web_repo... https://old.reddit.com/r/rust/comments/epoloy/ive_smoketeste... I get that people hate Reddit around here, but pushing this on them as vitriol by the Rust community there is wholly unfair. The impression I've gotten is that the developer of actix used unsafe too much, made no attempt to inform use…

Found a working copy of the original Github issue: https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...

Aside from maybe the second to last comment, I don't see anything here that deserved deletion.

Re: A Sad Day for Rust

#324

Post by steveklabnik » Fri, Jan 17, 2020, 4:46 PM UTC

quotemstr wrote: post #249

steveklabnik wrote: post #116

Earlier quoted context omitted.

I actually agree with you in a general sense, but our own opinions don't really matter much. What matters is the opinions in the aggregate. I wish that it wasn't perceived as such, but the reality is that it is. Ignore that at your own peril.

What peril? Why is everyone treating online outrage mobs as if they had any power or authority? Who cares if some unimportant anonymous commentator thinks a fork is aggressive?

If you are trying to get people to use your project, understanding how those people perceive your project is step 1.

Re: A Sad Day for Rust

#325

Post by tssva » Fri, Jan 17, 2020, 4:46 PM UTC

steveklabnik wrote: post #139

jimbokun wrote: post #108

Earlier quoted context omitted.

All of this is second hand, where are the mean comments "making" this person quit their own project? Were they actual personal attacks, or just criticism of the code? If you can't accept legitimate criticism of your work, that shows a real lack of maturity. (The article didn't give concrete examples, so I don't know which is the case here.)

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

Depending on the context that doesn't seem to be "far, far over the line."

Just about any thread on HN regarding any aspect of systemd or Google will have comments which are much more vitriolic.

Re: A Sad Day for Rust

#326

Post by watwut » Fri, Jan 17, 2020, 4:46 PM UTC

blackearl wrote: post #18

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…

I'm sure both sides are being childish here. Users thinking they can abuse a dev because they know better, and devs deciding they'd rather take their ball and go home. No one looks good at the end of this situation.

Taking the ball home when other kids abuse or bully you is correct action.

That is actually one of the things we teach the kids who are in these situations to do. It is ok to have a boundary, it is ok to leave the situation and it is ok to stand your ground. You don't ask for abuser validation nor permission.

Re: A Sad Day for Rust

#327

Post by amyjess » Fri, Jan 17, 2020, 4:46 PM UTC

pjc50 wrote: post #273

amyjess wrote: post #237

Earlier quoted context omitted.

And this is why I honestly don't ever want to release an open-source project. At the very least, I'm not going to make it easy for people to contribute. I'll keep the git repo private, go without a ticketing system, and just post tarballs full of code on a self-hosted website (I guess like the NetHack team used to do before 3.6, but they had a ticketing system, and I wouldn't). Maybe I'll even use a non-free license…

Why? I mean, if you're that hostile to collaboration, why not just keep it closed source and maybe try to charge for it?

Python is my language of choice, so posting projects means publishing the source code.

Re: A Sad Day for Rust

#328

Post by gmaster1440 » Fri, Jan 17, 2020, 4:46 PM UTC

gowld wrote: post #296

gmaster1440 wrote: post #152

Perhaps we can get at a deeper, more durable insight if we assume for a moment that most individual actors are well-intentioned, and that the described vitriol on one side and perceived stubbornness on the other is an externality of the unfortunate incentives (or lack thereof) that are parasitic on the open source community. It's almost instinctual/natural to misjudge the popularity of any project for some false sens…

It is a problem with people, people wanting to have their cake and eat it too. Open source is made of people.

You're right in the sense that, at the end of the day, almost every organizational/social structure is made of people. The interesting thing for me is to see what incentive structures are at play that incentivize otherwise good people to do apparently bad things.

We can think about these larger, emergent structures like programming language and open source communities independently of the individuals that comprise them.

Re: A Sad Day for Rust

#329

Post by tomjakubowski » Fri, Jan 17, 2020, 4:47 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…

Nikolay works for Microsoft, who use actix-web internally. He was putting in 12 hour days for 3 weeks porting the project to async/await, so I sure hope that Microsoft was paying him for it!

Re: A Sad Day for Rust

#330

Post by pgeorgi » Fri, Jan 17, 2020, 4:47 PM UTC

mlthoughts2018 wrote: post #198

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…

> “ 2. Open source participants are volunteers and owe you nothing.” Absolutely not. They are compensated with prestige, enjoyment, decision-making power, future employment rewards, and sometimes even money, all of which was their choice to pursue through their labor and time spent on the open source project. The users of open-source projects, upon which the projects themselves depend, are also not obligated to anyth…

>> “ 2. Open source participants are volunteers and owe you nothing.”

> They are compensated with

> prestige,

That seems associated with the popularity of a project which is largely outside the control of an author. So: how could one publish code (just in case it's useful to somebody else, which seems to be a nice thing to do) and opt-out of the popularity contest?

> enjoyment,

People can have the same enjoyment without publishing the code, so there's nothing open source about that.

> decision-making power,

In their own project? Of course. Again, they could just keep it private, with exactly the same decision-making power - nothing open source about that.

> future employment rewards,

If a developer ships crap code, that issue seems to sort itself out automatically (who would hire a proud author of unsafe code?)

> and sometimes even money,

Those paying money certainly can and do make demands. I haven't heard claims about breach of contract in this case, so that's probably not a factor here?