
A Sad Day for Rust - pjmlp
https://words.steveklabnik.com/a-sad-day-for-rust
======
dang
The earlier related thread is
[https://news.ycombinator.com/item?id=22073908](https://news.ycombinator.com/item?id=22073908).

------
_-___________-_
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
What do you use now? Warp?

~~~
dbcfd
Right now, if you want async/await, you either have warp or tide.

Hopefully gotham or rocket gets around to updating.

~~~
rudedogg
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
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)

------
vunie
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 do neither, but don't be surprised when people call you
out on it.

~~~
manish_gill
> 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 entitlement looks like.

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

That is completely beside the point. Do the Debian maintainers that were
responsible for famous security slipups regarding SSH keys got paid? No. Would
the backlash if they had been unwilling to fix the issues been warranted?
Absolutely.

Once you are a part of people's infrastructure and these people rely on you to
not be irresponsible, you can't afford to play the but-I-dont-get-paid-card.
You can resign gracefully and let other people take over. If you put up a
tantrum, you probably get your reputation burnt faster than a Google project
gets when they suddenly pull the plug.

Open source is not some backyard game anymore. It involves companies and their
commitment in form of infrastructure and participation.

Open source is like capitalism. But a project's success is measured in
commitment instead of capital.

~~~
Uehreka
I’d argue that if a company has a larger than normal dependency on keeping a
project running (like a cloud provider with 1 million VMs running Debian or
Debian-based OSes) they should hire a full time employee whose sole job is to
work on it.

I think the basic rules still apply: You’re getting this software for free
rather than paying for something expensive. Though you deal in the software,
you get no guarantee of its fitness for any purpose. If you want a better
guarantee of its fitness, either pay the current maintainers or hire someone
good who can become a maintainer. OR choose open source projects where a BigCo
like Microsoft or Google has hired people to work on it full time.

~~~
AnonymousPlanet
> You’re getting this software for free rather than paying for something
> expensive.

So open source is free as in beer, not free as in speech after all. And the
reason a company might choose to use open source is solely because it's free,
not because they can see the source code or alter it? Because _that_ is why
companies are in it, not because they were cheap for the small cash of a paid
version. And they're in it because they can watch and choose those projects
that are well maintained.

If the maintainer pulls a tantrum and acts unreliable that kills the project
from the point of view of any serious user. Until someone else takes over
maintenance or it is forked.

This "it's free so you get what you paid for, and if it's shit don't complain
because it was free" really rubs me the wrong way. It's a very capitalist
mindset that measures everything in money. If there is no money, there is
probably no worth, so don't expect any. Accomplishment, dependability,
positive net effect? No money, so don't expect it?

~~~
Uehreka
> This "it's free so you get what you paid for, and if it's shit don't
> complain because it was free" really rubs me the wrong way. It's a very
> capitalist mindset that measures everything in money.

I mean like... yeah.

If I'm maintaining an open source project as a side gig or for fun, I might be
able to review and merge some patches. But if the corporations that use my
project submit a busload of PRs (or worse, just issues with no solutions) and
I end up spending so much time on them that I have no time to work on my
dayjob and make rent... that's not gonna work.

Now if those corporations each chuck a hundred bucks a month (less than the
cost of a single Developer's Enterprise MSDN subscription) my way, then sure!
I'll scale back my freelance web dev work and spend half my workweek dedicated
to maintaining this project!

So yeah, I think the corporations who make money off open source projects
should be kicking back a bit of money to those projects if they want an
expectation of reliability. It doesn't have to be a ton of money either:

\- If we're talking about a tiny header parsing library that needs occasional
security patches, maybe expense a few bucks at the maintainer's Patreon so
they can spend 10 hours a year on those patches.

\- If we're talking about the web framework that underlies your big
newspaper's CMS, maybe have a developer spend 20 hours a month pushing well
made PRs to fix the problems you care about.

\- If we're talking about an OS like Debian and you're AWS, maybe hire a 3
person team to work solely on keeping it secure.

~~~
AnonymousPlanet
What rubs me the wrong way is the notion that if it's for free it has no
worth. This "free == shit" idea that is expressed in "you can use it but don't
expect much of it because it's free". Maybe I'm just too much of an old school
open source idealist.

------
trunnell
This seems to be a case of mismatched expectations.

Many want Rust to save us from our current nightmare hellscape of
vulnerability-ridden foundations.

So actix-web comes along-- a Rust web framework that is faster than everything
else including the C and C++ frameworks-- and people are filled with hope.
It's fast _and safe,_ right?

But the actix-web maintainer says he built actix-web just for fun and to see
how high he could get in the TechEmpower benchmarks. So he took license to use
a lot of unsafe Rust code to improve speed. He apparently was not trying to
make the world's best web framework, one that is safe and fast. Just one that
is fast. Oops, expectations busted.

Everyone is to blame. No one should believe that all Rust code is perfectly
safe, and we need better ways to know which Rust crates are trustworthy. And
the actix-web maintainer could have taken more responsibility for setting
people's expectations that the project prioritized speed above security.

I love the Rust Book by Steve Klabnik and Carol Nichols. But I think Steve is
off base in this post when he implies that Davidoff is wrong about unsafe code
increasing a library's security risk. Of course unsafe poses a risk. Of course
it's legit to avoid libraries with lots of unsafe code, especially
_unnecessary_ unsafe code. Actix-web was taking a lot of risk, more than
people expected.

~~~
travisgriggs
I am not a Rust guy (yet?). Are safe and super fast mutually exclusive? As I
reas the article I sensed your explanation was probably the case. Did the many
safety-making patches cause the performance to go down?

~~~
twic
Not so much mutually exclusive as "safe, fast, easy, pick two", at least
sometimes. It can take a lot of design effort to come up with a safe _and_
efficient way to do some things, so it's often tempting to do something unsafe
and efficient and hope it works out.

------
joeblau
I want to give a heads up to everyone who runs, or is thinking about running
an open source project. If your project sees _ANY_ notoriety and you are the
maintainer, you will quickly find yourself in this situation. In 2013, I
started a little side open source project and put it on GitHub which now has
5.2k stars. I've seen tons of arguments in my PR's over the previous 7 years.
My project isn't even _that_ large and I've seen lots of in fighting to the
point where I've had to lock threads. The skills required for you to run a
successful open spruce project are the same skills required for you to run a
business. You're going to need people skills and understand how to de-escalate
situations because once the community is large enough, there will be a lot of
culture conflicts. The main challenge with open source is that if you're not
getting actively incentivized (Paid for me) to maintain something that's super
popular, it's easy to abandon it when things get hard.

~~~
roca
It must depend on the project in ways I don't understand. Certainly while
working on Firefox I saw tons of toxic behavior from users, and sometimes
potential contributors. I've seen it in lots of other projects that I haven't
worked on. But for rr (4.7K Github stars) I have seen none whatsoever. I wish
I could explain the difference, but I can't.

~~~
kragen
rr is only useful to people with a minimal level of knowledge, and in most
cases to people who have stood in your shoes. Firefox is useful to any six-
year-old with a cellphone. Maybe that explains the difference.

~~~
roca
That could explain the difference between rr and Firefox, but it doesn't
explain the difference between rr and all the other developer-oriented
projects with toxicity issues.

~~~
maccam94
There's variance in developer experience and skill as well. The software's
purpose functions as an audience filter. There are still probably toxic people
out there using your software, but not as many so they're less likely to
bother you.

From what I've read about rr, it sounds like awesome black magic, and I'd
imagine most users appreciate how difficult its task is.

------
CoffeeDregs
While I much appreciate Steve's work on Rust, this does seem a little high on
drama and low on substance. Rust really does seem to be a nice language and
here for the long haul so bumps in the road are opportunities for improvement
rather than moments to sow seeds of doubt. From the link _title_ , I thought
that someone had _died_ or that Rust was fundamentally broken, but:

\- The internet will be the internet and that's, unfortunately, here to stay.

\- Being a maintainer can be a _less than_ thankless job and that's a bummer
but also a fact.

\- Reddit can be toxic, news at 11.

I had assumed that 'unsafe' was a rarely used aspect of the language (as it is
in Haskell and as duck-punching is in Python). It seems necessary (to me). It
_might_ be used more often than it should be? Hmm. Okay a little unsafe-
coverage tool should allow for quick assessment. Of course, FFI libraries will
be heavy on unsafe but use them at your own risk...

All successful software projects pass through previously-small-problem-
becomes-big-problem stages ("Argh. Looks like it's time to move from Pivotal
to JIRA..."). I don't find Steve's melodramatic response to an opportunity to
"level-up" to be particularly helpful.

I do think it'd be great to have an unsafeness analyzer (if there isn't one
already) and to expose those values in cargo.rs. And to follow other safeness-
flag recommendations in this discussion. Were those in-place or in-flight,
most of TFA would have been "the internet has driven away the maintainer of a
good project and that's not good".

------
gmaster1440
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 sense of security or acceptance. Just think about the numerous
issues that plagued the Node community around NPM packages with large amounts
of downloads and GitHub stars that turned out to be problematic.

For me the deeper insight here is that we all sort of want our cake and eat it
too. Project maintainers/owners want the freedom and enjoyment of working in
open source building fun and useful things without any explicit commitments,
and that's fair and understandable especially without any formal compensation.
And the users want to be able to have access to a growing collection of
projects without having much skin in the game, i.e. paying for it.

This isn't a problem with people, this is a problem innate to open source, and
the double-edged sword that it is.

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

~~~
gmaster1440
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.

------
dashwav
I can see where Steve is coming from about the difficulties of maintainer-ship
- I only have a few projects that I am actively maintaining and obviously
nothing close to the scale of a popular library. But at the same time I really
think almost all of the blame in this case rests solely with the reception (or
lack thereof entirely) of PRs/issues that are intending to improve the quality
of a library that many people have come to rely on.

Our entire ecosystem that we have built (for better or for worse) by using
these libraries as the foundations for countless projects necessitates that
when a community is willing to give their time to improve a library that you
maintain, the minimum that is to be expected is that you treat sincere
contributions respectfully and not dismiss them out of hand.

It's unfortunate that the maintainer has stepped down entirely instead of
changing how they are interacting with the community, but purely from a
security standpoint I would rather a slower (but more secure and receptive)
library take it's place than have a very popular library maintained by someone
who doesn't seem to care about the overall code quality of the library they
are a steward of.

~~~
lifthrasiir
The problem is that people didn't choose Actix only for performance. I
personally haven't used Actix, but it seems that all other contenders were
lacking in some way, not only performance but also feature sets and
flexibility and easiness. And thus we are now left with a horde of safe but
otherwise lacking libraries instead of what could possibly be the best of
breeds.

~~~
dashwav
That's entirely fair - and I wasn't saying that choosing actix was a bad
choice at the time for the users - but I also think that the people who were
willing to contribute to Actix to make it safer are probably also the type of
people who are willing to contribute to those other libraries to make them
more useful.

If there is one trend that has been consistent in the development world it has
been that there are always people willing to keep iterating on libraries to
get better and better implementations.

------
Klonoar
I love Rust and use it daily.

Unsafe isn’t something you live without, you just avoid unless there’s a
decent reason. Setting aside actix-web, the community has this really annoying
obsession with not using unsafe anywhere. You’re not replacing decades of
computing overnight, though, and it’s not the end of the world if it’s there
sometimes.

It often feels like newcomers and zealots preaching the unsafe issue, too. I
have to wonder if the Rust docs couldn’t better point out “the goal is less
unsafes, but unsafes will exist - this is fine”. I know it kind of explains
this already, but perhaps being more blunt?

Actix-web even with a few unsafe is still more sound than most frameworks IMO.
I’ll take slightly better with crazy good performance over not better at all
with no guarantees.

Also, look, the other problem is Reddit: I’m starting to think larger projects
should squat their name there and redirect to better discussion places. I
comment on Reddit sometimes and I roll my eyes every time I’ve done it lately.

End rant, I guess.

~~~
plopz
You can't squat and redirect subreddits to external sites. I have personally
been granted mod of a subreddit that had been redirecting to another website.
Its against the rules and the subreddit will be banned at which point anyone
can use /r/redditrequest to take it over.

Even if that did work however, people would create adjacent subreddits that
would end up to be defacto sureddit, for example /r/competitiveoverwatch.

~~~
Klonoar
I’ll defer to you on this, but I definitely know I’ve come across subs where
this has been happening for years and they’re not shut down.

~~~
plopz
Its completely possible that nobody has reported those subreddits to the
admins.

------
pdkl95
> there’s this style of response

This type of reprehensible response will keep happening until society finally
learns how the internet fundamentally changed the nature of _fame_. The best
explanation of the problem is the video "This Is Phil Fish"[1] by Innuendo
Studios. If you haven't seen it, _please_ watch it. It's not about Phil Fish;
he is simply a useful example of how fame works on the internet. _Please_
watch the video!

The core problem is that fame used to be _opt-in_. Becoming famous required
infrastructure. Gaining access to that infrastructure required the permission
various gatekeepers, time, and resources. You had to work to become famous,
because media access was a scarce resource.

On the internet fame became something that _happens to you_ , because the
internet _IS_ media access. We're used to seeing fame as something that was
_chosen_ ; if you didn't want to be famous, you could walk away from the media
infrastructure and go back to your "normal life". The famous band could quit
touring. Now that everyone has media access, that "normal life" can become
famous directly. When that happens, walking away from fame means _walking away
from your normal life_.

[1] [https://www.youtube.com/watch?v=PmTUW-
owa2w](https://www.youtube.com/watch?v=PmTUW-owa2w)

------
mtalantikite
A few years back I started using Rust after spending many years working with
Go full-time and the first thing I noticed was that the team really focused on
only providing the language, that libraries like HTTP were being pushed out to
the community to contribute. It's a totally fair position for a language to
take, but I found it disappointing coming from Go where I knew I could just
use 'net/http' and move on to solving problems.

This is the first I've heard of this conflict in the Rust community, but
honestly it's not at all surprising. People write lots of web servers and if
you're relying on your community to provide critical libraries (http is pretty
critical in 2020) things like this are bound to happen. I really wish Rust
core could provide a standard library of tools more akin to Go as I really
enjoyed working with it when I was learning it.

~~~
steveklabnik
The language team has been focusing on providing the primitives needed for an
efficient HTTP client and server, that is, async/await. That only got
stabilized a few weeks ago. If we had put HTTP in the standard library before
then, it would have only been synchronous. That would have been a huge
drawback.

~~~
mtalantikite
Oh absolutely, you actually mentioned that to me a few years back when I was
first looking at Rust, and that’s a totally reasonable place to have been in.
It’s just unfortunate that so many people decided to depend on an external
library/framework and then got upset like this. For me it meant Rust wasn’t a
language I should use for web servers at that moment, which hopefully won’t be
the case for too much longer. I will say that as a user it’d be great to see
an officially maintained lib like ‘net/http’, even if it isn’t a part of the
std lib itself.

------
AaronFriel
This is very difficult. I feel badly for the author of actix-web, and I agree
with Klabnik to the extent that Reddit can be a terrible place.

What I think this is, is a sad day for the Rust community.

But it is probably a good, and necessary step for the Rust ecosystem. The
bottom line is the creator of Actix made something really attractive, but not
necessarily _good_ ¹, which pulled a lot of people in to using it. It did
extremely well on benchmarks, which brought Rust positive attention.

But the project was fatally flawed unless another maintainer forked it. The
author was not obligated to accept patches from anyone else, but it was and
should be unacceptable to the Rust ecosystem for the most popular web
framework to have severe vulnerabilities that can be exploited. And for the
author and maintainer to disregard patches to those issues as "boring" or
other derisive terms should also be considered unacceptable.

Perhaps that would have been the right way to fix this actix-web issue, to
produce a better project. This is basicaly what happened with cabal (package
manager for Haskell) and stack (a wrapper that made it easy to build Haskell
packages). But at the same time I can't in good conscience recommend anyone
use cabal, nor could I recommend anyone use actix-web. It may very well be for
the best that they just won't be used.

¹ - Good has lots of different connotations. Is there a lot of code? Yes. Is
it largely well written? I think so, based on what I've heard. But in the long
term having a benevolent dictator for life controlling a major piece of the
Rust ecosystem is extremely dependent on them being _benevolent_ , and
rejecting critical security fixes and declining to engage the community in any
meaningful way is not this. On the other hand, I think projects like async-std
and tokio have a much more benevolent (and less dictatorial) leadership.

~~~
whateveracct
Not the point of this thread, but cabal is quite good now with its Nix-style
local builds. The meme of "cabal is bad" perpetuated during the rise of stack
is just wrong now :)

------
spamizbad
Question: why didn’t the more safety-focused developers just fork the project?
I feel like fork-o-phobia causes 90% of the incidents like this.

~~~
steveklabnik
Forking is _extremely_ aggressive, and just because someone has the time to
write a patch doesn't mean they have the desire or time to run a project.

~~~
sequoia
> Forking is extremely aggressive

This is not so. If you said "forking can be perceived as an aggressive
action"* I would not disagree with you, but in the context of an FOS
ecosystem, forking _should_ not be perceived as aggressive, and it definitely
is not inherently so. If someone doesn't want anyone to fork their project,
why release it under an open source license? Free/Open source, full control:
pick one.

I object to the characterization of forking as aggressive first because it's
not, and second because it cuts off another potential avenue of redress or
action. We already agree that "shouting on twitter and reddit" is not a good
response. If you declare forking off limits or "impolite," what alternatives
are left in a case like this?

I acknowledge the complicated ecosystem impacts of forking a popular project
(I'm from the JS world where the impacts are extreme), but I don't think "let
a project stagnate or yell and shout because the maintainer has other
priorities" is a better alternative.

Forking a project in a case like this should be seen as "putting your money
where your mouth is"/"stepping up to the plate"/taking on responsibility for
change if you think a project is going in the wrong direction. Personally, I
fault bitter complainers who _don 't_ fork a project for being lazy: do you
care enough to actually do the maintainer's job, to take on that
responsibility? If no, then what gives you the right to condemn them? If yes,
great! Your problem is solved and you can maintain rather than complain.

More forks please.

* just as asking someone "where are you from?" can be _perceived_ as aggressive but that doesn't make it objectively/inherently aggressive.

~~~
steveklabnik
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.

~~~
godshatter
Why? What's the danger here? Is the original maintainer going to send someone
named Vinny to break your legs if you fork a project that won't accept a
security patch you need?

I think you should just fork it privately, apply your patch, and move on with
your life.

~~~
steveklabnik
If you're keeping it private, none of this applies. I'm talking about "hey
that project is bad, I am now maintaining a competing project, please use it
instead."

~~~
growse
Instead of framing it as "that project is objectively bad, my one is better",
why not say "my project is a fork of this project but with a bit less _unsafe_
" and then see what the community does?

Forking isn't provocative. Forking and then claiming your fork is objectively
superior is.

------
AdmiralAsshat
The larger pity, to me, seems to be the maintainer's decision to not only quit
the project, but to take down the repo with the intent to delete it:

[https://github.com/actix/actix-web](https://github.com/actix/actix-web)

I get it, they feel personally harassed and slighted. And it's their project,
they can do with it what they like. But it still feels like the decision is
motivated more by spite than by a desire to simply wash one's hand of the
project. Surely there are _not hostile_ developers who would've been willing
to take over the maintainer role.

~~~
steveklabnik
It got moved to their personal github account, not deleted.

~~~
mileycyrusXOXO
He said he is going to move it to private in his [post
mortem]([https://github.com/actix/actix-web](https://github.com/actix/actix-
web))

~~~
jimbokun
This seems to me the most relevant quote:

"(Btw thanks to everyone who provided prs and other help!)"

So the maintainer was grateful for the PRs, but worn down by all the people
complaining without contributing.

------
transect
Here's the reddit thread in question:

[https://www.reddit.com/r/rust/comments/epoloy/ive_smoketeste...](https://www.reddit.com/r/rust/comments/epoloy/ive_smoketested_rust_http_clients_heres_what_i/)

I have no doubt it led to some github issue brigading, but it's not really
that big of a deal. Ostracizing /r/rust in a mealy mouthed way probably won't
make that community better...

~~~
davedx
Yeah, I agree. “It’s all reddit’s fault” is not helpful at all and simply
wrong from reading that thread.

~~~
steveklabnik
You cannot get the full context from a single reddit thread; as I mentioned in
the post, this situation is the product of multiple events. You'd at least
need the posts from all of them, let alone that this is only one of the posts
from this situation on reddit in the last day.

~~~
jimbokun
I think that's where some of the confusion comes in.

You say:

"Some people go far, far, far over the line."

So some people are assuming this is just the maintainer responding badly to
people pointing out problems with his or her code, but you are saying it went
far beyond that into personal attacks?

~~~
steveklabnik
Yes, they did. I posted an example of a particularly egregious one elsewhere
in this thread.

~~~
jimbokun
Yeah, saw that. Criticism of code should turning into personal attacks is
never justified.

------
yingw787
This is an unfortunate, but I think necessary part of community growth. I
really don’t think it’s possible to create a large community around a language
that is business critical, and not have these kinds of setbacks where people
get worked up and hurt each other’s feelings.

Python has many of the same issues, where core devs and key maintainers go
dark or behave badly. What Python does do pretty well, and what I like about
it, is placing its core user front and center. For Python, that is the
beginning programmer, and Python has a lot of empathy for him or her. What I
also like about Python is a general willingness to have difficult
conversations and back rebuttals with code snippets.

I read difficult conversations by Bruce Patton a while back, and it wasn’t an
easy read for me because I have problems of responding sometimes in a
constructive manner, but I learned a lot and I would highly recommend it .

I’m confident the Rust community will survive this and come out stronger than
ever :)

~~~
scoutt
Yes, but I wonder how many of those 50K users are "business critical" and how
many are there just for trolling, gossip and drama.

------
epage
This is a sad day for Rust. Situations can spiral out of control. Who started
it? Who escalated it? You can't really define these because communication is
sloppy and difficult, especially when there are cultural and language barriers
involved. The only way to not get these situations to spiral out of control
are a thick skin, forgiveness, and assuming noble intent.

There have been times on here where I see discussions around `unsafe` as if it
was a curse. I think the discussions, over time, have gotten more nuanced
which helps.

I also wonder if expectations were unclear. It now sounds like the focus of
Actix was on performance and creativity / cleverness and not on being a mature
product. I never heard that before. Maybe even the author didn't even
originally articulate it so clearly but discovered it through these
discussions.

Going forward, I hope someone archives their clones of actix and that people
fork that and get it moving forward as a product. I hope people don't take a
religious view of removing `unsafe` during the fork but instead follow best
practices (benchmark to confirm the need, abstract it to test it, offer a
feature flag for the paranoid to disable as much of it as possible).

~~~
ncmncm
No, it's a happy day. This won't be the last such event. People who care will
learn to keep track of details they care about, and certify -- and de-certify
-- without drama. Not all modules are right for use everywhere, but all are
right for use somewhere, including those only trusted for personal projects.

Some of the latter will be forked, and the forks certified to higher levels,
and those forked again and the forks certified or de-certified again.

This marks a step on the way to maturity, right on schedule. By the evidence,
in ten years Rust will be a mature language, much more quickly than some. Most
don't get there.

------
PragmaticPulp
I really want to like Rust. Every time I try to use Rust on a project, I end
up down a rabbit hole of internet arguments and unnecessary drama. When I
finally give up on Rust, I find I can accomplish the same task in a fraction
of the time with a more mature language. At this point, I think Rust is best
reserved for very narrow use cases that can be shown to fit neatly within
Rust's current ecosystem before coding begins.

Rust is a macrocosm of a phenomenon I've noticed in my own career: My
productivity is inversely proportional to how dogmatically "correct" I'm
trying to be with my implementation. The Rust community embodies many of the
negative aspects of perfectionism that tend to stall real world progress. That
perfectionism doesn't necessarily carry over to your code, but I find myself
wondering if I'm doing things "the right way" far more in Rust than other
languages.

Some growing pains are normal for any community. I really hope the Rust
community can settle into a healthy environment. Until then, I'll reserve Rust
for only smaller projects where I can afford to bail and rewrite in another
language if it starts to spiral in complexity.

------
honkycat
I love Neil Gaiman's "Entitlement Issues".

To sum it up: "George R.R. Martin is not your bitch."

I would carry this even further: "Open source maintainers are not your bitch."

I see a lot of whining and entitlement from engineers on open source repo
issues pages. Open a pull request, fork it and host it yourself, and just
relax in general.

Not to say maintainers can't be jerks. But again: That is their choice. They
are not your bitch.

------
CoffeePython
Tried reading through this but without context it’s very unclear what has
happened.

Can someone familiar with Rust and it’s communities explain from a high level
what all this is about?

~~~
jerf
The really short answer seems to be: actix was a Rust web framework. It did
some things internally that some people didn't like. The Internet echo chamber
picked that up and amplified it to a volume the maintainer couldn't justify
working through. The Internet echo chamber is now going to pick this up and
amplify it to a volume that probably isn't justified either.

I think this is another story about the destructive power of the internet echo
chamber, where the asymmetry of one person vs. a mob of people who are in
reality probably not _all_ that engaged with the problem but nevertheless have
enough engagement to send a nastygram or two creates a distributed denial of
decorum attack that no single human being should be expected to deal with
"nicely". Our ancient instinctive tribal signals of whether or not you are
approved by the tribe, tuned for tribes of 150 people or so, receive a message
that 15,000% of the tribe thinks you are a bad person, and our natural human
response to that is a lot of stress at best (our ancient instincts tell us
that eviction from the tribe is a _bad thing_ , even though in practical terms
eviction from this particular tribe won't be much of a problem at all in the
modern world).

(I phrase it this way because I think this is, well, not strictly speaking
_independent_ of the question of whether or not the maintainer was guilty or
innocent of any particular thing, but because the story is the wild
disproportionality of the response you can get on the Internet regardless.)

~~~
patrickmay
"Denial of decorum attack" is a great description that deserves broader
visibility. It's also a pithy summary of Twitter.

------
ddevault
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 anything
in the slightest. Your dependencies are your responsibility. Responding with
vitrol, anger, or hate when failing to uphold this responsibility bites you in
the ass is just being a jerk.

User entitlement is totally unjustified and will burn out maintainers faster
than almost anything else. I don't stand for it. If any other maintainers out
there are struggling with this, please send me an email: sir@cmpwn.com. I'm
sympathetic to your cause and I can likely lend some pertinent advice.

~~~
dbcfd
> 1\. YOU are responsible for your dependencies.

They not only created issues, they also created patches. That is taking
responsibility. They were contributing time and expertise back.

Having a project maintainer then call those patches boring or otherwise
disregard them? That's childish. He showed time and time again he would
respond without civility when an issue was demonstrated in his code.

Sadly, that led to some comments by people frustrated with the project, since
they had likely invested considerable time at least using, if not more. But
this was a situation that is entirely avoidable if Nikolay would have stopped
promoting Actix as for production use.

~~~
meesles
> Having a project maintainer then call those patches boring or otherwise
> disregard them? That's childish

So what? Along the same lines, it's not a maintainer's responsibility to
follow best-practices, respond to feedback/PRs, or respond in any coherent way
to anything asked of them. The fact that you call them childish for not acting
they way you want them to makes me think you are the childish one.

With those PRs written, _anyone_ on the internet can apply them and use them
in their software. I agree with GP, you aren't owed anything, and that extends
to any form of social behaviors online. And let's not forget that even the
most 'perfect' maintainer still deals with shit on a regular basis from the
masses of people demanding features as if they got paid to write the free
software people are using.

This expectation of being served high-quality open-source software for free,
and then outrage when it isn't, is absolutely ridiculous and will make people
not want to maintain software.

~~~
logophobia
It was advertised as a production-ready web-framework, and it was very
popular. When do people get to complain? "Oh, my credit card information was
stolen due to memory issues in this web-service, it's fine though, we didn't
pay the guy, so we can't blame him.". Web-frameworks are cornerstones for
security, and if you write one, advertise one, you need to care about
security. Features, code-style, ad-hoc PRs, bug-fixes: little responsibility
there, but security is something that can hurt a lot of people if done wrong.
The use-after-free bug this was about could've been exploited in the right
circumstances.

If I build a playground for free and it gets popular in my neighbourhood, and
then collapses on some poor kid, I'm still responsible, even if I did it for
free.

The way it was handled was definitely NOT productive though, the guy didn't
deserve the flames.

~~~
Turing_Machine
Holding people legally responsible for bugs in their FOSS code would be a good
way to ensure that no FOSS code got written. Ever.

~~~
rckoepke
Legally, absolutely agree with you. GP's playground analogy was a particularly
bad choice in that context.

Socially though - I don't see an issue with holding major projects socially
responsible for egregious failure to fix security flaws. Public criticism is
part of the open source model, it's the "many eyes" defense in action. Social
pressure would be appropriate if Ubuntu just said "ahh, so, a worm is stealing
every user's keystrokes. There's a fix for it but we won't merge it because
we'd rather spend our time working on PulseAudio and systemd. If users want to
use a forked version that will stop the keylogger, they are free to do so, but
we make no guarantees our future changes won't break those forks."

~~~
AstralStorm
They actually do exactly that. The only goal of Ubuntu is to provide
usability. They will care about security to an extent it does not interfere
with that goal.

Such as maintainers being overloaded fixing visible issues.

You want a security oriented distribution, you picked the wrong one.

------
Grue3
I remember when people were claiming Common Lisp community is toxic, but I
find that it is the languages which tend to focus on "building community" with
Community Managers and Codes of Conduct that end up becoming truly toxic
cesspools in the end. See also node.js. The focus on community attracts people
who aren't interested in programming, but rather those who want a playground
for gaining clout and trolling. You never hear about C++ drama, why is that?

~~~
zelly
Primates tend to attack each other out of envy when they become too similar
and all behave the same exact way. They look to find someone to crucify to get
rid of the angst built up from being too similar to the next person.

The Common Lisp community was pretty much the opposite of the Node/Rust crowd.
Everyone was different. Lots of people were using different implementations of
CL. Most people even had their own custom editors. And of course everyone had
their own DSL of macros they carried around with them, so basically everyone
had their own language. The supposed toxicity of the CL community was from the
constant arguments because they all had strong opinions different from each
other.

If this were the CL community, there would be 20 different versions of actix-
web or something like it. There would be no need to create drama and make
whiny demands of other people, because everyone in CL actually knows how to
program.

------
whatshisface
I don't think a few compiler engineers can hold themselves responsible for the
Twitter/Reddit behavior of thousands of programmers (which at this point are
selected more or less evenly from the whole population of programmers), no
matter how noble the sentiment might be.

------
bionicbits
What makes me sad is that someone spent a huge amount of time making
something, working on something, supporting something. If you don't like that
something, then use something else or write your own thing. I don't get how
there is some responsibility of maintainers to turn a passion project into
anything other than what they want?! Fork.

------
Ensorceled
I think there are three things that combine to cause the underlying problem:

1\. Open source creators own the package and they owe you nothing. Most (all?)
of the major package repositories follow this model.

2\. There are very few ways to officially fix a major dependency if the
creator(s) take a powder beyond cajoling or forking and attempting to maintain
it yourself.

3\. Many people are using VERY complex and important packages that, frankly,
they may not actually be able to maintain themselves. I fall into this
category for some packages that I use and I'm sure most people do, especially
on small projects.

So, you are left with hoping the OS creator stays on top of things or
cajoling.

Once cajoling fails, and you are in a bind, a bind that may threaten your job
and career; things get ugly. It's not right, but it's human nature and it's
predictable.

I'm identifying the problem, I really don't have a solution.

------
deckar01
There are a few project management techniques that can avoid a lot of this.
Mainly, don't submit a PR until you get a maintainer's approval on the purpose
of the issue and the plan for the implementation. Time is valuable. When I
want to convince maintainers to spend their time on my issues, I try to pitch
in a way that requires the minimal time investment from them. Ask yes or no
questions, provide multiple proposals with pros/cons, and look a past PRs that
have landed so you can replicate the qualities of an acceptable PR. A few of
these lessons were learned from successful OS projects with issue templates
that gently guide contributors. Most of them were learned the hard way by
misguided effort wasting a lot of peoples' time.

------
WalterBright
Steve, you have done a fantastic job. Don't let these issues get you down.

As an indication of that, I've been implementing an ownership/borrowing system
for D. I expect to see some of the same issues you brought up. But for the
people that want to use it correctly, it will produce the benefits. And that's
what I care about.

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

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

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

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

[https://github.com/dlang/dmd/pull/10586](https://github.com/dlang/dmd/pull/10586)

------
Waterluvian
I used to have this mental model for my (few, meager) open source projects:
"I'm making something really cool in my back yard. You can come help when I'm
home."

Eventually it's mutated into, "I'm making something really cool in the local
park. I'll be there on weekends!"

I had to bake in the perception of not "owning" my creation because yeah, at
some point it needs to grow well beyond what I had the time/energy/capability
for. I'm also very human, and very insecure about my competencies, and as the
youngest of three brothers, am defensive by nature.

Now practically speaking, how do you accomplish that in the open source
community? I wish I knew.

------
Animats
I have been complaining about Rust's "unsafe" for years. There's too much
"unsafe" code because there are things that you either can't express, or are
very hard to express, in safe Rust. I've pointed out partially initialized
arrays and backlinks as key trouble spots. Both are potentially fixable. I've
gotten back complicated excuses for not dealing with these design problems.
There was a serious denial problem in the Rust community. Now it's come back
to bite them.

Language design that forces users to lie to the language leads to this. The
classic is C's "a pointer is also an array" mindset. When you write

    
    
       int read(int fd, char* buf, size_t buflen)
    

that "char *" is a lie. You're not sending a pointer to a single character.
You're sending a reference to an array of unknown size. That design mistake in
C has probably been the cause of more serious bugs than any other mistake in
the history of programming. If you have to lie to the language, the language
is broken.

Rust had so much promise, too.

~~~
Cladode

        there are things that you either 
        can't express, or are very hard
        to express, in safe Rust.
    

This is true (and in some sense inevitable by Rice's theorem) but it is
unclear what can be done about this. Bear in mind that Rust's design
constraints are

\- decidable (indeed fast) type-inference/type-checking

\- simple typing system

\- you don't pay for features you don't use

It is easy to get rid of unsafe blocks if you throw complexity at Rust, e.g.
use dependent types and / or theorem provers, but all the obvious ways of
doing this immediately violate the constraints above. Doing it within Rust's
constraints is an open research problem.

    
    
       potentially fixable.
    

What would you use as an objective, measurable criterion that we can use to
decided whether a purposed fix is in fact a fix? If you have a concrete design
proposal that works (in particular w/o destroying Rust's fast (bidirectional)
type-inference/type-checking and the simplicity of Rust's types), and evidence
that it's widely applicable (i.e. doesn't just allow to type some trivial edge
cases of back-links and partially initialised arrays) that would easily
publishable in top PL conferences (e.g. POPL) and a working prototype would
help towards getting this into Rust.

I would be happy to help with implementing & writing up such work. I have
quite a bit of experience with sub-structural types a la Rust. I have spend
some time thinking about this problem space, but didn't manage to crack it. I
have an incoming PhD student whom I could ask to help with this.

~~~
Animats
Oh, not Rice's theorem again. That only applies to infinite systems. There are
useful decidable properties for a reasonably large set of programs. Yes,
they're "uninteresting" mathematically, but we're talking about memory safety
here. If your program is anywhere near undecidable in that area, you're doing
it wrong. Any time you're close to the edge on that, you can get decidability
with a run-time check. The Microsoft Static Verifier people have been down
that road with some success. I went there 40 years ago, with the Pascal-F
Verifier.

The question I'm asking is, what do you _really_ need to do that you can't do
in safe code. On the memory safety front, for pure Rust (no calls to C),
probably not all that much. Maybe only this:

\- Syntax for talking about partially initialized arrays. For a collection,
you have a variable that indicates how much of the array has been initialized,
and you need a statement in the language that ties that variable to a
partially initialized array. Then you can do simple inductive proofs to show
that as you initialize another element and add 1 to the counter, the entire
array is initialized. Non-consecutive initialization would require more
complex proofs. Is there a real use case for that? One with major performance
implications, where initializing the data to some null value would be too
slow?

Un-initialized blocks of types such as raw bytes aren't a problem, because
those types are "fully mapped" \- all bit combinations are valid. Only types
that are not fully mapped an initialization guarantee.

\- Backlinks. Backlinks in doubly-linked lists and trees obey some simple
invariants. You need syntax to say "this is a backlink". That implies an
invariant that if A points to B, B must point back to A. Everything which
updates A or B must preserve that invariant. The pointer from B back to A then
no longer needs to have ownership of A. (It's a problem that Rust doesn't have
"objects", because such invariants are usually required to be true when
control is outside the object, but can be broken momentarily while control is
inside it. The inside/outside distinction is important for this, and Rust is a
bit soft on that. Spec# took inside/outside seriously, but viewed it
dynamically, rather than being tied to static scope. Haven't looked at that in
years.

What else do you _really_ need? Remember that some knotty ownership problems
can be resolved by allocating the objects in an array which owns them, and
using array indices for relationships between the objects. It's not like you
have to use pointers.

Concurrency is a related issue, but I've said enough for one night.

~~~
Cladode
I'm still unclear about this, should this be done by the typing system or by
an external static verifier:

    
    
       simple inductive proofs to show 
       that as you initialize 
       another element and add 1 to 
       the counter
    

If the latter, you can already do this with Rust as it is, it's just a
question of building such a static verifier. If the former, I really doubt
that this can fit in Rust's typing system without major surgery. We know well
how to add arithmetic to typing systems, but the natural approach to doing so
(dependent types) will probably make type-checking / -inference undecidable.

------
Traster
I think one part of this problem is that people need to mind their own
business. If you're using an open source project and you find a bug then fine,
report it. Hell, maybe even do a PR for a fix. But the you're not the
maintainer's boss, they don't owe you a fix, they don't owe you anything. Now
here's where it goes wrong, it's not your business to go and call someone out
on social media. Not least because when you post on social media you should
know that you're inviting a lot of strangers who have nothing to do with your
problem to come and get angry. A decade ago maybe you could've feigned
ignorance. Not today.

Equally, if you see someone complaining on social media about something that
doesn't effect you, then mind your own business. But let's be clear - most
people can't be trusted to do that.

Social media has taught everyone that they get to have an opinion about
everything, and not just to have an opinion but to go and find the people
involved and tell them. That is a completely broken culture- and its actively
encouraged by places like reddit and twitter.

------
ridaj
It brings up the question — as a developer, how can you best set boundaries on
your customers so that you can have some degree of control over the toxicity
of the culture that you're exposed to when interacting with them?

~~~
coldpie
It's a good question. I'm involved in a large open source project that
attracts some of this kind of attention. Because of the project's age, much of
our infrastructure is old, which actually sort-of works to our advantage here.
If you want to be a jerk to us, you need to go find our mailing lists and
figure out how to send an email, or register a Bugzilla account and go file
some troll bug. Much more effort than posting "You Suck" on GitHub or
whatever. The barriers are insulating, which has pros and cons.

The other part that works well for me is disassociating your self from your
project. Set strict hours for when you will work on the project, and don't
work on it outside of them. Note that checking issue emails counts as work;
remove your "work" email from your phone. I'm lucky enough to be a paid
developer for the project, so I can clearly define my working hours as when
I'm in the office, and ignore issues when I'm not at the office. But even for
personal projects, there's no need to respond to issues within hours, or even
days, if doing so is burning you out.

And the obvious answer that applies to anyone who creates anything online:
Don't Read The Comments. In this case, that means Reddit. Reddit is a cesspool
of uninformed users giving maximum visibility to whatever is most appealing to
other uninformed users; not a good place to get useful feedback. Find spaces
that are supportive and provide useful feedback, cultivate them, and spend
your time there.

~~~
jeltz
Hm, dunno, I am tangentially involved in a big open source project which
almost never gets any negative comments, neither on Reddit nor here and the
feedback is usually useful. Yes, the project uses mailing lists for the
development, but there is almost no negativity in other parts of the
community.

I have no idea why some projects gets toxic attackers while others are almost
entirely spared. One thing which the project prioritizes is taking the time to
explain to people why their ideas which look good on paper may actually be
missguided.

------
nevi-me
1\. fafhrd91 might not be an English "native". A simple linguistic look at his
comments (esp on gitter when he answers our questions) shows that he uses very
short sentences. Perhaps that comes across as harsh to some people, but for
the most I think it was fine. Perhaps many of those who were offended took
this the wrong way (one can't keep apologising for their English).

2\. Perhaps actix focused more on TechEmpower benchmarks (if you follow
fafhrd91 on GH, you'd see the number of times he forks TE's repo, presumably
submitting PRs). I think having a library that's #1 for many benchmarks
attracts users, not all of which will be hobbyists working on toy projects.
The concerns (some valid, most not) about unsafe were bound to be there.

3\. The dismissal of `unsafe` alternatives was often a challenge (from the
comments that I saw, especially before his first instance of walking away),
which wasn't handled well by "us" the religious cult. I don't know why he came
back after the first instance last year, but what many of us saw was the
toxicity of Reddit when it came to actix. I think fafhrd91 asked for people to
co-maintain last time, which did see an increase in contributors.

4\. Part of us building a community will be many of us acknowledging that
"Performance" is not the sole goal of every Rust project. There are sometimes
people who will suggest a huge deviation in a project because of some micro-
optimisation or because they want a feature which might not make sense for
everyone else. So I hear what you're saying about the hardships of
maintainership because things can go pretty wild if one tries to please
everybody. Unsafe is also still 'young' in that more tooling around it will
still be worked on over the years/decades. How will we know if we're being
restrictive on a feature if we forbid it?

5\. Reddit is toxic. People on Reddit are toxic. People are toxic. We are
toxic.

A good principle for us to follow when we type things on the internet is to
ask "would I say everything this way to a person if I was standing next to
him/her/them"?

Good luck Nikolay, I wish you the best, we have learnt a lot from you on
what's possible in our little community.

------
_bxg1
Rust is unique in that it attracts:

\- Language theory enthusiasts, a famously pedantic group

\- Systems programmers, a famously exclusionary group

\- Unwashed masses of web developers who have never done either of the above
before

Frankly I'm amazed it's been as civil as it has been

~~~
0xdead
I wish I could upvote this many times.

------
harikb
One thing that isn't considered is that these "benchmarks" are a rat race to
the bottom in code quality. You can't blame the author(s) from wanting to win
this fictitious wall of fame. I don't know why exact numbers like "6.9987
million/sec" exist. There should be a saner way to run benchmarks, which in
turn creates sanity among developers.

This viewpoint is, of course, unrelated to the community discussion here. I
mean other languages have unsafe (or c's void *), but they don't appear to
fight about it. I don't mean to say anything bad about Rust. But it seems to
attract people who want the absolute best performance at any cost. IMHO. May
be I am wrong. That may be something Rust people can try to change??

------
arendtio
I think the simple version is that too many people don't understand how Open-
Source works and that they have no right to tell a maintainer what he has to
do.

If you are unhappy with the direction an Open-Source project is going, you can
do two things:

1\. Tell, in a civilized manner!

2\. Fork, if you are willing to spend the resources to maintain such a project
yourself

If you are unable to formulate your critique in a neutral way, then keep it to
yourself (aka STFU). If a maintainer decides he doesn't want to follow your
suggestions, you should be nice and stop. After all, you still have option
two.

And if you are unwilling to spend the resources to maintain a fork, how dare
you to tell someone who invests his time and shares his results, what he has
to do.

------
ncmncm
A necessary step on the way to Maturity. On Schedule.

Congratulations, Rust!

I mean this with no trace of irony. With maturity comes being used in ways you
didn't intend, and might not want, even with unwelcome publicity. Rust will
sail through more of these, and more, and they will cease to shock. People who
care will start to pay attention to modules' underpinnings, and start to keep
track, and certify. It takes a lot of conscientious people caring to uphold
that, but maturity brings them.

Rust is designed to a high standard, and it takes extra work and extra armor
to maintain it, just as it is worth the extra effort to learn it. It aims to
be worth that, so we cannot begrudge that without betraying its purpose.

------
dpc_pw
To start: any personal attacks against the author are unacceptable. Anyone is
free to write whatever the code in Rust they like, and it is wrong to attack
them about it.

But .... I think it is showing that the premise of memory safety in Rust is
working. Stuff that would go unnoticed in C and C++, is being identified and
called out in Rust. Does it lead to drama, personal conflicts, etc.? Maybe.
But from the perspective of the potential Rust user it's a proof that it
`unsafe` keyword works, leads to higher scrutiny of potentially dangerous
patterns and that the culture of other Rust users takes reliability, security
and safety seriously.

~~~
einpoklum
> Anyone is free to write whatever the code in Rust they like

Let's take an extreme example: I write some program for common use and
intentionally introduce a security hole or make it participate in bot-nets.
And don't tell anyone about it. Am I "free to write it because I like it"?
Well, in some sense, maybe, but it would also be something extremely
problematic for me to do. Certainly everyone would scream bloody murder when
it gets found out.

So, in a less extreme example, there's still some measure of responsibility of
mapping out what and how you've vetted, and not making false claims.

~~~
clarry
I think if you're actively deploying malware that people will run, the case is
pretty clear. And when you say "for common use", it sound like you know that
it is or intend it to be distributed and run by many people.

What's less clear is security holes (which are not malware as such) or just
"putting code out there" ("not in common use", although someone could come and
pick it up and start using it). I _would_ defend your right to write exploits
and backdoors and bots and put them on github.

Simply making a security hole is IMHO OK unless you have intent to exploit it
(or let someone who intends to exploit it know about it).

The difference, for me, is in writing versus deploying. And I'd consider it
deploying if you intentionally post malware to a public repo you know people
will run (without knowledge of having malware in it).

Contrast with building a trap (and maybe showing it to people) and stashing it
in shed, versus building a trap and priming it and putting it in the woods
where you know kids like to play. Not a watertight analogy, I guess making
traps could be illegal just like making guns is in many countries. But you get
the idea. I think you should be allowed to write malware or make combat knives
or mantraps for fun but don't put them to their respective use.

Of course, going down this line of reasoning is a rabbit hole. If you build
something on your yard (something that isn't illegal per se and has no
intention to harm anyone) and it turns out to be dangerous and someone gets
hurt, you might have to take responsibility (but it _really depends_ on a lot
of factors and would be decided on a case by case basis). I'm not sure I would
like such reasoning to be applied to FLOSS projects that come with a warranty
disclaimer and which can freely be audited by anyone who intends to use them
for real. It's not like they hurt you just because you happened to stumble
upon them.

------
coldtea
What's all this BS drama? It's the original maintainers project, his way or
the highway. Those who don't like his use of unsafe can take a hike, fork it,
write their own etc.

If the project owner just wants to use Rust as a fancier C, just for a few
niceties, and mostly code in unsafe, that's their decision to make.

------
shadowgovt
""" But the point is, while Reddit is not official, and so not linked to by
any official resources, it’s still a very large group of people, and so to
suggest it’s “not the Rust community” in some way is both true and very not
true. """

Perhaps one could call it "the unsafe Rust community." ;)

~~~
zozbot234
The word "community" comes with some troublesome implications. Just call it
"the unsafe space (and proud of it)"

------
mileycyrusXOXO
I understand maintaining open source is a lot of work and why someone might
want to call it a day - but this is probably the least professional way
someone could do it. People depend on this software. It is inconsiderate to
just move it to private instead of taking the time to hand it off to someone
else.

I'm 80% through building an API using actix-web. Time to reassess whether or
not I should start over - wonder what my client will think if I bring that one
up? I hope there is a community fork with enough momentum to keep the project
alive.

~~~
lostmyoldone
You don't get to invoke professionalism, or lack thereof in regards to some
individuals work they've made available for free.

Open source gives you access to source code to do with as you please. Storing
your own copy is a good idea if it's something critical to your endeavors. The
possibility of having to maintain anything of that nature yourself is always a
risk.

Expecting, demanding, or begging for anything except what the author
willingly, and happily takes upon themselves is exploitation, pure and simple.

If you think about it, trying to coerce an author/maintainer into doing
anything they willingly and explicitly have commited to, is no different than
employing bullying, group pressure, and other social/psycholgical manipulation
techniques to get whatever outcome others deem useful to themselves.

Yes, something as trivial as complaining about the lack of response to a
question can easily be seen as being abusive when there is no established
relationship or expectation, no quid pro quo, or similar.

Getting free access to someones work is amazing, and nobody should ever have
to face what so many maintainers have to face today in the form of
unreasonable expectations and outright bullying.

~~~
zozbot234
> You don't get to invoke professionalism, or lack thereof in regards to some
> individuals work they've made available for free.

Plenty of people do exactly that: they point to work that they've made
available for free on their GitHub as proof that they have the required skills
and attitudes for professional work. The former Actix-web maintainer also used
to do this, via their LinkedIn page. You can't have your cake and eat it too.

~~~
clarry
Linking a hobby project isn't necessarily meant to say anything about attitude
at work. At work, the expected attitude might very well be that you have to
bend over for and pamper customers and deal with no end of bullshit. Or maybe
the expectation is that you never interact with customers directly, everything
goes through customer support / sales / executives (after being checked by
legal). A hobby project, by contrast, is your kingdom, and you can reject
bullshit and/or have fun or just never respond to tickets without a patch
because it's your free time and your pet project.

If I link my stuff or show it to a prospective employer, it's meant to show
them that I can code. Nothing more. If they want to read too much into it and
dismiss me as unprofessional because they found a cat meme, Theo quote, or
link to hello.jpg, it's their loss not mine. Fuck 'em. Kinda unprofessional of
them.

------
tomxor
This all boils down to _entitlement_...

If you want a committee to answer for maintenance and philosophical debate or
whatever, then fork and form an organisation for it... if not, leave people
alone ffs, a one person authored project that got popular does not deserve
this, abandonment is the only outcome.

------
endothrowho333
> “Why Reddit is like this” is a whole other essay; I think it’s built into
> reddit’s structure itself.

Classic Eternal September.

Around 60k subscribers, the cultural identity starts degrading, as the amount
of "old guard" is outmatched by "new blood." Therefore, the old "monkey see,
monkey do" phenomenon, where new users would slowly mimic the culture of the
prevailing older users to "fit in," is replaced with new users mimicking other
new users, and the culture shifting towards the platform's identity instead of
retaining the sub's identity.

Generally, the type of person to post on Reddit frequently enough, has social
cohesion problems that may preclude him from fulfilling his social needs
through more healthy avenues, like real life. The same is true for the
majority of people that post online frequently. Usually the pyschological
profile that follows that point is one built on abrasiveness, distrust and
aggression towards authority, an inability to adopt social manners and
participate in social contract, low emotional intelligence, etc.

All of the aforementioned behaviors culminate into the toxicity and vitriol
you usually see -- and as well why it's so prevalent.

~~~
stanferder
It might not be just reddit though. The author's summary points to a volatile
combination of elements in Rust itself:

1) _[T]he Rust project saw Rust as more than just the language..._

2) _unsafe... is a really important part of Rust, but also a very dangerous
one, hence the name._

If a project is considered to be not just a project, but something closer to a
cause, people are going to defend their understanding of that cause fervently.

And introducing the language of "safe" and "unsafe" isn't just descriptive,
it's a value judgment. It has connotations of recklessness at least, and
explicit threat at worst.

People who perceive themselves to be defending a cause against danger are
going to react very strongly, much more so than people who are criticizing an
implementation choice on purely technical grounds.

~~~
cle
> And introducing the language of "safe" and "unsafe" isn't just descriptive,
> it's a value judgment. It has connotations of recklessness at least, and
> explicit threat at worst.

Is it really a value judgment? Coming from a formal PL background, I had just
assumed that the "unsafe" keyword was referring to the PL concept of "safety",
AKA "soundness", which has a specific technical definition, and not that it
was necessarily a value judgment. In that context, "unsafe" just means "the
compiler can't guarantee the behavior that it can normally guarantee".

~~~
steveklabnik
You are correct.

That doesn't mean that people will incorrectly interpret it, though.

~~~
henrikeh
Ada’s language is probably clearer and less loaded: checked and unchecked.

~~~
steveklabnik
Yeah, and interestingly, a lot of unsafe functions use "unchecked" in their
names.

The issue was that by the time this was recognized, there was too much Rust
code, and there was no clear alternative that people universally liked. This
kind of conversation is the definition of bikeshedding. I submitted an RFC and
it... didn't go well. (I think I picked "trustme" though.)

~~~
cle
I don't think it's bikeshedding. It does seem to be contributing to the
dogmatism I'm seeing from the Rust community here, and this community reaction
is a huge problem for Rust. So it matters.

~~~
steveklabnik
Bike shedding is a structural description, not a value judgement. It’s about
technical complexity, and changing a keyword is one of the most minimally
complex bits of language design.

~~~
cle
My point isn't to argue over the definition of bike shedding. If the name of
this keyword is contributing to this undesirable community outburst, then its
name matters, and discussions about its name are important. That's all I'm
saying. If that's what you originally meant, then we are on the same page :).

~~~
steveklabnik
We are on the same page, yes.

------
Maxious
Previously, in the Ruby community:
[https://blog.steveklabnik.com/posts/2011-08-19-matz-is-
nice-...](https://blog.steveklabnik.com/posts/2011-08-19-matz-is-nice-so-we-
are-nice)

~~~
steveklabnik
That situation is a little different for a number of reasons, but the broad
strokes are the same.

Sam tweeted at me recently about this situation:
[https://twitter.com/sstephenson/status/1167856878673694728](https://twitter.com/sstephenson/status/1167856878673694728)

------
bmgxyz
I think this has less to do with Rust and more to do with people using the Web
as a tool to be unkind to what they think are unhuman pixels.

Sometimes I think the Web was a mistake, and that none of us are ready for the
scale that it brings.

------
topspin
Fork. That's the answer. It's not friendly or nice or kind or whatever, but
that's the answer. Rust and its ecosystem of people and their work are not
magical; there are and will be difficult people and yes, sometimes the correct
answer is to shun them by forking the work and leaving the problem children
behind. It is impossible to avoid this when building a complete language
paradigm involving so many people.

Nikokay isn't the problem. His indifference to soundness concerns is
inevitable; Rust pragmatically doesn't preclude reckless programming and
that's a good thing except that some people will, in fact, be reckless. The
actual problem is the naive expectation that Nikokay's indifference and
recklessness can somehow be fixed by the 'community.' It clearly can't. The
'community' needs to sack up and fork stuff until it's happy with the work.

------
C14L
This is really bad. Actix Web is such an awesome framework.

Reddit has become such a toxic place since they optimized the platform to make
money.

Why don't those idiots just fork Actix Web and make a "no unsafe" version of
it? Instead of harassing the author, who has devoted so much of his time and
talent to building this great piece of software?

------
MrStonedOne
Open source frees us from the tyranny of the maintainer, but only if people
stop raging at maintainers and start forking shit, and other people stop
raging at maintainers and start voting with their feet to other forks.

Who the fuck cares if the package maintainer does or doesn't do x,y, or z.

Either make the patch, submit it, and launch your fork when it gets rejected,
or look for such forks. Anything else is just masterbation.

On another note: it seems like this entire mess was based around a bunch of
peoples inability to see that "can" != "does". The fact that it can be
vulnerable because it doesn't do something that makes being vulnerable
impossible does not in any way mean that it is in fact vulnerable.

This is like the time somebody came to our repo with a bunch of pep8 linter
warnings and treated them like high severity issues.

"good practice" != "must do".

------
ernie24
I think Github (and other services that host OS software) needs something like
"thank you box", that's just alongside Issues. Even if I am not able to
contribute to some project I use and like (mostly because I don't have enough
technical knowledge yet) very often I would like to - at least - say how much
grateful I am for what this person is doing. There is some need for positive
energy or gratitude, as we - who are happy - won't usually post an Issue
saying that we are happy, everything is working fine. It seems then that there
are only issues, and people who are angry or unhappy seem to be the loudest.
How else, we who are grateful but silent users - can help maintainers and
contributor to know that there is large or even larger amount of people who
are happy and even amazed by their work?

~~~
333c
GitHub has a donation feature, which is up to the maintainer to enable for
their project. Otherwise, it seems to me that a stream of positive comments
would get old quickly.

------
jt2190
> It’s unfortunate that a well-known project had soundness issues. It’s
> unfortunate that the maintainer wasn’t receptive to fixing them. At the same
> time, I’ve been there: being a maintainer is tough. It’s also unfortunate
> that there’s this style of response, and kind, and volume. It is true that
> the situation was dangerous. But did it have to be handled this way? You
> have to understand a lot of nuance here to even know the main points of the
> story. One version of this story that will certainly be told is “The Rust
> community says they’re nice but they will harass you if you use unsafe
> wrong.” Is that what we want? I, for one, do not. If you’re a part of Rust,
> you gotta ask yourself: are you happy with this outcome? How did your
> actions (or lack thereof) contribute to it? Could you have done something
> better?

------
NopeNotToday
IMO, the most telling point of this is when the author rejected a security
patch because it was not creative enough. He was more of an artist than an
engineer.

 _What was the patch? It was very strait forward, simple, uncreative change,
intention was just to remove unsafe not to fix existing code. I believe
software development is one of the most creative work we do, and creativity is
part of why we love software development, why it is fun. Especially if you
combine it with real world projects constraints. “creative constrains” could
be source of very interesting solutions. Being on the edge of your abilities
is super fun. So uncreative change felt boring_
[https://github.com/actix/actix-web](https://github.com/actix/actix-web)

~~~
pgeorgi
> He was more of an artist than an engineer.

Assuming this is true: What's the problem with that?

~~~
dbcfd
The project was not promoted as that for a long time. That "view" on what the
project was only came yesterday, when yet another security hole was identified
and a patch was prepared.

The impact of that patch would have likely caused actix to no longer be at the
top of the techempower benchmarks.

------
unexaminedlife
"I assumed that over time, the community would grow, and we’d encounter
problems.

Today is the first day where I say to myself, okay, has that happened?"

I think it depends on how you define community. I used to think Rust was going
to be able to go mainstream. Now I'm wondering if it isn't niche. In other
words, infrastructure needs code too, but all of the code "at the edge" (ie.
applications that interact with users) may not be the perfect place for Rust.
And I feel like that's where the majority of code will be written. So, maybe
to produce metrics on this I would start with "where is the primary activity",
and discover within that niche whether or not Rust has positive trajectory in
terms of "market share" of that category of applications.

------
btrask
If your language promises some kind of new feature (e.g. "safety") but offers
a back door you could drive a truck through (e.g. 'unsafe'), then ensuring
that back door is used appropriately and in good taste comes down to _culture
policing_ , which, as we've learned in other areas, is something the internet
does not handle well.

As the Rust community grows, how can it ensure that people use 'unsafe'
tastefully? Well, in general, it can't. But maybe Cargo could exercise some
editorial control, and delist (or flag) packages that don't follow the
"community standards". I'm not saying this would be a good idea, it's a
tradeoff. But you can't force open source volunteers to write code in a way
you like.

~~~
jpab
I would prefer to see a positive badge for "this project doesn't directly use
unsafe" or similar, which maintainers can choose to put in their README in the
same way that they currently put build-status, test-status and other badges.
The actual badge state is produced by tooling (a CI system) so it stays up to
date and you can follow a link to a (tooling generated) report with more info,
so it's relatively easy to verify.

Maintainers that don't care don't have to use the badge (even if their project
does in fact avoid unsafe), but the choice to include the badge acts as an
implicit signal of intent. When I see a crate with green CI status badges (or
in this case a green safety badge) that's a signal I can use to help judge
whether I want to depend on the crate.

No one needs to be flagged or called out if they're not interested in that
aspect of maintainership.

I think the hard part is that actual quality is a spectrum and no-unsafe-at-
all isn't necessarily the best goal for many crates. So ideally the badge
would show some more granular safety score. But scoring effectively is
difficult, and the so is correctly interpreting a heuristic score.

~~~
jpab
Oh, and apparently there is something vaguely along these lines already:

[https://github.com/rust-secure-code/safety-dance/](https://github.com/rust-
secure-code/safety-dance/)

------
shadowgovt
I haven't seen the phrase "contempt culture" before, and I want to thank Steve
for bringing it to my attention in this article.

Thanks Steve. :)

~~~
steveklabnik
You're welcome; I think it's one of the most important concepts for
programming communities to understand. Felt like a revelation when I read it,
as someone who was previously very contempt-ful and regrets it.

------
simias
For me this says more about the drawback of easy and automatic dependency
management. When I write C code, adding dependencies is often a huge pain in
the ass. You need to figure out how it's packaged, how it's build. Should I
build a custom version or just use $distro's pre-packaged version? How do I
tell my Makefile/configure/CMakeLists where to find the headers and libraries?

This is generally a bad thing. It leads to NIH, to poor portability, to
difficult integration in other dev environments etc... But it does mean that
you carefully consider every dependency that you must use. The quality of the
packaging is often an indication of the quality of the code too, a well
polished build system inspires confidence, a crappy buggy bespoke shell script
less so.

Meanwhile take this example: I've re-started working on a PlayStation emulator
a few weeks ago. I haven't reached the point where I need to display images or
output sound, it's pure algorithmic code with no I/O so far. That's 0
dependencies.

But then I wanted to add some basic logging infrastructure to be able to do
'warn!("this thing shouldn't happen")' or 'debug!("this register has value
{:x}", val")'. I could just use println! but, hey, adding dependencies is
super easy and I'll end up with more flexible and expressive code, so let's do
that instead. So I add these two lines to my Cargo.toml (note the _simple_ in
simple_logger):

    
    
        [dependencies]
        log = "0.4"
        simple_logger = "1.3.0"
    

And as easy as that I have a proper logging framework available. Amazing.
Except that when I then run `cargo build` I see the following:

    
    
        Compiling autocfg v0.1.7
        Compiling libc v0.2.66
        Compiling log v0.4.8
        Compiling lazy_static v1.4.0
        Compiling cfg-if v0.1.10
        Compiling num-traits v0.2.10
        Compiling num-integer v0.1.41
        Compiling atty v0.2.13
        Compiling time v0.1.42
        Compiling colored v1.9.0
        Compiling chrono v0.4.10
        Compiling simple_logger v1.3.0
    

That's 12 dependencies for a glorified println! implementation. Did I vet this
code? Of course not. It would be faster to just reimplement it myself. Do I
trust that somebody went to the trouble of doing it for me? Not really. I just
cross my fingers and hope for the best. It's wonderfully convenient but I'd be
very wary of trusting any security-critical project with a dependency graph
like that, and it's quite paradoxical since Rust is all about safety.

Oh and beyond that Reddit is a terrible place that manages to be the worst of
4chan and the worst of Facebook in one convenient package and should be
avoided at all costs, but we already knew that.

------
archsurface
What I see: unsafe should be used sparingly, and it turns out there is a
crowd-sourced safe-guard to ensure it. Don't cross the threshold.

Be warned: unsafe causes both bugs and anxiety - excessive use will lead to at
least one biting you.

------
duxup
Help me out here is actix-web some sort of software that is integral to Rust?

If not ... I get the idea he wasn't really welcoming of the changes but at the
same time. It's his code man.

I came from the world of networking and etc and the world of programming has a
great deal of personal preferences / hypothetical problems / "we don't do that
at my workplace" stuff pushed under the guise of technically correct ... sort
of technical bullying.

Under that sometimes there's little room for mistakes / other points of view,
other working styles, and etc... and it's really horrible.

~~~
steveklabnik
Integral? No. Used in production, by companies? Yes. Outwardly visible?
Absolutely, due to Techempower.

Rust will survive without actix, but losing it is a setback for Rust in the
web space.

~~~
war1025
If it's LGPL can't someone just put up a new fork of it and people transition
to that?

~~~
steveklabnik
It is MIT/Apache2, and yes, in theory they can.

------
girishso
Elm packages are not allowed to use JavaScript, period. I personally thought
this very restrictive and unnecessary. But after seeing this, maybe Elm/Evan
is doing it right after all.

------
fefe23
Let me point out that even if you think that this project is "not rust-y
enough" by violating basic premises of the Rust way, it would still be useful
as it outperforms all those C based project with at least as many guarantees
than the C versions.

To me the important part is that we as programmers start advertising our
intent. If the intent was to learn how Rust works, then we should write that
in the description. Instead we write things like "very fast and lightweight
framework". To many people fast and lightweight is good enough. Many other
people would also like dependability and sustainability. So please, just put a
little label on your github project.

All my open source projects, for example, are exploratory. None of them was
meant to be used in production unless you tested rigorously that it would
work, and that is on you then. There is nothing wrong with that, I think, as
long as you communicate it up front.

People are just importing open source libraries with flashy sounding
descriptions left and right, and then they find out those were unfinished and
crash all the time, or the author ignores bug reports, or will not maintain it
anymore, or thinks it's ok to switch the APIs around on you, breaking your
ability to upgrade without reworking your application.

Again, there is nothing wrong with that. Just be honest about it up front.

------
cthalupa
I generally believe people should be polite.

But when you open source a project, you are opening yourself up to criticism
and critique of your work. You are opening yourself up to that in basically
any form the internet wants to take it, and sometimes that really can be
shitty.

We have a very promising project making use of a language that has gained
popularity largely based on marketing around memory safety, and then that
project has unnecessary and flawed use of something that undermines the
messaging around rust. This is a risk for Rust - a promising and popular
project in a popular space that undermines some of the core rust messaging is
a PR problem for the language. The maintainer not being receptive to
contributions to resolve this difference is a problem. The maintainer not
being receptive to contributions that fix SECURITY ISSUES is a MAJOR problem.

Open source maintainers are, of course, volunteers. I don't think we should
hold them responsible for the fact that there are bugs in their code, or even
security flaws. People aren't perfect, and no one should be expected to be,
especially when contributing something to the open source community. But we
SHOULD hold them responsible for not fixing security issues. It's
irresponsible to release something to the public that you know puts them at
risk.

So is it fair for people to be upset in this situation? I think so. I also
think their reaction should be a polite one - but it's totally fair for people
to push someone to take responsibility for code they've introduced to the
world that has security vulnerabilities in it.

~~~
bloodorange
Exactly! Everyone should demand a full cash refund for all that they paid for
the maintenance of that piece of software.

~~~
cthalupa
This is a common snarky retort when any discussion happens with open source
software, but it doesn't add anything to the discussion.

There is a cost to using software that goes beyond money exchanging hands. The
maintainer has no legal obligation to do anything, but acting as if someone
having an issue with software having security vulnerabilities is someone being
entitled is a childish reduction of the interactions in play here, especially
when people are taking the time to write code that resolves the issue.

~~~
bloodorange
Why do you think it adds no value?

It at least makes it very clear to those who have not paid for the maintenance
that their position is silly if they make demands of the maintainer. It is his
project and he does as he pleases. Why is that difficult to see?

One could perhaps persuade him to accept a patch but like any endeavour where
you need something from another person, either you offer them something in
exchange (which they value enough) or ask nicely and see how it goes.

In either case, it might still fail. In that case, one can of course try and
do the same with _someone else_ who might be more receptive. This is possible
with free/open-source software.

What you consider a "snarky retort" is just the same thing said in a different
tone.

------
rukittenme
A word to the wise. Don't read the reddit thread around this. A lovely little
snippet:

> > it's up to you as a developer to vet your dependencies

> This is effectively impossible on an individual level, and it's something
> that absolutely needs to be a community-level effort.

Don't hire this person... Dependencies are absolutely, FULL STOP, your
responsibility. YOU are the one making the money NOT the maintainer.

------
dependenttypes
I would feel sad for the creator but after reading more about this it feels
like they were clearly acting with malicious intentions, such as removing a
bug report from months ago because someone mentioned it in an article, or
being rude to contributors.

I do not believe that anyone is entitled to free features/bugfixes/etc on foss
projects but apparently this is not what happened in this case.

------
username90
This is the reason why Rust will never go mainstream. People say "You can get
the same performance and features as C++ with unsafe!", but as happens in
every language such hacks gets ostracized by the community and therefore
basically unusable. So instead we just write our code in C++ which is unsafe
by default so nobody complains.

~~~
zozbot234
Nothing whatsoever was "ostracized" in this case. A fix was provided for code
that could cause UB in some cases, the former maintainer rejected the fix as
"boring" and denied that a problem existed. This could have happened just as
easily in C or C++ code.

------
alexandercrohde
How is this a story?

If people don't want to use an unsafe library, don't. If their patches aren't
getting merged, clone it.

If reddit is being meany-heads, don't login.

I really don't understand what the point of this post is. It's arguable
whether there's a problem, and if you take the author's point that this is a
problem, no solution is offered.

------
dgellow
The free software and open source implicit contract is that as a user you’re
free to fork and redistribute. That’s it. You cannot force others to accept
your patches, or to behave in the way you want. Just fork and create a safe-
and-community-friendly version of the project if that’s what you want.

------
anon463637
There's a tendency for masses of people to eagerly follow strongly-opinionated
people. I think such qualities are a big warning sign, especially if they're
dramatic, engage in all-or-nothing thinking, unconvinced by evidence and/or
put their ego / being "right" ahead of everything and everyone else.
Furthermore, there's a tendency for people to get emotionally-attached to
"their baby/pet" project and reject anything that doesn't fit with their
delusions of grandeur. IMHO, assertive, honest, respectful and professional
folks who lead projects tend to attract better quality contributions and
sustain development long-term than jerk dictators for life who may ragequit at
any time if they don't get their way.

------
compiler-guy
This problem wouldn't exist if the people who wanted changes were willing to
write a big enough check. If you get your code for free, you shouldn't expect
_anything_ of the person giving it to you. They have already given you more
than you are entitled to.

------
danmg
You can submit patches upstream all day long, but you can't browbeat the
maintainer into applying them if they don't really care about it. It's their
project at the end of the day.

Likewise, it's just as annoying when you submit a PR on some random thing
because you see a legitimate bug or unhandled case and the maintainer starts
demanding you do more free work for them to do 100% they way they would have
done it. Just say "thank you", accept it, and make those superficial edits.

The price point here is free. This is essentially a gift economy. Just because
some random strangers on the internet have an interest in the same few bits of
code, doesn't mean there is an obligation to do free work or twist someone's
arm.

------
TiccyRobby
The article mostly consider both side and the main point is to flourish open
source community, which is highly appreciable.

I think, as an outsider, both side had its wrongs and corrects, the author
could consider changing unsafe code and the community could be at least civil.

As a personal opinion, i can say that we have to consider the fact that the
authors of open source software are mostly doing it for hobby or fun. And if
we ever want to keep open source alive and magnificent, we should be very
civil and and at least thankful for the programmer and their time.

The only way out i see that could solve the issue was to fork the project and
do the desired changes there. I dont know why they did not do that when it got
to that point.

~~~
dbcfd
> I dont know why they did not do that when it got to that point.

I think most people kept hoping they weren't at that point, and could actually
move forward without forking.

------
brianzelip
I'm just a js dev with a whole lotta love for the web. I know enough to
respect the hell out of Rust. I'd just like to offer my best wishes to the
Rust community, and put a call for folks to be more civil on places like
reddit, etc.

In closing, here's a nice little gem from the OP author's final blog post on
his old blog[0]:

> if there’s one thing I’ve learned from writing software, it’s to blog about
> error messages.

Cheers.

[0] [http://blog.steveklabnik.com/posts/2015-07-05-ember-data--
ds...](http://blog.steveklabnik.com/posts/2015-07-05-ember-data--ds-is-not-
defined)

~~~
ssokolow
> if there’s one thing I’ve learned from writing software, it’s to blog about
> error messages.

I hope I'm not the only one who just realized that "A Sad Day for Rust" is
also an example of "[blogging] about error messages" and appreciated that
statement even more.

------
tracker1
Hopefully someone with a clone of the project can spin off a "reactix" fork.

I don't think the negativity was necessary, that said, if it wasn't a
significant impact to performance but did potentially improve safety, many of
the patches should probably have been brought in.

Personally, I've been more drawn to the likes of Rocket and Yew. The former
for the server because I really like the interfaces and usability. The latter,
I haven't done much with, but think it's pretty cool and a relatively small
starting point for a WebAssembly based UI experience, compared to say Blazor.

------
vmchale
That's my experience too, particularly lately. Reddit/HN both is and isn't the
Rust community, but everyone there is a disaster for all the reasons the wider
programming world is a disaster.

------
guelo
As a maintainer of a medium-ly popular library that I also use for work I can
say that I love getting (quality) bug reports since these are bugs I didn't
know I had. OTOH pull requests for the bugs I'm not as excited about. I wrote
my library with a strong vision for the api and how everything fits together.
Many times the pr submitter isn't aware of the vision nor has taken the time
to understand how everything fits together. I'll read and understand the
submitted code but many times I'll end up writing the fix myself.

------
sendilkumarn
It is indeed a very sad day. Personally I enjoyed being a small part of this
community and amazed how welcoming and constructive it was. But yeah as we
grow, we are bound to face this.

------
cfv
The guy has absolutely 0 obligation towards anyone. There was 0 money
exchanged, there were 0 contracts signed, he's free to take his ball home.

Hope the people who caused this are happy now.

------
lidHanteyk
Sorry to add yet another top-level thread, but my take on this is that, while
it is correct that unsafe-blocks are a central and contributing factor to this
incident, it is incorrect that languages doing what Rust does fundamentally
need unsafe-blocks. As long as Rust both has such an easy way to circumvent
the type system, and a desire to supplant C and C++ on the basis of code
quality and safety, there will be ready fuel and kindling for these sorts of
social conflicts.

~~~
steveklabnik
What is your alternate proposal?

~~~
lidHanteyk
The proposal that has the most concrete chance of succeeding is probably to
formalize some of Miri's behaviors as _auditors_ [0], explicit syntactic
annotations which indicate a type/function's willingness to have its source
code inspected and have facts proven about its behavior.

In terms of quality engineering, the "page of assembly" strategy is the one
that I think has the most merit. Write out enough machine-level code to boot
the machine and provide an environment for some higher-level language. This
should take about a page. Rinse and repeat until the higher-level language is
high-level enough for comfort. VPRI supposedly had made this technique work
for them. This would cleave Rust into two or more languages, though, and I
gather that a big selling point of the language is the ability to compromise
and allow many different safety perspectives into a single codebase.

I'm not Miyazaki; I can't just tell you that unsafe-blocks were a mistake. But
clearly and obviously, to anybody watching who has considered design and
implementation of programming languages, they were a mistake. Further, they're
the same mistake as Safe Haskell. We keep making this mistake, as a community
of designers and theorists, and we need to do better.

[0]
[http://www.erights.org/elang/kernel/auditors/](http://www.erights.org/elang/kernel/auditors/)

------
djsumdog
> Can we reject the idea of a BDFL? Can we include as many people as possible?
> Can we be welcoming to folks who historically have not had great
> representation in open source? Can we reject contempt culture? Can we be
> inclusive of beginners?

I feel like in any language, beginners are more than encourage to write things
in said language. Yet when working on language internals, you need to be more
careful. Reading the Firefox programming guide on what's allowed/not-allowed
in the C/C++ codebase is pretty eye-opening[1]. Have there been issues with
core Rust developers not being kind or following their CoC? The author doesn't
really include examples or explore this line.

As far as Reddit: I stopped using it the moment one of their CEOs altered
someone's comments during the election and was not asked to step down. That
CEO is still there. Reddit had their warrant canary removed years before that.
All their original values are pretty much gone and they've gone on a community
banning spree over the past few years. It's also no longer open source. I'm
fine with any community rejecting this as any kind of official communication
platform, but no one is stopping enthusiasts or hobbyists from using /r/rust

If actix-web has unsafe code and the authors are not accepting patches, and
someone feels passionately about it, they could create a saftix-web fork,
include all the patches, and maybe even develop it independently or pull in
changes from upstream.

It sounds like things went down terribly, and that's sad. Was it just Reddit
people, or core devs? I agree it doesn't help to attribute blame, but the
author doesn't dive into where the problem might have started and what could
have been done differently. I wish this had some more explicit examples of how
the community screwed up, the things they did right, the things that could
have been better. But then again, that could lead to call-out culture BS. I
feel this article is missing some depth, but it's also something that would
have probably washed over without the author going out of the way to write
this piece. I dunno. /shrug

[1]: [https://firefox-source-docs.mozilla.org/tools/lint/coding-
st...](https://firefox-source-docs.mozilla.org/tools/lint/coding-
style/coding_style_cpp.html)

~~~
zozbot234
> I stopped using it the moment one of their CEOs altered someone's comments
> during the election and was not asked to step down. That CEO is still there.

That was not a CEO but a _founder_ , AIUI. Can't really fire them or ask them
to step down, they literally own the place.

------
rafaelvasco
I don't know the minute details of the case so sorry but this comes to mind:

The double edged sword of open-source: We can't cooperate with one another if
we don't know how to behave and deal with other people. Emotion can never have
the final say. Because emotion is raw, uncontrolled, knows no boundaries,
doesn't know right from wrong. Especially if it is selfish emotion. Those that
act like this are bound to harm themselves and others;

------
aazaa
> So, someone takes a peek under the covers, and it turns out actix-web is
> using a lot of unsafe code. That’s not inherently a problem. The problem is,
> a lot of that unsafe code is not actually needed. This is where things start
> to go wrong.

Can anyone link to a discussion in which the actix-web maintainer explains his
position at a technical level?

The article leaves me baffled at why the maintainer was so unreceptive to
concerns about the use of unsafe.

------
DarkCrusader2
A lot has been already said about this unfortunate situation. I would like to
mention that pinning all this on brigading by reddit is very disingenuous.
There was a lot of hate directed towards actix and Nicolay on twitter by some
very prominent members of Rust community also who were discussing removing
actix from the awesome-rust list so people stop using it. Let's not represent
a community by their worst members.

------
excerionsforte
I wonder if there is a better way to manage vitriol for Open source
maintainers. Why should a maintainer take brunt of other communities responses
for issues like this compared to what they've contributed.

There just has to be a a way to summarize the noise such that it is indicative
of pushback. There has to be a way to have a discussion without attacking each
other when the disagreement is only on a detail.

------
alexashka
This is what happens when you get attached to a language, a library and
especially an idea of how things could be different.

You inevitably get disappointed. Good. Now you can evaluate and see if a
different outcome is even theoretically possible.

When you hope, you lose :) It doesn't mean you cease hoping, it just means you
don't do it so strongly. It's too much. You know it's too much, so just let go
:)

------
zelon88
> Its author also works at Microsoft, and suggested that Microsoft is using
> actix-web in production. This was really exciting to people. This was the
> second project using Rust at Microsoft, and so this seemed really fantastic.

Well if the project isn't FOSS anymore I can't see Microsoft continuing to use
it, which makes me question the accuracy of this statement in the first place.

------
zelphirkalt
I liked actix and did a little free time unfinished project in it, when it was
updated frequently. Ultimately I lacked the energy to read anew the tutorial
and update my code. Still, I liked to use it and think it probably became
better over the time I did not use it.

I don't know what kind of licence actix-web had. Seems to have been some open
source license and not a free software license, according to the "postmortem"
readme file, where the author says: "I am done with open source."

What stops anyone from using a fork to develop further? Did the license not
permit that?

If somehow that was not permitted or not possible, because no one created the
fork before it was moved to "private repos", then I think the author did
something quite childish , taking away the possibility for others to continue
developing the software, just because he is fed up with enduring the
criticism. "You don't like how I run the project? Meh, I'm going to take it
all away from you!" (That's how it sounds, when you move a repo to private
after and because of criticism.) Ideally any author, who works on an open
source project, knows, that they give up some control over the code and would
not act this way.

I do not say, that the shit storms were justified or good in terms of their
social aspect. However, if all of this managed to make actix-web safer, then
at least that aspect was a good result.

------
JohnFen
I have to wonder -- is this a real problem in the Rust community? The essay
makes it sound like it's just the usual Reddit toxicity.

~~~
steveklabnik
That’s what I was trying to get at with the “is /r/rust part of the community
or not” bit. Inside official spaces, none of this happened. If you don’t read
Reddit, it follow certain folks on twitter, you wouldn’t have seen any of
this.

------
miguelmota
There's a false expectation that if a package or project is open source then
the maintainer should put in free labor to keep it up-to-date. If you don't
like something then fork it and make it yours. Nobody is entitled to anything.
If I were the package maintainer I'd most likely do the same if I were getting
that kind of response from the community.

------
jmull
It's easy to get any bug fix you want: pay for them.

If you think loading your expectations on to an unpaid volunteer and then
harassing them over it will work out, hopefully this moment is a good learning
experience for you.

(Unfortunately, I can see from reading the comments that not everyone is
getting it.)

Perhaps someone should create an OSS contributor agreement where contributors
explicitly agree to work long hours, for free, in perpetuity, prioritizing
issues based on reddit heat, and see how many developers agree to those
conditions. Those are the expectations that appear to have driven this
developer to quit their project.

BTW, for those that don't know: acting on bug reports and accepting pull
requests is often a lot of work in its own right. Bug reports are often vague,
incomplete, contain incorrect assertions and assumption, lack clear steps to
reproduce or even a clear description of what happened vs what was expected.
It takes time a effort to clarify these things. Even then you may need to,
e.g., build an environment to reproduce or correct the issue. Changes from
developers that aren't highly experienced with the project typically have
gaps, new bugs, misunderstand requirements, don't build, ignore style
conventions, lack unit tests, and have various other issue that have to be
ironed out before the change can be accepted. It's all a lot of work.

~~~
status_quo69
I want to preface my comment with "I agree with you"

However, in this case patches and reproductions were submitted and rejected as
"boring". Whether the author really meant to use the word "boring" is neither
here nor there, the result was that the fix was ignored, even though that's
how open source works!

I've watched from the sidelines with no skin in the game (I use Rocket) and my
conclusion from all of this is that the maintainer should have created an
actix committee or group of maintainers to help shield from the inevitable
bugs and issues that crop up. If the OG author wanted to step back to take a
break from all of this, then fine, the rest of the group can continue to churn
and work.

The original article that called out the behavior also called out other
incredibly popular crates, like reqwests, for their underlying HTTP stack, yet
there's not a shitstorm about those libraries. The obvious difference that I
can see is the maintainer response to said criticisms.

EDIT: I also want to make clear that I _hated_ the comment about never writing
rust again. I'm not condoning that behavior at all

~~~
jmull
I think you're still heaping unwarrented expectations on the developer.

E.g, "...that's how open source works!"

That's your opinion, but what obligates the developer to adhere to this?

If the question is, was this a professionally run OSS project I would say,
certainly not, and I assume almost everyone would agree. But so what? Why
should a maintainer be expected to run an OSS project to a certain level of
responsiveness or spin up a governance mechanism if they can't do it on their
own?

> The obvious difference that I can see is the maintainer response to said
> criticisms.

I would suggest that reddit mobs are almost entirely capricious, random, and
irrational.

~~~
status_quo69
If my comment implied that there was some sort of expectation then I think
there was a miscommunication. There's no obligation for anyone to do
_anything_ , ever, but that's a pretty useless metric to mark against IMO.

Was this a professional project? Absolutely not. But was this a personal
project? I would also say categorically "no", since it wasn't scoped under his
personal github profile until recently. I'm very saddened to see something
that could have been solely community maintained be revoked instead of there
existing a potential mitigation plan in place (for example in the form of a
foundation or Org) for situations like this, especially since this has
happened twice before and it's sadly caused burnout for the main developer.
Again, no obligation to do this but why can't I say "man, that's true that he
_could_ follow these actions but that's also shitty" at the same time?

------
jes5199
the amplification of reasonable criticism into harassment campaigns is a major
dynamic in the last few years, and it generally ends up pushing people
completely offline instead of like, allowing them to improve.

It's in open source but it's affecting everyone who posts their work online,
which is to say, anyone doing anything that's publicly visible, anywhere.

------
AtlasBarfed
What is the issue here actually?

Fork the project and un-unsafe it.

------
withoutboats
This situation is the sad and absurd result of two processes going on in the
Rust community.

The first is that the Rust community on Reddit is in a feedback loop of
groupthink and outrage, making it into a powerful vector for harassment. The
maintainer of the actix project had a particularly terrible experience of
escalating harassment from the users of this subreddit, and its extremely sad.
This has caused a lot of grief for the maintainer of actix and prevented real
(but _far_ overblown) code issues from being fixed in a productive way.

But I think Steve undersells the absurdity of the unsafe anxiety. Some Rust
commmunity members are conflating two wildly different scenarios together. The
first is a library exposing an API which, if used in an unlikely and contrived
way, could result in a program using that library containing undefined
behavior. Then, since that program has undefined behavior, it could contain a
memory bug. If that were the case, someone could potentially exploit that bug
to attack a user of that program. You'll notice this is a series of
conditional statements - its a funnel of decreasing probability.

So yes, library APIs which can allow UB in safe code - even unlikely and
contrived safe code - must be fixed. The goal of Rust is that safe APIs can
never cause UB. But people should have a proportionate understanding of the
risk profile of these bugs (again: a programmer using this API in an unlikely
way could create a program with a bug that could potentially be exploitable).
This is a miniscule increase in the _risk_ of another heartbleed, it is not
_the same thing_ as heartbleed.

The spark that lit the kindling of the toxic Reddit community was a blog post
by Shnatsel, a member of the RustSec team. This blog post didn't get attention
here, but I want to take a moment to look at how ridiculously it frames things
by examining its analysis of a different project: reqwest (sort of the most
standard HTTP client library in Rust).

Here's the link: [https://medium.com/@shnatsel/smoke-testing-rust-http-
clients...](https://medium.com/@shnatsel/smoke-testing-rust-http-
clients-b8f2ee5db4e6)

The fuzz test, which is what the library is about, found no security issues.
It found some hangs in 6% of cases and Shnatsel traces them to a known
deadlock issue. This is a great result.

But Shnatsel spends most of this talking about a custom hashmap implemented in
the http library, which the RustSec group did a security audit of just a few
months ago. That security audit found only two issues, both UB that would
result from a contrived use of a minor library API (they are linked in the
blog post, but not explained). These two issues were fixed, and the fix
released, by the maintainers of the http crate in 10 days.

This is an incredible success! The security audit of a foundational library
found two minor issues which were promptly fixed, and the fuzz confirms that
the entire stack on top of it seems to contain no memory issues. Wonderful
result, but how does Shnatsel frame this?

> First things first: it didn’t segfault! I am actually impressed because I
> had really low expectations going into this.

Come on! The blog post is full of these kinds of snide zingers which are
totally unfounded in the face of the actual evidence presented. When you have
someone writing in this disingenuous, meanspirited way about open source
maintainers and then putting this in front of a groupthinking rage machine
community like Reddit, of course you're going to get harassment. This behavior
is totally unacceptable, and it's very sad to see it promoted in the Rust
community.

~~~
zozbot234
Didn't the Rust stdlib just gain a high-performance hash map recently? Is
there a real case for using a custom implementation in reqwest? I could see
Shnatsel getting a bit frustrated wrt. that choice.

~~~
thramp
The reason the `http` crate has a "bespoke hashmap implementation" is not
because "performance", it's because _HTTP headers call for different behavior
than `std::collections::HashMap`_. Some of the differences in behavior
include:

\- The map needs to be a multimap.

\- Insertion order needs to be preserved.

While `std::collections::HashMap` is an excellent HashMap, it is not a good
fit for HTTP headers.

------
Attained
This is something JavaScript does better than Rust. I like the JS community
because it's way more sympathetic on average. They have lots of code quality
issues to solve in some of the hardest ways... But people are working on that,
and I think they will succeed eventually, if they haven't already fixed much
with npm audit.

------
oaiey
There is a Code of Conduct. Question: is there a Code of Maintainership.

A document describing the principles the maintainer tries to uphold?

------
weiming
The "unsafe" keyword should probably just be called "unchecked," otherwise it
is a bit of a misnomer.

~~~
saityi
I think 'unchecked' would be a bit of a misnomer; code inside of unsafe blocks
is still checked by the compiler for many things. The borrow checker is even
on IIRC.

------
slewis
We always look at number of stars or installs of libraries before deciding to
put them in a production project. It'd be cool if there was a "percent unsafe"
badge that was commonly used for Rust repos. If folks started paying attention
to it it'd be harder for unsafe libraries to become popular.

------
gatherhunterer
People being people. I disagree with both the author’s code choices and his
treatment. I imagine most feel the same. Rust will be fine. The lessons
learned about choosing dependencies wisely and taking responsibility for those
choices will be scarce.

Running software is always more of a performance than an institution.

------
XAMPPRocky
Some of us in the Rust community wrote a letter of support for the actix
maintainer. In case anyone else thinks what happened sucks and wanted to show
support.

[https://github.com/actix-support/letter](https://github.com/actix-
support/letter)

------
amelius
I think the Rust compiler should write as its final log message "Resulting
binary contains x bytes of unsafe code" (or something similar). That way,
people are constantly reminded that their code depends on unsafe code, and
they can try to reduce that with visible results.

~~~
vngzs
Given the "unsafe guts" most of Rust stdlib contains, there's going to be some
baseline of unsafe code that every project has. I could thus see this
confusing new authors and users - you could have a project with zero unsafe
lines that will still report a relatively large unsafe surface.

Besides, perhaps this would reinforce the notion that unsafe is - by its very
nature - a bad thing. To quote Klabnik:

> it turns out actix-web is using a lot of unsafe code. That’s not inherently
> a problem. The problem is, a lot of that unsafe code is not actually needed.

If the code were actually needed, then there's no benefit in printing this
metric - it just makes a project that is using the feature perfectly correctly
look bad.

------
aganame
A community this large can easily deal with a loss of technical talent. It
cannot easily deal with toxicity. Therefore, it seems like a good thing actix
and its developer are leaving.

Also, a fascinating Trumpian "both sides have good people" -defense play.

------
qaq
I think there might be some cultural aspects at play here too as far as
communication style.

------
thosakwe
This is a sad day for open-source at large, as well. I think it's very
important to keep having conversations about proper stewardship of open-source
projects, until we eventually reach new models that are more fair/reasonable.

------
rowanG077
I'm not sure I agree at all with the author about the air about the Rust
community. Rust is an amazing language but the community has always been
totalitarian trash. I try to keep as far away as possible from them as I can.

------
barbarbar
I have no knowledge of actix-web. But just starred at the insane high
throughput achieved in the world most thorough benchmark test. Just horrible
to read about what the author had to go through. But fully understand him.

------
meddlepal
Simple solution: Ignore Reddit

------
mcguire
" _It’s unfortunate that a well-known project had soundness issues. It’s
unfortunate that the maintainer wasn’t receptive to fixing them._ "

What should you expect in this case? What is the best possible response?

------
anon284271
I don't know what a single thing in this post is referring to, so I'd just
like to point out the surreal nature of reading someone very passionate about
a bunch of words you've never heard of.

------
einpoklum
1\. I find the assumption that Rust code is safe a bit overly optimistic. If
you're writing network-facing code, security is always an issue to some
extent, even if mitigated by language guard-rails.

2\. The actix framework author supposedly did the following things at once:

    
    
       2.1 Wrote code somewhat carelessly
       2.2 Wrote and maintained his code alone
       2.3 Claimed his code was "safe" - in that mythical complete sense I mentioned above
    

this combination is a recipe for disaster, and he was warned (albeit in a
possibly-non-friendly-way). Thus, while the public outroar is probably
excessive - security bugs do happen - he is to some extent getting what's
coming to him.

Caveat: I'm a C++ person and am not familiar with the Rust ecosystem.

------
axilmar
If I was the maintainer and someone offered a patch that didn't alter the
properties of my code, but improved it, I'd be more then glad to accept it.

Unnecessary drama because of inflated egos.

------
rukittenme
I want to add two (maybe very) controversial comments.

1). It should be considered RUDE to contact a solo maintainer in any way
relating to the project (email, issue, pull request, etc.). You should ALWAYS
fork the project and use the forked project on your own terms.

Most people write their projects, on a whim, on a Saturday, for a bit of fun.
They do not want to be shackled to a hobby for the rest of their lives.

2). Opening an issue and opening a pull request are IDENTICAL requests for
effort.

Think I'm wrong? How many people were so incensed by this renegade maintainer
that they FORKED the repo?? Why didn't people FLOCK to the safer fork? Why did
people still care about the original repo??? The answer to those questions
underlie the fundamental problem of open source. No one wants to do the work.
People want to work on what they're passionate about. But they don't want the
responsibility of ANOTHER FULL TIME JOB.

An issue is a request to write "native" code. A pull is a request to maintain
"foreign" code. I have never had a large, successful open source project. To
date, I've had one repo with ONE issue and ONE pull request. Both required
more effort than I ever wanted to give.

I have stopped opening issues completely. If a project is maintained by one
person, you will never hear from me. Large projects with paid maintainers will
receive issues because I believe it the only appropriate time to do so.

\---

Here is a simple flow chart for contributing to a solo maintainer's open
source project.

1\. A problem has been discovered.

2a. I do not know how to solve the problem. -> Move on. Don't reach out to the
maintainer in any way.

2b. I can write a fix for this problem but I don't want to maintain this
project in its totality. -> Move on. Don't reach out to the maintainer in any
way.

2c. I can write a fix for this problem and I want to maintain this project in
its totality. -> Fork it. Don't reach out to the maintainer in any way.

~~~
zozbot234
A maintainer that you can't reach out to is no maintainer at all. If that's
the behavior they expect from others, they should clearly state that the
project is _not_ being maintained, and be open to others taking up that effort
instead.

~~~
rukittenme
> they should clearly state that the project is not being maintained

A project by a solo, unpaid author should be presumed unmaintained.

------
agumonkey
I cannot help but to think there are deep parallels between software projects
and any good old company. Dealing with a group of people around an "idea" is
far from easy.

------
h0bb35
This whole affair makes the Clojure way of relying on libraries instead of
frameworks really appealling to me. Frameworks are not fork-friendly.

------
fortran77
The Rust community is very, very toxic. They fight internally, but externally,
they take over any thread about anything and make it about Rust.

~~~
tasogare
Was here to post something along this line. The only place in which I'm
(hopefully) in contact with the Rust community is here. What do I see all the
time?

\- "rewrite it in Rust" kind of posts on a lot of threads

\- upvoting Rust mildly or not interesting projects just because there are
written in Rust

\- down voting every comment that even slightly criticize Rust (this comment
will be gray when you'll read it) or remind that code safety exists in VM
language for decades

~~~
fortran77
I am _very_ productive in GC languages. I use F# and C# all the time, and the
code runs fast, everywhere. And I don't have to worry about memory, and don't
have to learn a wacky syntax and wait for hours for a "borrow checker" to
complete its static analysis.

~~~
cesarb
> and wait for hours for a "borrow checker" to complete its static analysis.

The borrow checker is actually fast, the part where you wait for hours is the
code generation. There is nowadays also a "cargo check" command which stops
before the code generation, which you can use when you want only to see if it
would compile without errors (without waiting for it to actually compile).

------
gowld
What's wrong? There was a popular but dangerously broken library, and the
maintainer didn't want to fix it, and so it shut down. Everyone is better off
now. The code is still free for anyone who thinks they can fix it. It was a
bit messy along the way because people get emotional about bad security, and
people on the Internet have freedom to make comments you are free to ignore.
This is an open source success story.

------
The_rationalist
I wonder if some devs will get fired/some startup bankrupt, for using such a
risky dependency?

------
vasilakisfil
Just because maintainer quit doesn't mean the project is dead. It can be
forked and fixed.

------
debaserab2
I’m starting to really wish reddit wasn’t the default community forum for
everything.

------
scarejunba
Dudes, why don't you just fork the repo and run with it. License looks good.

It doesn't matter if code is full of secbugs, author doesn't like patches, or
whatever. Code is open source. You can't make it look like your vision. Fork
it.

Of course, no one in the mob appears to have had the wherewithal to do that.

------
fapjacks
Man... Wouldn't it be great if this same attitude often seen in users of open
source software was had by regular people toward civil liberties? Like where
people just pile hate on the codifiers day in and day out, because they are
owed their entitlements by birthright.

~~~
_wzsf
That's kinda how politics works. Sorry to have to tell you :(

~~~
fapjacks
You didn't understand what I wrote. To put it into simpler terms: Over time,
people demand less and less about their civil liberties, whereas with open
source projects, people demand more and more.

~~~
_wzsf
that's not even remotely true.

------
fc_barnes
I hope this makes it to the top so ngate can write about it...

------
sergiotapia
First the “rust being a moral programming language” and now this - I’ve never
seen a community stain a language so poorly as the rust people. Wow! And I was
there when Zed Shaw Cale’s rails a ghetto.

------
AzzieElbab
Why is this getting so much drama?

------
korethr
This is my from-the-outside-looking-in take on the matter.

It seems to me that there's a clash of expectations/worldviews, both happening
in this thread, and in the wider portions of the interwebz involved in the
kerfluffle this article is about.

A comment[1] from ddevault states two things:

> 1\. YOU are responsible for your dependencies.

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

The above is true. But there's another aspect here, that of cultural norms,
implied goals and the expectations derived therefrom.

By my observation of mailing lists, hacker's blogs, my own attempts at
contributing to various projects, and other things, there's come to be a set
of expectations of the authors, maintainers, contributors, and even to some
degree, users, of FOSS projects. These expectations are not set in stone; they
can be shaped by the statements and actions of the maintainer(s), implicit or
explicit, or the lack thereof. But there is nonetheless a default set of
expectations. A set of social norms, if you will.

One of the expectations I've observed, and discovered I myself had absorbed
through cultural osmosis, is thus: A maintainer should make clear what a
project's goals are, and earnestly consider patches/pull-requests offered in
good faith support of a project's explicit or implicit goals. They should
communicate clearly technical facts, concerns, and considerations when
discussing or debating an offered patch. Said discussion should be focused
only around the technical facts as they relate to the goals of the project and
the offered patch. And if the patch is rejected, the maintainer should clearly
communicate why. Said communication could be a long essay expounding on the
technical trade-offs the project has had to make, or a simple link to a FAQ
entry covering why such-and-such common patch type will never be accepted. (In
that latter case, presumably the earnest consideration of that patch type had
happened sometime in the past).

A related norm, one tying back in to ddevault's post, is the contributor's end
of that exchange. One offering a patch should accept a rejection with grace. A
contributor can and should be willing to discuss and debate and try to
persuade a maintainer how the offered patch actually does align with the
project's goals after all. But he should do so only with technical facts and
logical argument, not fallacies, emotional manipulation, name calling,
threats, or other such juvenile BS. To persist and pester after a final
decision has been made is a violation of that norm. Thus, it is as equally
gauche for a contributor to tell a maintainer to die in a fire after a
rejection as it is for a maintainer to state he doesn't accept patches from
people who voted for the Labor party in 2017.

None of the above invalidates ddevault's assertions. However, IMO, social
norms serve as a sort of oil on the machinery of the human interaction
inevitable in collaborative projects. A person rightly gets upset when those
social norms are violated. But, there are right and wrong ways to respond.

From what I've seen of this kerfluffle so far, it is a violation of those
norms which led to this mess.

Recall what I said about a project's goals, above. Rust's explicit goals of
memory safety, thread safety, etc, IMO carry with them an implicit goal of
making for secure programs, by making it easier to avoid the kind of mistakes
that cause programs to become insecure. I'm not a rustacean, but it seems to
me that at least part of the wider Rust community is working on making that
implicit goal an explicit one. And so, by building your project with Rust,
that goal of a secure implementation transitively becomes one of your
project's goals, at least implicitly. If it's not, you had better explicitly
state otherwise. And if you do, I don't think you should be particularly
surprised when some push back.

And so we come to the violation of social norms. I can't find any before-the-
kerfluffle articulation of actix-web being a for-fun project. So, actix-web
was seen as having the goal of being sound and secure, by virtue of being
implemented in Rust. And here was Nikolay's virst violation: failing to make
clear the goals of the project. If after that first instance of 'unresponsive
maintaner', as steveklabnik puts it, Nikolay had made clear his main goals
were being fast as possible and winning the benchmarks, that soundness and
security were non-goals, and he had firmly and politely held his ground on
that, I think the kerfluffle could have ended there. If he'd made those goals
explicit then, then other users would have been able to take a look at the
project, and see that all that Unsafe code was probably not something Nikolay
cared about changing, and so know they need not offer patches for it.

But since that wasn't done, we come to the next violation: not earnestly
considering those patches offered in good faith -- or at least seeming to.
Because of the impedance mismatch between Nikolay's actual goals and those
seeming goals of actix-web, he seemed to not take seriously those patches
offered.

As I said above, there's a right way and a wrong way to respond to such
things. And sadly, the response by some was to violate the contributor's end
of the bargain: accepting a patch rejection with grace. By responding with
out-of-line remarks like "please stop using Rust", the quality of the
discourse degrades, and shit rapidly gets toxic.

I don't think it would have been a violation of norms to call out all the use
of Unsafe, and the various ways it was unsound, or even to advocate that
others should not use actix-web, so long doing so stayed fact-based and did so
somewhere other than the actix-web bug-tracker. As far as I can tell, the
smoke test of HTTP clients did that. I haven't dug deep into the Reddit
thread, but if there was personal attacks on Nikolay, I'd not be surprised.

What have I learned from this, despite not being part of the Rust community?
Well, if nothing else, it highlights the importance of clear communication. In
any future projects, I will need to make what my goals (and non-goals) are as
clear as possible. I will also need be willing to clarify things when there
seems to be an impedance mismatch between my goals for a project, and what a
contributor thinks they are or should be. And I'm going to have to develop a
thick skin and the ability to de-escalate, because some people are going to
respond with perceived rudeness from me with deliberate rudeness of their own.

Perhaps that's a naive take on it. I welcome suggestions on how to improve it.

1\.
[https://news.ycombinator.com/item?id=22075346](https://news.ycombinator.com/item?id=22075346)

------
rezeroed
I deleted the issue - I regret that. I'm deleting the project.

------
emccue
Oof magoof

------
rusttoxic
I agree with what another person has said on github- the rust community on
reddit is incredibly toxic. The last time such a thing happened, there were
losers who made personal attacks on Nikolay. Then Nikolay showed up in
comments being angry that he had helped that particular loser only a few days
back.

Its easy to create blog posts and comments about RIIR, its not easy to
actually write code.

If anybody actually wants to fix this issue and prevent it from happening
again, I'd start by instantly banning /r/rust users for 3 days anytime they do
a circlejerk.

~~~
munmaek
Blaming 86k people for the actions of a few is toxic.

------
coleifer
I am _disgusted_ by the cultural phenomenon of making sarcastic call-out
comments on twitter/etc., with an eye towards building up enough community
outrage to force an issue.

There are people who forget that open-source does not entitle you to anything
(read the fucking license).

Maintainers of large projects are not even allowed to have a bad day, to make
a brusque comment, or to disagree with a majority -- without someone trying to
stir up a lynch mob. It sickens me the lack of balance between the work done
by the maintainers, and the expectations of random users.

~~~
dbcfd
> Maintainers of large projects are not even allowed to have a bad day, to
> make a brusque comment, or to disagree with a majority -- without someone
> trying to stir up a lynch mob. It sickens me the lack of balance between the
> work done by the maintainers, and the expectations of random users.

Sure they are. There's a number of projects out there with a massive caveat on
the front page that says "Not for production use". They are then more than
free to close issues with comments like "Hey I'm researching a new refcell
implementation, thanks for finding this, but I'm more interested in speed than
safety at this point."

Actix did not put up a disclaimer, and in a lot of cases, either closed
issues/patches without comment, or with a somewhat demeaning comment. It was
not just published as a fast and safe production ready web framework, it was
promoted as such, so the author should expect patches in that vein.

There were multiple bad actors involved here, but it stems from a maintainer
who took issue with anyone finding problems in his code.

~~~
Traster
Sorry, it doesn’t work that way, come on github isn’t intended for production
unless specified otherwise. The default assumption is “This is just some code
I don’t own”. Even repos that do make some claim of support or quality should
be treated with suspicion. The onus is on the person using the Open source
project to do due diligence.

~~~
ssokolow
But it's not just "code on github". It has the very professional-looking
[https://actix.rs/](https://actix.rs/) and so on.

------
Brave-Steak
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/epzukc/actix_web_repository_cleared_by_author_who_says/)

[https://old.reddit.com/r/rust/comments/epoloy/ive_smoketeste...](https://old.reddit.com/r/rust/comments/epoloy/ive_smoketested_rust_http_clients_heres_what_i/)

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
users that his framework was thus not safe to use (to the level expected of a
Rust project), and rejected plenty of PR's where these issues would've been
fixed, while being belligerent about continuing to write unsafe code.

[https://cdn.discordapp.com/attachments/648807492931026953/66...](https://cdn.discordapp.com/attachments/648807492931026953/667520639455854593/img-2020-01-16-160126.png)

He'd even started deleting comments and entire issues just for pointing out
unsafe code. _And_ it seems like he's had the archives deleted, since the
archived pages which used to exist are no longer accessible (I didn't even
know that was possible?).

[http://web.archive.org/web/20200117043715/https://github.com...](http://web.archive.org/web/20200117043715/https://github.com/actix/actix-
net/issues/83)

Frankly, after years of seeing people defend C/C++ projects because "well,
just get better", I think it's a good thing that security-consciousness is at
a point where developers are being rightly criticized for playing fast and
loose with security. There are always complaints about how we have no idea
what kind of code being used on NPM or other package systems. But make some
effort to improve it and now they're the bad guys? Oh, come on. You can't have
it both ways.

And as somebody else has already pointed out, plenty of other projects also
had PR's regarding safety issues, as linked by the original article which
tested all these projects. The actix author is the only one who rejected them,
and he's the only one facing complaints.

~~~
Brave-Steak
Found a working copy of the original Github issue:
[https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...](https://gist.github.com/mafrasi2/debed733781db4aba2a52620b6725adf)

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

------
archivist1
Open source is fundamentally wrong and in need of a correction. It's an
exploitative labor practice.

There's a better way. It's coming.

------
o_p
So much for the C killer huh

------
giancarlostoro
> Rust has a necessary feature, unsafe, that allows you to escape Rust’s
> guarantees. This is a really important part of Rust, but also a very
> dangerous one, hence the name. But one of the things that’s important about
> it is that, since unsafe means “I have checked this code, and it upholds all
> of the guarantees the compiler cannot check,” you can build a safe interface
> with unsafe guts.

This blew my mind. I had no idea this was happening! I really hope Rust
continues to evolve. Still no idea why JetBrains wont adopt it officially like
they did Go.

~~~
steveklabnik
JetBrains does sponsor the development of the Rust plugin, IIRC.

------
EugeneOZ
Nothing "sad" here. FUD article. By 2 reasons framework was not good enough
for usage anywhere else than benchmarks: 1) careless attitude to security
issues; 2) too fragile behaviour of author - when I know author can completely
ruin some dependency of my project just because somebody on Reddit was too
rude, I will never pick such dependency. Internet is a wild place, Reddit is a
wild place, deal with it. Creating issues for so many users of your project
just because somebody wrote offensive comment on Reddit - I can't even
understand such childish behaviour.

------
nautilus12
I dont know what people expected from him, he was working 12 hour days
already. If they didn't like it then they could just try to help him out
instead of tearing down the work he was doing. Did he not accept PR's because
he didn't have time to get to them all? Either way, writing an article further
isolating him for all his work isn't going to make the situation better.

------
zelly
That's okay, Rust should never be used for web anyway.

I don't like the idea of Rust, C, C++, or Assembly for directly web-facing
services. Any non-GC language should be a non-starter. There are literally
(uncountably?) infinite ways you can have memory errors in a native program.
The consequences of _any_ of these can be devastating because absolutely
anyone can access your endpoint. Notice the asymmetry: One small, unnoticeable
error can lead to devastation. Like running across of a field of sparse
landmines, eventually you will get destroyed.

~~~
umanwizard
The set of all computer programs is countable, so I don't think there can be
uncountably many ways to have memory errors.

~~~
zelly
That seems right. Memory errored programs are a subset of all computer
programs.

The possible runtime states of a program (expanding every branch/subroutine
recursively over all threads) is uncomputable. (Otherwise we would have a
solution to the halting problem and be able to correctly free memory at
compile time.) I'm not sure if that's the same as being uncountably infinite.
It's probably a different concept.

~~~
umanwizard
Uncomputable is indeed a totally different concept from uncountably infinite.

------
olah_1
I actually think the "code of conduct" culture that Rust embodies exacerbates
this kind of drama. Ironically, it creates a more unsafe environment where
everyone feels anxious and judged by the CoC Police. Under the CoC, I am
entitled to a wonderful experience, and if I don't get it, the culture has
failed in its commitment to me.

~~~
DagAgren
I have literally never felt "judged by the CoC police" in any project that has
one. I have no idea why you would ever feel that way. Pretty much every CoC
says "do not be a raging asshole". I am fully capable of not being a raging
asshole, and if I slip up and am, I would be happy to be told off for it.

~~~
zdragnar
There have been very public instances of it happening, though the truth is
people would have been just as assholish with or without one. Toxic people
don't need to hide behind a CoC to be toxic, and they aren't especially likely
to obey one either.

