9 ms·

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

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 Actix does should use any unsafe code at all, so I didn't use it. When I later saw the way the maintainer responded to well-meaning bug reports, including patches, that validated my decision. There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code.

munmaek 7y ago
What do you use now? Warp?
- deleted 7y ago
  [deleted]
- dbcfd 7y ago
  Right now, if you want async/await, you either have warp or tide. Hopefully gotham or rocket gets around to updating.
  - rudedogg 7y ago
    Can anyone comment on how close Rocket is to a 0.5 release? I’ve been wondering for awhile, but opening an issue to ask seems annoying.
    - agersant 7y ago
      I don't have any insight but you can subscribe to this issue to see how things are moving: https://github.com/SergioBenitez/Rocket/issues/1065 https://github.com/SergioBenitez/Rocket/issues/1065
    - nicoburns 7y ago
      I've been following this quite closely. Most of the work seems to be done. But development is very stop-start in fits and bursts, so it's hard to tell how much longer it will take.
  - kevinastone 7y ago
    Gotham will be async-ready once this PR lands and the next release is published: https://github.com/gotham-rs/gotham/pull/370 https://github.com/gotham-rs/gotham/pull/370
    - anon463637 7y ago
      Noice. To me, Gotham makes more sense because it depends on stable, whereas Rocket uses nightly. Anything depending on nightly seems inherently more fragile and un-future-proof (no pun intended).
- _-___________-_ 7y ago
  We just use hyper directly, with a small amount of glue code to use serde_json, serde_urlencoded for body parsing and a very simple (and very fast) router of our own creation. This approach also made it very simple for us to introduce std-future/async-await in a gradual way.
- mojzu 7y ago
  I've been in the process of switching to tonic for the last few of weeks. Based on hyper/tower and has async/await support. It's a gRPC server rather than HTTP, so I've been using it with grpc-gateway to provide an HTTP OpenAPI v2 interface. It has automated quite a few things I found dull to do in other server frameworks, from the gRPC .proto file I can generate: - Rust server request/response types and request handler stubs. - grpc-gateway files and an OpenAPI v2 json spec. - Client side typescript types and request/response handlers from the OpenAPI spec. So now the process of adding a new endpoint is much less time consuming and involves writing less repetitive and error prone code. As mentioned above I've only been using it a few weeks but so far it has been great, easier to use than actix-web and felt no less responsive.
mumblemumble 7y ago
I hit a same conclusion about a popular framework (that shall remain unnamed) on a different platform a few years back. It feels like it should be simple: I disagreed with how the maintainer was doing things, so I decided the package was not for me. No need to hassle them about it. I wish it could be that simple. Instead, I had to weather a fair bit of defending my choice to use a different, less popular option, and there's apparently no honest answer I can give that won't be taken as an attack on the framework or its users. And refusing to engage with the question is, of course, rude. I'm finding that Internet culture wears me down, these days. Even when you don't go looking for flamewars, they come looking for you. With less-popular libraries, it's easier. Open an issue, say hi, make sure the maintainer knows what you're planning on doing, do it, learn a few things, have a nice day. Once or twice I've been asked to more-or-less rewrite the patch because the maintainer didn't like something about my coding style, which is also fine, and often a good way to try a different way of doing things on for size. It's all pretty benign. But popular, well-known projects have this way of getting political. I suspect that the worst thing that could possibly happen to one of my labors of love would be for lots of other people to like it, too. A few people, great. But I don't want my free time to become Internet politicized.
C14L 7y ago
Or fork the code. That's the great thing about FOSS.
- sendilkumarn 7y ago
  This could have solved a lot of problems...
  - mratsim 7y ago
    and introduce new flamewars about "Not-Invented-Here", why don't you contribute to a common codebase, ffmpeg vs libav/avconv debacle.
    - pgeorgi 7y ago
      ffmpeg / libav had lots of bad blood long before the fork, which might have been the real driver for making it a "debacle". GitHub in particular has a "fork" button to make it super-easy. So fork, do your edits. If you want, make a pull request with the original project. If they take it, great: the fork can cease to exist. If they don't want to merge it don't take it personally but go your own merry ways. And this is what didn't happen with actix.
- anon463637 7y ago
  Forking if it's mature and featured enough to justify it, but it maybe too unsafe broken to invest in rewriting large swaths of code. That's the perpetual trade-off of engineering decisions; whether to build, fork or buy.
deleted 7y ago
[deleted]
strbean 7y ago
I have to question your position from a moral standpoint though. If you were a rollercoaster engineer, and you saw that a rollercoaster had an unsafe design, would you follow a similar approach? "I'm not going to ride that, but I'll let this line of people ride it without warning them." Obviously the stakes are wildly different, but still...
- swayson 7y ago
  That is a false equivalence, roller coasters have far more material risk given human lives are at stake.
  - nindalf 7y ago
    If you had discovered Heartbleed, would you have kept that knowledge to yourself so that you could minimize the maintenance burden on the OpenSSL develoopers? Granted, no one died over Heartbleed but it caused lots of real people harm. We should start worrying about the well being of our fellow human beings long before their lives are at stake.
    - deleted 7y ago
      [deleted]
    - swayson 7y ago
      Agreed, we have a responsibility as a community to not cause harm and even take effort to prevent it. That is what I like about HN, it is a place where these things are discussed and as a collective, positive outcomes can manifest.
    - iforgotpassword 7y ago
      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?
kbenson 7y ago
Part of using any piece of software, professionally or privately, open source or commercial, is assessing how well if will meet your needs now and in the future, and possible complications you might anticipate. Doing this well and thoroughly is extremely hard, and commercial enterprises spend a lot of time and money doing so (or pay the equivalent of insurance to not worry about it). Doing a minimal amount of research entails doing what you did. Look at the current and past state of the item in question, and decide whether it's worth putting the significant amount of time and effort into using it. I can't help but feel the vast majority of people complaining failed to do this minimal amount of legwork. They're upset about their lack of forethought for what they view as a bad investment, but that's on them. Unfortunately, I find people often have a hard time accepting blame onto themselves, but feel there is blame to be assigned, and so it needs to be directed somewhere. They say don't look a gift horse in the mouth, but if you are responsible for dealing with whatever diseases that horse might introduce to your stable, or even if you are just legally obligated to deal with the care and feeding or removal on death of such a large animal, you definitely look that horse in the mouth for red flags.
- deleted 7y ago
  [deleted]
deleted 7y ago
[deleted]
bachmeier 7y ago
> There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code. It works both ways. You put something out there, you need to be ready for the response. I'm not a Rust user, but presumably there was a reason other than charity that he put it out there (show off his brilliance, use it to get jobs, I don't know - but it was something he did for his own benefit). If you don't like that, don't make your code available to others, and don't complain if others act in a way you don't like. There's so much posted on HN about "open source entitlement". Well, the entitlement seems to run in both directions. That's the simple the reality of the situation.
- kelnos 7y ago
  I don't think "entitlement" means what you think it means. Unless you're arguing that people shouldn't feel entitled to be free of harassment, in which case I don't agree with you. Yes, if you put something out there, you should expect feedback, and assume that some of that feedback is not going to be very nice. But that doesn't excuse the people giving that feedback for being rude. It doesn't excuse the fact that those people giving feedback have no inherent right to see that feedback acted upon, and expecting that is unreasonable and entitled. I'm not saying I would have acted the same way the actix developer did (in my experience as an open source maintainer I certainly have some moments I'm proud of, and others that I wish I could take back), but I'm not so quick to condemn them, either.
  - bachmeier 7y ago
    Well, I'm using the dictionary definition: entitled: to furnish with proper grounds for seeking or claiming something example: this ticket entitles the bearer to free admission Being an open source maintainer doesn't mean you're entitled to recognition or praise or deference. You're not entitled to put out low-quality software and have others pretend it's awesome. You're not entitled to make claims that are false and not be called out for it. You're not even entitled to people not trashing your work. When you put your work out there because you want to be praised, that's the downside. "But that doesn't excuse the people giving that feedback for being rude." That has nothing to do with being entitled (at least not in the context of an open source project). That's basic human interaction.
p1esk 7y ago
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?
- mumblemumble 7y ago
  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 implies that the author of the code has a tendency to play fast and loose in a way that you might not want to welcome into your own codebase if you don't have to. Where unsafe is supposed to be treated as a sort of pinky swear that says, "The compiler couldn't guarantee that this is safe, so I did," that starts to get scary, because any errors will undercut the safety guarantees that the compiler is supposed to be enforcing on your own code. And a large volume of unsafe code implies a large manual verification burden, and a larger volume of code that's easy to accidentally break. And the more of it that should be manually verified there is, the lower the chances that it is actually being manually verified. So it threatens to defeat the ostensible purpose of choosing a language like Rust in the first place. That's not to say that programming Rust that way is wrong or evil in any objective sense. But it's something that needs to play into a decision on whether to take a dependency on such code. When you link code, you're inviting it into your process space, and you now have to accept responsibility for anything it does while it's in there.
  - p1esk 7y ago
    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 solves their problem. Seemed like the software was rejected on wrong grounds.
kragen 7y ago
> There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code. Also, you can change your copy of it to work the way you want, and if you decide to share it, other people can choose to use your version if they like it better. You don't have to bully other people to get your needs meet, individually or collectively. These are among the core benefits of open source. Probably in this case most people would have ended up using the less-unsafe fork of the project, and the original author would have tried harder to extract the potential performance benefits of his more-unsafe version, while both groups constantly learned from one another. Everyone would have benefited. I've written a bit about the history of some such friendly forks at https://news.ycombinator.com/item?id=22080672 https://news.ycombinator.com/item?id=22080672
- tus88 7y ago
  I wonder if authors consider "friendly" forks to be friendly ...
  - catalogia 7y ago
    I think that probably depends on the nature of the words exchanged before the fork. Many forks happen after nasty comments have been thrown around.
  - kragen 7y ago
    The XEmacs fork I mentioned had some bad feelings attached. As far as I know the other examples I mentioned (Stackless, swap-to-NFS, LuaJIT) don't. But it doesn't matter what authors think. What matters is what helps the users. Would you ask for Newton's approval before calculating a planetary trajectory, or Kalashnikov’s before designing an automatic rifle? Their achievements matter precisely because they empower everyone, for better or for worse. Emphasizing authors’ feelings in this way has the effect of diminishing their software from a contribution to the intellectual heritage of humanity to merely a service like delivering a pizza. Don't forget to tip your waiter! Of course you should be nice to authors if you interact with them. But the whole point of open source is that you don't have to interact with them unless you want to.
dunkelheit 7y ago
This is the standard voice vs. exit dilemma. Rust community is, for better or worse, very worried about "fracturing the ecosystem" so they generally prefer voice. Well, some of these voices can get ugly.
namibj 7y ago
I'm curious what you'd recommend instead for async pgsql requirements as a Rust web framework. Actix seemed interesting, but I didn't know about the masses of unsafe. These too eliminate it, because it'd be able to crash/break a cluster that uses deliberate unsoundness for its serialization/deserialization needs in the vain of speed (timely-dataflow), allowing memory issues to spread (at least in theory)... I thus can't use a framework that uses this much unsafs/has known stray pointers or similar bugd/issues.
- _-___________-_ 7y ago
  We use tokio-postgres. Previously we had our own connection pool implementation, but we recently switched to deadpool.
  - namibj 7y ago
    Thanks! The pipelining is just really important to get proper performance out of CockroachDB (mostly due to network and coordination overhead due to it's cluster architecture).
infinity0 7y ago
I don't like contempt culture either but there's a balance to be made here - if you let everyone do everything and encourage them all as special snowflakes that can't create anything crappy, a community will also go to shit. In this case it does sound like people initially were very nice and tried to give the author very polite suggestions on improvement, and it was only after the author being extremely dismissive[1], not admitting to his own flaws, not wanting to learn from others, and abusing his own power in shutting down valid discussion, that things turned nasty. The fact that the author deleted many of the linked issues e.g. https://github.com/fafhrd91/actix-net/issues/83 https://github.com/fafhrd91/actix-net/issues/83 really feels like he is playing the victim here and taking everyone for a ride, denying his own responsibility in all this drama that's unfolded. Yes a community should be open and forgiving, but blindly forgiving someone who doesn't even admit their own mistakes, who doesn't even understand what they are being forgiven for, is naive and also will result in community destruction. I also don't buy the "if you don't like it just don't use it" argument. If it's actively dangerous and you know this, and you know that other people don't know this, you do have a responsibility to (politely) inform others about it. Simplying "not using it" is plain negligence. [1] "the patch is boring", LOL WTF I would never have even come up with something this insulting even when I wanted to actively piss someone off, kudos for imaginativity
- Traster 7y ago
  > initially were very nice and tried to give the author very polite suggestions on improvement, and it was only after the author being extremely dismissive[1], not admitting to his own flaws, not wanting to learn from others, and abusing his own power in shutting down valid discussion, that things turned nasty. Yes, nice comments such as >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? and > Never write rust code again
  - infinity0 7y ago
    That was after the author was extremely dismissive with "this patch is boring". Seriously, who says that??

munmaek 7y ago

What do you use now? Warp?

deleted 7y ago
[deleted]
dbcfd 7y ago
Right now, if you want async/await, you either have warp or tide. Hopefully gotham or rocket gets around to updating.
- rudedogg 7y ago
  Can anyone comment on how close Rocket is to a 0.5 release? I’ve been wondering for awhile, but opening an issue to ask seems annoying.
  - agersant 7y ago
    I don't have any insight but you can subscribe to this issue to see how things are moving: https://github.com/SergioBenitez/Rocket/issues/1065 https://github.com/SergioBenitez/Rocket/issues/1065
  - nicoburns 7y ago
    I've been following this quite closely. Most of the work seems to be done. But development is very stop-start in fits and bursts, so it's hard to tell how much longer it will take.
- kevinastone 7y ago
  Gotham will be async-ready once this PR lands and the next release is published: https://github.com/gotham-rs/gotham/pull/370 https://github.com/gotham-rs/gotham/pull/370
  - anon463637 7y ago
    Noice. To me, Gotham makes more sense because it depends on stable, whereas Rocket uses nightly. Anything depending on nightly seems inherently more fragile and un-future-proof (no pun intended).
_-___________-_ 7y ago
We just use hyper directly, with a small amount of glue code to use serde_json, serde_urlencoded for body parsing and a very simple (and very fast) router of our own creation. This approach also made it very simple for us to introduce std-future/async-await in a gradual way.
mojzu 7y ago
I've been in the process of switching to tonic for the last few of weeks. Based on hyper/tower and has async/await support. It's a gRPC server rather than HTTP, so I've been using it with grpc-gateway to provide an HTTP OpenAPI v2 interface. It has automated quite a few things I found dull to do in other server frameworks, from the gRPC .proto file I can generate: - Rust server request/response types and request handler stubs. - grpc-gateway files and an OpenAPI v2 json spec. - Client side typescript types and request/response handlers from the OpenAPI spec. So now the process of adding a new endpoint is much less time consuming and involves writing less repetitive and error prone code. As mentioned above I've only been using it a few weeks but so far it has been great, easier to use than actix-web and felt no less responsive.

mumblemumble 7y ago

I hit a same conclusion about a popular framework (that shall remain unnamed) on a different platform a few years back. It feels like it should be simple: I disagreed with how the maintainer was doing things, so I decided the package was not for me. No need to hassle them about it. I wish it could be that simple. Instead, I had to weather a fair bit of defending my choice to use a different, less popular option, and there's apparently no honest answer I can give that won't be taken as an attack on the framework or its users. And refusing to engage with the question is, of course, rude. I'm finding that Internet culture wears me down, these days. Even when you don't go looking for flamewars, they come looking for you. With less-popular libraries, it's easier. Open an issue, say hi, make sure the maintainer knows what you're planning on doing, do it, learn a few things, have a nice day. Once or twice I've been asked to more-or-less rewrite the patch because the maintainer didn't like something about my coding style, which is also fine, and often a good way to try a different way of doing things on for size. It's all pretty benign. But popular, well-known projects have this way of getting political. I suspect that the worst thing that could possibly happen to one of my labors of love would be for lots of other people to like it, too. A few people, great. But I don't want my free time to become Internet politicized.

C14L 7y ago

Or fork the code. That's the great thing about FOSS.

sendilkumarn 7y ago
This could have solved a lot of problems...
- mratsim 7y ago
  and introduce new flamewars about "Not-Invented-Here", why don't you contribute to a common codebase, ffmpeg vs libav/avconv debacle.
  - pgeorgi 7y ago
    ffmpeg / libav had lots of bad blood long before the fork, which might have been the real driver for making it a "debacle". GitHub in particular has a "fork" button to make it super-easy. So fork, do your edits. If you want, make a pull request with the original project. If they take it, great: the fork can cease to exist. If they don't want to merge it don't take it personally but go your own merry ways. And this is what didn't happen with actix.
anon463637 7y ago
Forking if it's mature and featured enough to justify it, but it maybe too unsafe broken to invest in rewriting large swaths of code. That's the perpetual trade-off of engineering decisions; whether to build, fork or buy.

deleted 7y ago

[deleted]

strbean 7y ago

I have to question your position from a moral standpoint though. If you were a rollercoaster engineer, and you saw that a rollercoaster had an unsafe design, would you follow a similar approach? "I'm not going to ride that, but I'll let this line of people ride it without warning them." Obviously the stakes are wildly different, but still...

swayson 7y ago
That is a false equivalence, roller coasters have far more material risk given human lives are at stake.
- nindalf 7y ago
  If you had discovered Heartbleed, would you have kept that knowledge to yourself so that you could minimize the maintenance burden on the OpenSSL develoopers? Granted, no one died over Heartbleed but it caused lots of real people harm. We should start worrying about the well being of our fellow human beings long before their lives are at stake.
  - deleted 7y ago
    [deleted]
  - swayson 7y ago
    Agreed, we have a responsibility as a community to not cause harm and even take effort to prevent it. That is what I like about HN, it is a place where these things are discussed and as a collective, positive outcomes can manifest.
  - iforgotpassword 7y ago
    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?

kbenson 7y ago

Part of using any piece of software, professionally or privately, open source or commercial, is assessing how well if will meet your needs now and in the future, and possible complications you might anticipate. Doing this well and thoroughly is extremely hard, and commercial enterprises spend a lot of time and money doing so (or pay the equivalent of insurance to not worry about it). Doing a minimal amount of research entails doing what you did. Look at the current and past state of the item in question, and decide whether it's worth putting the significant amount of time and effort into using it. I can't help but feel the vast majority of people complaining failed to do this minimal amount of legwork. They're upset about their lack of forethought for what they view as a bad investment, but that's on them. Unfortunately, I find people often have a hard time accepting blame onto themselves, but feel there is blame to be assigned, and so it needs to be directed somewhere. They say don't look a gift horse in the mouth, but if you are responsible for dealing with whatever diseases that horse might introduce to your stable, or even if you are just legally obligated to deal with the care and feeding or removal on death of such a large animal, you definitely look that horse in the mouth for red flags.

deleted 7y ago
[deleted]

deleted 7y ago

[deleted]

bachmeier 7y ago

> There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code. It works both ways. You put something out there, you need to be ready for the response. I'm not a Rust user, but presumably there was a reason other than charity that he put it out there (show off his brilliance, use it to get jobs, I don't know - but it was something he did for his own benefit). If you don't like that, don't make your code available to others, and don't complain if others act in a way you don't like. There's so much posted on HN about "open source entitlement". Well, the entitlement seems to run in both directions. That's the simple the reality of the situation.

kelnos 7y ago
I don't think "entitlement" means what you think it means. Unless you're arguing that people shouldn't feel entitled to be free of harassment, in which case I don't agree with you. Yes, if you put something out there, you should expect feedback, and assume that some of that feedback is not going to be very nice. But that doesn't excuse the people giving that feedback for being rude. It doesn't excuse the fact that those people giving feedback have no inherent right to see that feedback acted upon, and expecting that is unreasonable and entitled. I'm not saying I would have acted the same way the actix developer did (in my experience as an open source maintainer I certainly have some moments I'm proud of, and others that I wish I could take back), but I'm not so quick to condemn them, either.
- bachmeier 7y ago
  Well, I'm using the dictionary definition: entitled: to furnish with proper grounds for seeking or claiming something example: this ticket entitles the bearer to free admission Being an open source maintainer doesn't mean you're entitled to recognition or praise or deference. You're not entitled to put out low-quality software and have others pretend it's awesome. You're not entitled to make claims that are false and not be called out for it. You're not even entitled to people not trashing your work. When you put your work out there because you want to be praised, that's the downside. "But that doesn't excuse the people giving that feedback for being rude." That has nothing to do with being entitled (at least not in the context of an open source project). That's basic human interaction.

p1esk 7y ago

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?

mumblemumble 7y ago
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 implies that the author of the code has a tendency to play fast and loose in a way that you might not want to welcome into your own codebase if you don't have to. Where unsafe is supposed to be treated as a sort of pinky swear that says, "The compiler couldn't guarantee that this is safe, so I did," that starts to get scary, because any errors will undercut the safety guarantees that the compiler is supposed to be enforcing on your own code. And a large volume of unsafe code implies a large manual verification burden, and a larger volume of code that's easy to accidentally break. And the more of it that should be manually verified there is, the lower the chances that it is actually being manually verified. So it threatens to defeat the ostensible purpose of choosing a language like Rust in the first place. That's not to say that programming Rust that way is wrong or evil in any objective sense. But it's something that needs to play into a decision on whether to take a dependency on such code. When you link code, you're inviting it into your process space, and you now have to accept responsibility for anything it does while it's in there.
- p1esk 7y ago
  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 solves their problem. Seemed like the software was rejected on wrong grounds.

kragen 7y ago

> There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code. Also, you can change your copy of it to work the way you want, and if you decide to share it, other people can choose to use your version if they like it better. You don't have to bully other people to get your needs meet, individually or collectively. These are among the core benefits of open source. Probably in this case most people would have ended up using the less-unsafe fork of the project, and the original author would have tried harder to extract the potential performance benefits of his more-unsafe version, while both groups constantly learned from one another. Everyone would have benefited. I've written a bit about the history of some such friendly forks at https://news.ycombinator.com/item?id=22080672 https://news.ycombinator.com/item?id=22080672

tus88 7y ago
I wonder if authors consider "friendly" forks to be friendly ...
- catalogia 7y ago
  I think that probably depends on the nature of the words exchanged before the fork. Many forks happen after nasty comments have been thrown around.
- kragen 7y ago
  The XEmacs fork I mentioned had some bad feelings attached. As far as I know the other examples I mentioned (Stackless, swap-to-NFS, LuaJIT) don't. But it doesn't matter what authors think. What matters is what helps the users. Would you ask for Newton's approval before calculating a planetary trajectory, or Kalashnikov’s before designing an automatic rifle? Their achievements matter precisely because they empower everyone, for better or for worse. Emphasizing authors’ feelings in this way has the effect of diminishing their software from a contribution to the intellectual heritage of humanity to merely a service like delivering a pizza. Don't forget to tip your waiter! Of course you should be nice to authors if you interact with them. But the whole point of open source is that you don't have to interact with them unless you want to.

dunkelheit 7y ago

This is the standard voice vs. exit dilemma. Rust community is, for better or worse, very worried about "fracturing the ecosystem" so they generally prefer voice. Well, some of these voices can get ugly.

namibj 7y ago

I'm curious what you'd recommend instead for async pgsql requirements as a Rust web framework. Actix seemed interesting, but I didn't know about the masses of unsafe. These too eliminate it, because it'd be able to crash/break a cluster that uses deliberate unsoundness for its serialization/deserialization needs in the vain of speed (timely-dataflow), allowing memory issues to spread (at least in theory)... I thus can't use a framework that uses this much unsafs/has known stray pointers or similar bugd/issues.

_-___________-_ 7y ago
We use tokio-postgres. Previously we had our own connection pool implementation, but we recently switched to deadpool.
- namibj 7y ago
  Thanks! The pipelining is just really important to get proper performance out of CockroachDB (mostly due to network and coordination overhead due to it's cluster architecture).

infinity0 7y ago

I don't like contempt culture either but there's a balance to be made here - if you let everyone do everything and encourage them all as special snowflakes that can't create anything crappy, a community will also go to shit. In this case it does sound like people initially were very nice and tried to give the author very polite suggestions on improvement, and it was only after the author being extremely dismissive[1], not admitting to his own flaws, not wanting to learn from others, and abusing his own power in shutting down valid discussion, that things turned nasty. The fact that the author deleted many of the linked issues e.g. https://github.com/fafhrd91/actix-net/issues/83 https://github.com/fafhrd91/actix-net/issues/83 really feels like he is playing the victim here and taking everyone for a ride, denying his own responsibility in all this drama that's unfolded. Yes a community should be open and forgiving, but blindly forgiving someone who doesn't even admit their own mistakes, who doesn't even understand what they are being forgiven for, is naive and also will result in community destruction. I also don't buy the "if you don't like it just don't use it" argument. If it's actively dangerous and you know this, and you know that other people don't know this, you do have a responsibility to (politely) inform others about it. Simplying "not using it" is plain negligence. [1] "the patch is boring", LOL WTF I would never have even come up with something this insulting even when I wanted to actively piss someone off, kudos for imaginativity

Traster 7y ago
> initially were very nice and tried to give the author very polite suggestions on improvement, and it was only after the author being extremely dismissive[1], not admitting to his own flaws, not wanting to learn from others, and abusing his own power in shutting down valid discussion, that things turned nasty. Yes, nice comments such as >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? and > Never write rust code again
- infinity0 7y ago
  That was after the author was extremely dismissive with "this patch is boring". Seriously, who says that??