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.
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.
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.
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 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
> 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 that still doesn't justify harassment. If that person said any of these things to the maintainer on HN, the mods would shut them down and for good reason.
> 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.
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.
Actually I agree, I wasn't trying to emphasize their feelings as much as question if there is really such a thing as a friendly fork. In reality it shouldn't matter and the concept be void, if someone forks your project and it is successful you should be glad you don't have to anymore and can do something else, as well as benefit from the improved software.
If you like what they added, you can merge it into your version unless they chose an incompatible license for their work. (That's one reason the GPL is so important: it prevents such incompatible licensing.) So if the forks continue unmerged, it likely signals some kind of difference of opinion: perhaps over technical quality, perhaps over tradeoffs, perhaps over licensing. The humans frequently turn such differences of opinion into chimpanzee factional dominance games similar to football, but in principle there is no need for that. I don't know of any LuaJIT users denigrating the hygiene and ancestry of PUC-Lua users, for example, nor vice versa, but surely it has happened on one occasion or another.
Fighting over "who gets to donate their time for free" is absurd. Unless you are one of those pretend open source companies that sell commercial versions and prevents certain cloud based usage.
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.
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.
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.
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.
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).
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.
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.
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).
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.
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.
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.
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.
It is actually easier to introduce an undefined behavior in unsafe rust than in C, since rust use the guarantee that two mutable references living that the same time cannot aliase to optimize code.
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...
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.
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?
The linked article specifically mentions that a specific soundness issue had been found and a fix had been submitted as well. If they had done nothing, it would have attracted no comment. If they had allowed another maintainer to review and merge, it would have attracted no comment. But they went out of their way to denigrate the people who called attention to this issue, called the issue "boring", rejected the patch, then deleted the issue and all comments.
> Every time I stumble upon shitty open source code, am I supposed to fix it?
Your tone suggests that you don't want any part of this, so you continue along that path. I'm not going to convince you to start caring about your fellow men and women.
> But they went out of their way to denigrate the people who called attention to this issue, called the issue "boring", rejected the patch, then deleted the issue and all comments.
This is an unfair characterization of what happened. Here's another version: The maintainer did not denigrate anyone, he did call the patch "boring" (which isn't really an insult or anything?), worked on his own patch (without closing the previous PR mind you). People immediately starting shitting on the maintainer - within the hour - because the PR had not been merged. Maintainer chose to delete the issue to avoid it devolving into the usual mess. More shitting contest happened here on HN, on Reddit, and elsewhere.
I would like to believe you. But without access to the actual issue in question, I have no reason to trust your account of the events over nindalf's account of the events.
To me, deleting the issue instead of disabling comments or making read-only suggests mens rea on the maintainer that their actions were out of line and regrettable, and don't suggest an effort to de-escalate the situation.
> The linked article specifically mentions that a specific soundness issue had been found and a fix had been submitted as well.
True, but I (and I think the other comments) referred to the top level comment here, which is a guy who just felt the code was smelly and avoided it, without having discovered anything specific.
> Your tone suggests that you don't want any part of this, so you continue along that path.
Been there, done that. The amount of excuses and other bullshit is not worth my time and effort. If the project is on github I still do open issues providing repro or at least a stack trace if possible. But if you have your own bug tracker where I'd need to sign up first (most likely going through email verification) you've lost me. Same for when you start requesting I do a git bisect even though I provided steps to reproduce or start giving excuses for why this isn't an actual bug and I'm holding it wrong. I'll just stop replying immediately.
Yes, and you're making the same mistake that you're railing against: if you're going to invoke some sort of moral imperative to do something, you have to examine the risk of what can happen if you do nothing. In the case of something like Heartbleed, yes, the consequences of silence could be quite high. But I just can't see the same argument against remaining silent for this web framework.
It's also a matter of degree and thoroughness. There's a huge difference between "I've found a specific exploitable vulnerability in this security library and here is a proof-of-concept exploit", and "after a cursory look, I see this rust code uses a lot of `unsafe` and I'm uncomfortable with that".
There were specific issues found in this library. Soundness holes as a result of unsafe. And people submitted fixes. This person could literally have done nothing and it would have been ok. But they went out of their way to be terrible to everyone.
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.
This point pretty much invalidates your argument. When making a moral decision like this, determining the stakes and the consequences of remaining silent is a critical part of the moral evaluation.
In the case of the rollercoaster, silence could have deadly consequences for the riders. Not so much for the code. (Sure it's possible that someone might use it in a life-critical situation, and it could fail in a way that would cause loss of life, but assuming from the outset that this is a strong possibility is quite the stretch.)
Failures of Actix will be “ergotic”; individuals experiencing the failure will be able to play again, experiencing the long-term average failure rate.
Failures of a roller-coaster are “non-ergotic”; individuals never experience the long-term average failure rate, since they’re, you know, dead...
This has got to be the most common and tragic type of mis-application of statistics I’m aware of; I know I used to do it all the time! Virtually nobody teaches/talks about it, but it is arguably more critical to understand than “causation vs. correlation”, or “post hoc ergo propter hoc”.
> 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.
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.
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.
We all have to ask ourself which shape we want to give our feedback. You can factually say the same as the other guy, but send a very different message.
When you critizise someone for using unsafe blocks, there are many ways how you could go about this. This argument here is not about whether we are allowed to point out unsafe code blocks, it is about how we do it.
It is a tangible difference if your message is: "You are using unsafe there and it is not really needed, let me help" or rather: "You are using unsafe there without any reason, you idiot. Go away and never come back!"
And the thing is: only one of these messages will get you closer to safe code.
> 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.
That's fine and all but you are entitled to control your own repo, its issues, pull requests, and related fora. You are entitled to set the acceptable standard of communications and if you don't like the way someone is communicating you are entitled to shutting that off.
See, entitlement works both ways: as a maintainer you're not entitled to a lot of things, but as users others are also not entitled to lots of things.
> But that doesn't excuse the people giving that feedback for being rude.
From what I can tell reading the salvaged conversations, that feedback wasn't rude (IMO) up until the maintainer called the outside patch "boring" (which, IMO, was rude). Even after that, the "rudeness" was pretty mild.
The entirety of this drama seems to have been self-inflicted. Blaming "reddit" for the author/maintainer being unable to handle criticism or PRs doesn't exactly change that.
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.