6 ms·

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

> 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. And regardless of how strongly you feel about 2), 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". These statements aren't mutually exclusive

ddevault 7y ago
>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 maintenance - these are the correct solutions.
- nevi-me 7y ago
  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.
  - notyourday 7y ago
    nodejs <=> io.js split was a great evolutionary step. It allowed for the chaffs to fall through making node a stronger project because it was clear that neither of the sides was going to "win" outright. If the argument is that "maintainer is not doing his/her job of being a maintainer" and this argument is accepted by the users, then should the project be forked by someone who will do his or her job of being a maintainer, the users will flip their source repo pointer and move onto the fork effectively killing the original.
    - nevi-me 7y ago
      The risk was worth it, node was stuck (in 0.12), and it was the whole thing, not "one of the things that you use to run JS on the server". A fork of actix wouldn't enjoy the same conditions that existed with Node. Does the fork care as much about TechEmpkwer benchmarks? What happens if it is slower because it forbids unsafe even where it makes sense? There was a looming cliff in Async/await, which caused a split to some extent (some old libraries that no longer have maintainers, changes that make updates difficult). A fork with those changes looming would mean divergence when rewriting to support Async/await. Maybe I'm being too cautious, but I doubt we'd have had a successful fork earlier. Let's see if it happens now ...
- Ygg2 7y ago
  > 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/debed733781db4aba2a52620b6725adf https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...
  - hjek 7y ago
    > 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?
    - ivanbakel 7y ago
      Cherry-picking a comment doesn't give a good representation of the community. The GP is right - most comments were courteous. The point is that saying "the community" was hateful and vitriolic needs more evidence than a couple of bad eggs, because those exist everywhere.
    - dependenttypes 7y ago
      This was posted after fafhrd91 was rude. Also... > The last few were rude, but so was the fafhrd91
  - enumjorge 7y ago
    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.
    - jhall1468 7y ago
      Just because it's easy to fork in the UI, doesn't mean it's easy to get people to switch. Some people are actually concerned about the community as a whole, rather than their own projects.
    - Ygg2 7y ago
- jasondclinton 7y ago
  You're lumping a few bad apples (apparently recruited from Reddit) in with "they". The users who found the bugs and provided patches were largely courteous considering the circumstances.
  - kungtotte 7y ago
    Steve Klabnik makes this point in his write-up, but I'm restating it here for clarity. You don't get to cherrypick who is part of your community or not when these situations arise. Those "bad apples" are part of the Rust community, and the Rust community needs to take responsibility for them the same way any community needs to take responsibility for their bad apples even if it's just to denounce their behaviour. Good thing that those who submitted the patches and PRs were polite; they're not the ones who caused this maintainer to quit though I'd wager...
    - jasondclinton 7y ago
      Should a politician be held responsible for every unhinged, vitriolic tweet by one of their supporters?
      - gbear605 7y ago
        Maybe not the politician, but the general group of “supporters of politician X” should be.
- cushychicken 7y ago
  I wholly agree with your viewpoint in this comment. There is a prominent "Fork" and "Clone" button in every GitHub repo. If you're so fucking sick of the lack of support from the maintainer, fork it, fix the flaws that you've found, and assume some of the responsibility for the project. This whole situation is a bunch of people getting angry because of what they view as a lack of accountability. That's preposterous - the nature of GitHub and open source makes it super easy for you to assume some of that accountability yourself. The fact that so many people chose to get upset rather than assuming accountability speaks volumes to me. Pull requests welcome, jerks. </s>
deng 7y ago
As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you.
- cforrester 7y ago
  That doesn't mean it's wrong to criticize his choices, so long as it's done without being insulting.
  - deng 7y ago
    Of course you can criticize, but people are continuously demanding things, like "he should have labeled it as a toy project", "he should have given reasons why he didn't accept the patch", etc. And Drew is very right to say: No, he didn't have to do any of that.
    - unethical_ban 7y ago
      You know, there is a lot of "He isn't required" but I will say there are reasonable expectations that people have when a project gets to a certain level of exposure/downloads/etc. and while someone should not be "cancelled" or tarred and feathered for not accepting a merge request, if your project is a leader in its niche (Rust web frameworks) you should do better. You publish your code to Github, you're part of a community. You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit.
      - deng 7y ago
        > You publish your code to Github, you're part of a community. Hell no. It that were the case, I'd never publish anything. > You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit. It is YOUR responsibility to see that for yourself by watching how the project is actually maintained.
falcolas 7y ago
The community's response might be valid if it were limited to that. But, quoting TFA, they went beyond that. "It’s extra nasty this time. Some people go far, far, far over the line." When someone polite says this, I picture some of the nastier attacks on the internet - doxxing, death threats, and swatting.
- cerebellum42 7y ago
  In this case it meant people saying things like "you are bad and you should stop writing rust, forever" possibly with some more colorful words in there. Very hurtful things but at least not threats and actions...
  - tssva 7y ago
    If someone poorly implements something, potential causes harm in doing so, doesn't accept that they have done so poorly and express a desire to learn and improve in future endeavors, it isn't even necessarily incorrect to express that they may not want to pursue that particular field anymore. Of course it should be done tactfully which I doubt most of the comments on Reddit did. I see this same sentiment expressed fairly often on HN in usually but not always more polite terms.
    - shkkmo 7y ago
      In what way is it correct or even helpful? Even if done tactfully, I have a hard time seeing that being taken by anyone as anything other than a personal attack. The correct response would be to organize the community to create a fork that is more focused on correctness and security than on performance.
      - tssva 7y ago
        It is correct and helpful because it can prevent continued poor behavior which impacts others. Trying to protect someone's feelings only goes so far. Sometimes you have to be straight and to the point with people whether they take it as a personal attack and it hurts their feelings or not. Whether it would be appropriate in this I case I don't know but I disagree that it is never the correct response.
throwaway17_17 7y ago
Rust is a programming language. Nothing more, nothing less. It is a tool. If I like the typing and macro systems used by Rust, but I do not care in the slightest about “memory safety” I can write my dirty, filthy ‘unsafe’ C style code with casts, and raw pointers, and multiple mutable references in a giant unsafe block and get a compiled binary out of rustc. And if I use the above style of coding to write a neat CLI tool and offer the code as open source on Github, so be it. What the purported ‘Rust community’ thinks the language professes doesn’t mean a thing. Use the tool or don’t. I don’t want to come as negative toward Rust or developers using it, but there is a whole lot of using Rust’s ‘security’ focus/features to say the Actix developer needed to do things a certain way. He wrote he, he could do whatever the hell he wanted.

ddevault 7y ago

>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 maintenance - these are the correct solutions.

nevi-me 7y ago
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.
- notyourday 7y ago
  nodejs <=> io.js split was a great evolutionary step. It allowed for the chaffs to fall through making node a stronger project because it was clear that neither of the sides was going to "win" outright. If the argument is that "maintainer is not doing his/her job of being a maintainer" and this argument is accepted by the users, then should the project be forked by someone who will do his or her job of being a maintainer, the users will flip their source repo pointer and move onto the fork effectively killing the original.
  - nevi-me 7y ago
    The risk was worth it, node was stuck (in 0.12), and it was the whole thing, not "one of the things that you use to run JS on the server". A fork of actix wouldn't enjoy the same conditions that existed with Node. Does the fork care as much about TechEmpkwer benchmarks? What happens if it is slower because it forbids unsafe even where it makes sense? There was a looming cliff in Async/await, which caused a split to some extent (some old libraries that no longer have maintainers, changes that make updates difficult). A fork with those changes looming would mean divergence when rewriting to support Async/await. Maybe I'm being too cautious, but I doubt we'd have had a successful fork earlier. Let's see if it happens now ...
Ygg2 7y ago
> 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/debed733781db4aba2a52620b6725adf https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...
- hjek 7y ago
  > 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?
  - ivanbakel 7y ago
    Cherry-picking a comment doesn't give a good representation of the community. The GP is right - most comments were courteous. The point is that saying "the community" was hateful and vitriolic needs more evidence than a couple of bad eggs, because those exist everywhere.
  - dependenttypes 7y ago
    This was posted after fafhrd91 was rude. Also... > The last few were rude, but so was the fafhrd91
- enumjorge 7y ago
  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.
  - jhall1468 7y ago
    Just because it's easy to fork in the UI, doesn't mean it's easy to get people to switch. Some people are actually concerned about the community as a whole, rather than their own projects.
  - Ygg2 7y ago
jasondclinton 7y ago
You're lumping a few bad apples (apparently recruited from Reddit) in with "they". The users who found the bugs and provided patches were largely courteous considering the circumstances.
- kungtotte 7y ago
  Steve Klabnik makes this point in his write-up, but I'm restating it here for clarity. You don't get to cherrypick who is part of your community or not when these situations arise. Those "bad apples" are part of the Rust community, and the Rust community needs to take responsibility for them the same way any community needs to take responsibility for their bad apples even if it's just to denounce their behaviour. Good thing that those who submitted the patches and PRs were polite; they're not the ones who caused this maintainer to quit though I'd wager...
  - jasondclinton 7y ago
    Should a politician be held responsible for every unhinged, vitriolic tweet by one of their supporters?
    - gbear605 7y ago
      Maybe not the politician, but the general group of “supporters of politician X” should be.
cushychicken 7y ago
I wholly agree with your viewpoint in this comment. There is a prominent "Fork" and "Clone" button in every GitHub repo. If you're so fucking sick of the lack of support from the maintainer, fork it, fix the flaws that you've found, and assume some of the responsibility for the project. This whole situation is a bunch of people getting angry because of what they view as a lack of accountability. That's preposterous - the nature of GitHub and open source makes it super easy for you to assume some of that accountability yourself. The fact that so many people chose to get upset rather than assuming accountability speaks volumes to me. Pull requests welcome, jerks. </s>

deng 7y ago

As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you.

cforrester 7y ago
That doesn't mean it's wrong to criticize his choices, so long as it's done without being insulting.
- deng 7y ago
  Of course you can criticize, but people are continuously demanding things, like "he should have labeled it as a toy project", "he should have given reasons why he didn't accept the patch", etc. And Drew is very right to say: No, he didn't have to do any of that.
  - unethical_ban 7y ago
    You know, there is a lot of "He isn't required" but I will say there are reasonable expectations that people have when a project gets to a certain level of exposure/downloads/etc. and while someone should not be "cancelled" or tarred and feathered for not accepting a merge request, if your project is a leader in its niche (Rust web frameworks) you should do better. You publish your code to Github, you're part of a community. You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit.
    - deng 7y ago
      > You publish your code to Github, you're part of a community. Hell no. It that were the case, I'd never publish anything. > You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit. It is YOUR responsibility to see that for yourself by watching how the project is actually maintained.

falcolas 7y ago

The community's response might be valid if it were limited to that. But, quoting TFA, they went beyond that. "It’s extra nasty this time. Some people go far, far, far over the line." When someone polite says this, I picture some of the nastier attacks on the internet - doxxing, death threats, and swatting.

cerebellum42 7y ago
In this case it meant people saying things like "you are bad and you should stop writing rust, forever" possibly with some more colorful words in there. Very hurtful things but at least not threats and actions...
- tssva 7y ago
  If someone poorly implements something, potential causes harm in doing so, doesn't accept that they have done so poorly and express a desire to learn and improve in future endeavors, it isn't even necessarily incorrect to express that they may not want to pursue that particular field anymore. Of course it should be done tactfully which I doubt most of the comments on Reddit did. I see this same sentiment expressed fairly often on HN in usually but not always more polite terms.
  - shkkmo 7y ago
    In what way is it correct or even helpful? Even if done tactfully, I have a hard time seeing that being taken by anyone as anything other than a personal attack. The correct response would be to organize the community to create a fork that is more focused on correctness and security than on performance.
    - tssva 7y ago
      It is correct and helpful because it can prevent continued poor behavior which impacts others. Trying to protect someone's feelings only goes so far. Sometimes you have to be straight and to the point with people whether they take it as a personal attack and it hurts their feelings or not. Whether it would be appropriate in this I case I don't know but I disagree that it is never the correct response.

throwaway17_17 7y ago

Rust is a programming language. Nothing more, nothing less. It is a tool. If I like the typing and macro systems used by Rust, but I do not care in the slightest about “memory safety” I can write my dirty, filthy ‘unsafe’ C style code with casts, and raw pointers, and multiple mutable references in a giant unsafe block and get a compiled binary out of rustc. And if I use the above style of coding to write a neat CLI tool and offer the code as open source on Github, so be it. What the purported ‘Rust community’ thinks the language professes doesn’t mean a thing. Use the tool or don’t. I don’t want to come as negative toward Rust or developers using it, but there is a whole lot of using Rust’s ‘security’ focus/features to say the Actix developer needed to do things a certain way. He wrote he, he could do whatever the hell he wanted.