
Rust framework actix and actix-web are dead - dragonsh
https://github.com/actix/actix-web/blob/master/README.md
======
kbumsik
Dupe:
[https://news.ycombinator.com/item?id=22073908](https://news.ycombinator.com/item?id=22073908)

------
logicchains
Hypothetically, if I was writing an open source library for game development
or HFT (two other big users of C++ code), would the Rust community respond
similarly to use of unsafe code? In HFT at least we have zero concern for
buffer overflow vulnerabilities and the like because we're not on the open
internet, rather we're running in a colo directly connected to the exchange,
so we face no risk from security vulnerabilities in code (as long as the code
works as intended). I imagine it's similar for games, where unless you're
writing DRM it doesn't matter if somebody gets root on their own gaming device
(and even if your code is perfectly secure, they can still try to modify the
code in memory to exploit it).

In which case the "downside" from unsafe code is much less (it's not going to
leak an entire database of people's private details to the web), so would
people still make such a big fuss about removing it? Especially if removing it
involves any performance compromise, which in HFT at least would be
unacceptable (or at least politically unacceptable when trying to sell Rust).

~~~
printango
What's the particular benefit Rust offers you in such a scenario? Part of the
appeal of Rust is memory safety, per-compile correctness, and enforcing best
practices.

If you wrote a game engine in Rust, and open-sourced it, you'd probably get
similar grief. Because that's what Rust is largely about. Anyways, certain
high performance render applications (browsers, ahem), don't seem to suffer
significant penalties.

Also, I'd argue that memory safety/rce protection/etc is crucial in games,
particularly ones that are online. HFT running in a contained env? Less so,
for sure.

~~~
logicchains
>What's the particular benefit Rust offers you in such a scenario? Part of the
appeal of Rust is memory safety, per-compile correctness, and enforcing best
practices.

It's a modern language: no #includes, faster compilation (compared to
template-heavy C++), nice macros, compile-time reflection (libraries like
Serde are really nice), generally nicer stdlib than C++, decent package
manager. And it's one of the only languages with RAII/destructors, which to me
are one of the best things about C++.

>Also, I'd argue that memory safety/rce protection/etc is crucial in games,
particularly ones that are online.

This applies to the server, but not to the graphical game client running on
the user's machine, as the client is usually not accepting random inbound
connections, instead it just connects to the server.

~~~
printango
Thanks.

>This applies to the server, but not to the graphical game client running on
the user's machine, as the client is usually not accepting random inbound
connections, instead it just connects to the server.

There have been a few demonstrated RCEs in game clients (especially in P2P
models which many modern games use).

~~~
logicchains
I didn't know that, that's scary :/

------
echelon
I feel bad for the maintainer and how the community treated him, but I think
his reaction was incredibly self-destructive.

I'm a little worried about the professional ramifications he'll face. His
employer is definitely aware of him burning down all of his open source code.
That's got to make for awkward conversations with his team, peers, and
manager. It's also going to make future job hunting weird if that subject is
broached.

How did this escalate to this point? Why couldn't people be nicer to him? Even
if the unsound arguments are true, there are better ways to offer constructive
criticism. People needlessly backed this man into a corner from which he saw
this as the only solution. He's going to be dealing with this for some time.
:(

~~~
peterbraden
Why do you think this reflects badly on him? He deleted some repositories that
he made in his spare time? It wouldn't affect my decision to hire him
negatively, and the experience that he demonstrated with the project is still
a massive positive.

~~~
echelon
I think it was the wrong way to disengage from the project and community.
Deletion and removal is destructive. He could have easily changed the README
and archived the project, but he went out of his way to destroy it.

Without knowing him, I'd worry he'd do that in other organizations he's a
member of. What if he has a fight at work? Will he delete stuff or leave in a
hurry without making arrangements for other maintainers?

I'm not saying he would do these things or that he's a bad person, it's just
something I'd be cautious of given his response to this. If I were his manager
or coworker I certainly wouldn't fire him, but I would talk to him about it.

As for next steps, I think the maintainer should undo the deletion, apologize
for the rash response, thank the sane members of the community for their
appreciation, and leave a message that he's disengaging for awhile (it could
be forever). That would be the perfect way to go about it. It doesn't leave a
bad taste, and it's an overall good look. It's the high road.

I still feel incredibly bad about how the community treated him. He was doing
amazing work for all of us, and some careless folks berated him needlessly.
There are better, more constructive forms of criticism.

------
fizx
I don't think I've seen another situation where the arguably premier framework
for some language was so contrary to the language's purpose and community
goals.

It would be like building a GraphQL framework that serialized all data as
Base64'd XML inside a single field, or perhaps if the biggest Burning Man art
car was police-themed.

------
halffullbrain
Now it's back up: [https://github.com/actix/actix-
web/issues/1289](https://github.com/actix/actix-web/issues/1289)

Good call, fafhrd91! C'mon, people, it's only software, try to understand each
other and be civil.

------
shmerl
Previous discussion:
[https://news.ycombinator.com/item?id=22075076](https://news.ycombinator.com/item?id=22075076)

