Hacker News new | past | comments | ask | show | jobs | submit login
Actix Web – Project Future (github.com)
147 points by praveenperera 28 days ago | hide | past | web | favorite | 38 comments

Earlier discussion for context: https://news.ycombinator.com/item?id=22075076

How many `unsafe` blocks of code are there and how many of them can be refactored? What's a t-shirt size estimate on the level of effort to convert the code?

Unsafe blocks are not per se a bad thing — think of them more of a "trust me here and give me manual control"-override.

Figuring out whether an author's trust is earned or if they just used unsafe to stop the borrow checker from nagging is non-trivial for precisely that reason.

So you question is very likely impossible to answer even by the author himself. If you are really eager to know, dig yourself.

I'm certainly glad that given a bit of time, cooler heads have prevailed. I completely understand the shear frustration one must endure when managing any open source library/framework. There is a huge sense of entitlement among consumers... but this should not translate to any responsibility on the part of the author. Throughout this process, I've seen comments about how simply forking the repo would be considered hostile... yet, I always felt that was part of the beauty of open source. Use what is available, and "stand on the shoulders of giants" when you wish to see something go in a different direction. Instead of viewing it as, "what you built is terrible, here, let me fix that for you". We should strive to see it as a tree that has much potential, some branches may be more favored. Some may collapse. Alliances may be formed. But it's all in the name of building cool stuff. I get how some may consider that nothing would ever get finished using that model... but, therein is again, the beauty of open source. If someone wants to "finish" something, they are free to do so.

It doesn’t have to be a tree, branches can merge again - remember iojs.

I am in exactly this situation now. I want to be able to have a method to load the content of the partial for mustache.ra; wrote in their repo looking for feedback - but if no none - absolutely going to fork, and hopefully no hard feelings on either side....

I maintain a handful of forks of node.js libraries that the original authors were unresponsive or uninterested in maintaining. Some people did the same to some Ruby gems I wrote ten years ago.

There was absolutely no drama involved. As long as you credit the original authors and isn't passive aggressive about forking, all is good.

In fact, one of the authors of a library I forked noticed the attention my fork was getting and wanted me to merge back. Everyone won in the end.

So glad I don't maintain open source for some viral scale fanciness. Seems like a lot of work for generally no pay. I know a lot is company supported but a lot more isn't. Then there's those people demanding support for free. And other's demands for you to review their code and apply it 5 seconds from when they send it in.

Seems like I'd take a few days off one week and a twitter storm would brew and then a doxing campaign would fire up and there would be lynchmobs and angry pitchforks outside the building where I work. Obligatory comparison to Hitler or such and then I'd shrug and say, "its a tetris clone, people, calm down!"

I'm hoping that is all an exaggeration. But from what I have seen recently its not that far off in terms of online hate that can appear.

Is there a guide for maintainers of such things so deal with the generic overhead that must come from having a "community" around some popular tech software?

I'm always a bit horrified when I see folks show up on github making demands / insults are thrown at someone offering their code for your use.

For whatever reason I sort of assume that there was a barrier on github where users who bother to read the code also code and would have some level of understanding that coding is hard, not every bit of code everyone writes is the way they want it ... and that would add to some level of understanding and civility.

It seems like I was wrong.

In this case, you really need to go back and look at the issue trackers. It wasn't just people making demands; people had submitted patches that fixed safety issues. Some of them were merged in, but some were ignored, one was called "boring" and it then mean things started being said. Entire issues were deleted.

I don't agree with the mean things. Yet I can understand the frustration: here is a new patch that works and fixes something that could lead to a security issue? No one wants to fork the entire project and start their own version.

Honestly, the maintainer seemed kinda arrogant to boot. It might have just been a language barrier too, so who knows. I think if you took enough time to really look at all of it, it's a much more complex situation that what everyone is simplifying it too.

Looking back, it seems to me that the maintainer was/is in dire need of a vacation. It's easy to become dismissive when you're stressed and burnt out. There even is an issue filed in August where he recognized that he needs help with the project.

The mistake seems to have been that no effective countermeasures were taken before things boiled over, but at least now the whole mess has ended on a positive note.

Wow, what happened? I just went through a local Rust meetup in NYC and learned that Actix is one of fastest web frameworks across all languages and the huge popularity in IoT space. Can some one explain any concerns for this project's future like splits between ffmpeg / libav?

The author prioritised benchmarks and "creativity" in code rather than making sure the library was safe. That's fine, it was their code after all.

However, many people saw that this was a caviller attitude to take, especially as it wasn't signposted, and gave the author grief for this.

The problem was, though, that the cumulative effect of these "unsafe is bad, therefore you are bad" comments (which shouldn't have been made) was that the author was dismissive towards reports of actual unsafe behaviour in their library which could have caused security issues.

The author got frustrated and moved the repos to his own personal account and left a patronising message in its place.

Bare in mind that Atix had been built up as one of (if not the) best Rust libraries for HTTP servers, partly off the back of the benchmarks (for which safety had been sacrificed) and partly from the fact it ran on stable (non-nightly) Rust.

I tried to make sense of it and it didn’t seem to be that much more convenient compared to running iron + appropriate middleware packages (session storage; multipart; etc). They seem a bit “stale” but work absolutely fine. Source: 33KLOC stable rust web project.

Where is rust being used for 33kLOC projects?

33kloc is pretty small; rustc is over a million lines of code, for example.

The tl;dr is that part of why Actix is so fast is that it takes an aggressive approach to the use of unsafe code blocks. This is not inherently a bad thing (Rust's own standard library is full of unsafe) as long as the APIs you expose on top are safe. Actix has drawn criticism multiple times over years for excessive use of unsafe; many times these criticisms have included findings that safe APIs can be misused. The primary author of Actix sees it more as project of intellectual curiosity - which is certainly a fine way to run a project, it's just a little at odds with the perception you (correctly) picked up of Actix being a flagship Rust framework and recommended for production use. He doesn't see unsafe code as something to be cautious about and hasn't prioritized removing unnecessary unsafe code, which puts him a bit at odds with the Rust community and also gave Actix a bit of a reputation of "the framework that's fast because it cheats" (which isn't totally fair but isn't totally unfair either).

This weekend, someone found an unsound use of unsafe code, reported a bug, and eventually a patch was supplied that switches out some optimized Actix types for somewhat less optimized standard library types. The author dismissed the patch as "boring," the internet got mad, and the author got mad.

Humans gonna human. Glad to see this is working itself out.

maybe the new maintainer will be more open to vetting & accepting `unsafe`-reducing patches? that would be a great outcome.

This whole situation reminds me that team management of open source projects is very helpful. Not just for when maintainers have issues but for those time when you have to go through issues as a maintainer. Having someone to talk with and sharing the burden is incredibly helpful.

That is a trade-off, as the team typically needs a common vision that might not be easy to distribute (or even extract out of your mind).

I had a similar problem with Chrono [1], the most popular Rust date & time library at the moment (though now rivalled by time-rs [2] ;-), where I was struggling with personal issues and yet (thus?) unable to sufficiently materialize my vision. Eventually I gave up and passed a torch to other interested people, one of which is now the primary maintainer, but no major API design and stabilization that would lead to the 1.0 is not happening as far as I concern.

[1] https://github.com/chronotope/chrono/

[2] https://github.com/time-rs/time

Have to say, this whole drama put me off Rust a bit, more so than I expected. Its the taint of proselyting extremism among the worshipers of 'security', I think. Like finding a worm at the bottom of your tin of peaches.

Honestly, it put me off Actix; not Rust. Mind you, I haven't really explored the language that much, but I'd like to be able to pick a well supported framework that has some solid guarantees if I enter the web space with it.

I want to take a moment to appreciate the participation of the whole community on this. I've been following the story since it started and I'm very pleased to see how people (HN, Reddit, Github, etc.) came together to support the author and promote a more friendly Rust community.

There is a lot of criticism in the Software Engineering community in general but the Actix story made me feel way more welcome and open. I'm very happy to see that!

Great news, I hope the project has a healthy future ahead.

Would anybody care to shed some light on the situation? It seems that various commenters have a level of context not present in the linked post.


you'll find all the references there


Nice to see a (relatively) happy ending!

This is not a duplicate, this is an update with meaningfully new information, and should not be hidden. @dang ?

My heart skipped a beat when I saw the new maintainer went by the name John Titor. Apparently just a reference to the original though.

Judging by their avatar, it might be a reference to Steins;Gate, a visual novel and anime about time-travel. John Titor features prominently in its plot, and it references many aspects of the "real world" counterpart, including the crazy theory about the IBM 5100 computer.

So, John Titor came to save the future of Actix.

A more lore-correct reason would be John Titor returns to learn how Rust actually works as people in the future can no longer figure it out.


Comments like this are exactly the reason why we got into this mess in the first place. If anything, please take this as a lesson for the future.

It wasn't a random person. A random person would be tolerable. If you haven't been on the receiving end of that sort of abuse you probably can't imagine what it feels like. But if you are paying any sort of attention to the world, you would realize that to most people it feels really bad to get a lot of abusive and hurtful comments from strangers about something you've put a lot of work into.

They tend to go hand in hand, don't they? When something isn't interesting anymore, the negatives seem much more ominous. The benefits don't seem to be worth it.

Now he has the best of both worlds, deservedly so. He created and was the primary author of a substantial, influential project and that will never be taken from him. Yet he also gets to move on to other things without it dragging him down in perpetuity.

Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact