Is this project abandoned?

[t1m0t]

I don't see any updates since end of August from Sergio as he is the sole validator. So I am wondering if this project is abandoned?

[JockeTF]

See this comment.

[t1m0t]

@commandline-be that makes sense to create funding to maintain this project but if the maintainer, who Sergio for 90% of commits, is not here, it is like the project is dead, despite all the considerations and debate that can be made here. It not of being right or wrong, on taking things personally, it is about real stuff. So my question still remains? Is there any news about this project being taken over? Or should we stay silently put and wait for chickens to have tooth?

[nathanielford]

I maintain that there are four scenarios: the project will go forward and the maintainer will answer the aforementioned thread, the project will not go forward and he will answer on the aforementioned thread or generally, the project will go forward without acknowledgement of the question, or it will not go forward, without acknowledgement. In none of these cases does asking /again/ help.

On the other hand, it does make the /asker/ seem entitled to an answer, which one is not really entitled to.

As engineers you always have to make choices about what libraries you use, and code velocity is a factor in that. Hence my recommendation; either choose a library that makes practical sense for you, given all concerns, or if you think this is the library for you, you have two choices - wait patiently or contribute. The latter can be directly to this library or it can be to a fork, but pestering the maintainers does not move the needle, and carries a real cost. Asking repeatedly about the state does little to 'band the community together'. Making demands of others without yourself having any skin in the game does little.

I love Rocket and have staked several projects on it, so I reject the idea that it's somehow disloyal to encourage people to use their professional judgment in library selection. I believe fully that if and when the contributors and maintainers of Rocket can, they will address concerns, and that repeating those concerns serves little end. I don't think anyone on this thread wants anything but for this project to continue. And in that spirit I have offered the above advice, because I think it leads to the best outcome. It is not a reprimand, just an ask for all of us to be very cautious about (even accidentally) making demands, or blithely assuming we know what the situation is and how to fix it (especially if we have not anted up with the work to do so).

One last thing before I sign off this thread:

If anything developers are well known for not being great communicators

This is a stereotype, and harmful. Let's avoid it, please!

[t1m0t]

@nathanielford I got the point, thanks for taking the time to explain this necessary point of view which is constructive and positive. I hope Sergio will come back soon safe and sound with answers if necessary!

[IniterWorker]

Hi folks,

Recently, I was listening to the presentation by Sarah Novotny at OSS. "A personal note on growth and hats". Somehow, the talk is in phase with your concerns.

Humans are great storytellers. When they don't get any updates, at the right time, they are starting to make stories about everything.

In this particular case, It was great to read the message from @commandline-be about "seek for someone at their side to communicate with the public". I hope that @SergioBenitez helps us with the communication process around his framework.

Let's be harmless

I agree with @nathanielford, because developers are human, stereotypes don't belong in an argumentation.

Let's be humble

True is, we are struggling to gather information and folks are talking about the framework's end of life. I understand that the lack of checkpoints in an open-source project is complicated for the users and their projects (commercial or not). We need to work on :

• Communication
• Community

Let's be helpful

The project's state of the art is all about one person. So, what is the best approach to help @SergioBenitez in this open-source project?

• Should we need more maintainers?
• Should we need more reviewers?
• Should we need more speakers? (seems to be yes)

I would suggest that we empower people to contribute in a more proactive way. Maybe a hierarchical way or maybe a flat management way. But, we need more people working on the project. And, I have hope that the community will contribute to the Rocket.rs project and that we will learn from every contribution.

Regards,

[somehowchris]

Let me reassure you, what ever you might read from me beneath this line, I‘m totally with you @IniterWorker and I just wanna shine a light at the current ongoing things.

Rocket with it’s community seems too big to fail for rust. Neither warp nor actix have the tooling and support of the community as Rocket does. Coming from a background with nestjs (a nodejs framework) Rocket had a lot of similarities with it but Rocket has a lot more code to deal with as frameworks like nestjs are just abstractions but Rocket has to deal with a lot of things itself. And yes, big moves aren't that easy in rust to accomplish all together.

Most of the times it's just about how maintainers and developers interact with their community. @SergioBenitez showed us how he can present his accomplishments at conferences and worked out plans to have this project going but as you guys already pointed out. This leaves him as the one controlling the repository and with it the state of the project.

Many of us have pointed out that they would love to help out. Get this project going, maybe with @SergioBenitez with us, him as a mentor or just him overseeing the project as he knows what's going on probably a hell of a lot better then we all do.

Now Sergio isn't gone. A few days ago he updated some repository of him with additional commits and releases to crates.io. This motivated me to write him a Mail (PLEASE DO NOT SPAMM HIS MAILBOX). I didn't yet hear back from hin and I wasn't aware of this thread but I will happily share what I hear from him if he answers and if he allowes me to share.

Again I would like to emphasize a humble and cheer-ish movement. That said, from my point of view Rocket is at a stage where it shouldn't be a personal project anymore but it's neither a commercial one.

[fakeshadow]

I don't see how the current state of Rocket has anything to do with funding.
I bet if the maintainer ask for it the community would happily offer help on maintaining/releasing/developing when he is busy on personal matter. It's just sad seeing the community can do nothing when the project stale.

[kolbma]

Is here somebody who is in contact with @SergioBenitez ?

Next to him there is only @jebrosen who has an adequate commit line count at the moment.

I'd really like to see Rocket becoming a team project with some regularity.
But it is hard to step in without any communication to get things going.

[najtin]

@nathanielford To me it is really about continuing rocket. I hope SergioBenitez will come back in good health and all and with the capacity and interest in the rocket. Right now SergioBenitez is the only Maintainer of Rocket. It is great software, but if for what ever reason SergioBenitez leaves the project, there is no backup. Right now Rocket works great, i don't see the requirement for urgent actions. Nevertheless did SergioBenitez absence highlight this single point of failure. And that is why now is the right time for the ongoing discussion. I am hesitant to build projects that shall last for years on Rocket because of this, although Rocket may be otherwise the best choice.

[couchand]

My previous post skipped past the "why fork?" question and jumped straight into the "what to do?" one. I did this in an effort to keep a positive note. However, from the above discussion I can see that it's not clear to everyone why a fork is necessary. I'm going to be completely open and honest, at the risk of sounding harsh, because it's important for folks to understand what's at stake.

I lead a small consultancy that uses Rust to build reliable systems. Many of our clients require publicly-accessible web software. To now, Rocket has been a fantastic and solid web framework, letting us build performant servers while focusing on the domain. Given the track record of stability and the pace of ongoing development, it's been our go-to recommendation for a while. We have several clients running Rocket servers in production and more projects in development.

We will no longer be using Rocket for new projects, and we will be migrating existing projects off of it. The current situation is simply untenable: it is not an acceptable risk to have a critical, web-facing piece of infrastructure be built on top of a crate that has no way to release timely security updates. It is not an acceptable risk to have the only maintainer of such a core library go dark suddenly. We don't need to lack specific features to reach this conclusion: the inability to publish a release is enough risk.

Sergio Benitez has done an amazing job building the software, and he's clearly also built a community. Unfortunately, he did not take the critical step of preparing a succession plan, allowing the bus factor to remain at one for too long. I have the deepest of empathy for him for whatever personal concerns have come up over the past few months. It is apparent that something very difficult has happened, and I have no way of understanding what he's going through right now.

However, the decision to use this library is not a personal one, it is a professional one. I made the mistake of assuming that the broad community around this project was enough to keep development momentum, but failed to notice the bus-factor risk. At this point it would just be irresponsible to use this library in a professional context -- there's too big of a risk that a show-stopping security issue will come up and no mitigation can reasonably be made. Or worse, that such a vulnerability will go unnoticed due to lack of attention of the development team.

This is not yet an irreparable situation. If the community can rally and produce a maintenance release, the Rocket project has a hope. Rocket may once more earn a full-throated recommendation. I've been impressed with Rocket to now, and I hope that this community is able to build on the solid foundation that Sergio Benitez has made. But it can no longer be only him, that much is clear.

[blackghost1987]

@najtin please make the members of the organization public and invite some important people (if you haven't done it yet, I can't tell).

I was looking into how to get the organization working without creating a new crate on crates.io, and this is what I could come up with:

1. Get @SergioBenitez to join the rocket-org organization!
2. Create a new "publishers" team in the org. Sergio must be a member of this team for the rest to work, and we also need at least one other (active) org member (I propose @jebrosen as the top contributor )
3. Set up the organization access rights correctly (see: https://doc.rust-lang.org/cargo/reference/publishing.html#github-permissions )
4. Get Sergio to approve the members of the "publishers" team, and add the team as crate owners on crates.io (with cargo owner --add github:rocket-org:publishers)

Note that this won't and can't get rid of Sergio as the crate owner, because GitHub team members can't remove crates.io owners! But this would get rid of the bus-factor, at least partially, by making it possible for the approved organization members to publish a new version. Also this makes it easy for Sergio to continue work when/if he returns, because all his rights will be unchanged. (He could even transfer the original Rocket repo under the organization I think, so we won't even need a fork and all the PRs / issues / discussions would be there, but this might be wishful thinking...)

If we cannot achieve these 4 steps, then we'll have no choice but to create a new crate, which would be unfortunate :(

If all steps are done, then the Publishers team could release a new version seamlessly. I propose creating a 0.5-rc2 version, only with stuff already merged in the main repo (probably the current head of the 0.5-rc branch?). This way there will be a distinct point in code history (with a tag and everything), showing where the code approved by Sergio ends, and where the new community stuff begins.
This would already help a bunch of people (like the ones waiting for MTLS for example, see: #2054 ).

Doing all this would be a good example on how the organization could work in the future, but it's only a first step. Then comes the real work: merging open PRs and creating a 0.5-rc3 or maybe even a full 0.5 release.

[viniciusd]

Doing all this would be a good example on how the organization could work in the future, but it's only a first step. Then comes the real work: merging open PRs and creating a 0.5-rc3 or maybe even a full 0.5 release.

Not sure I would consider it as a first step though. I really hope everything is fine with Sergio or at least it is getting better. I honestly wish him all the best.

But we have no guarantees he will indeed come back when he said he would. His ETA has already been sort of extended since his initial comment. We have no reason to believe (but we do have reasons to hope) that he will indeed be back by June.

There are a series of very nice ideas in this issue that we can consider in order to move forward. If Sergio does come back, any changes in a fork can be merged to the original project if he feels like so.

I am not confident Jeb Rosen is taking it over either as they haven't said anything so far.

I don't personally get the resistance to fork it, such as:

In all i applaud the intent, i also think random community members should not fork without good cause. Except for the maintainer not responding, what are the real issues at hand which could motivate a fork ?

Except for the maintainer not responding, well... this is exactly what is happening.

Rocket is a project that is currently on hold without any activity. Security issues might arise. Folks will move towards other frameworks when they are choosing the stack for their professional projects as Rocket is apparently unmaintained. At the same time, Rocket is staying behind while other frameworks are further developed, which will affect even further how competitive it is.

I don't see any reason to be optimistic about the way things are right now. I am not saying it is a dead-end and that Rocket is over, it us just that we should indeed consider the options discussed so far to move forward.

[somehowchris]

So I haven’t been read everything, will do that once I’m back from my holidays.

@kolbma love your activity and commitment, though one huge PR doesn’t seem to be a good solution from my point of view.

@najtin you created the github org, so it’s your turn to organize stuff, if you need help, hit me up at christof@weickhardt.ch

[kolbma]

If you have not followed the latest comments...
there is now a
https://github.com/rocket-org/

At the moment this seems to be managed by @najtin although there has not happened anything next to creating the https://github.com/rocket-org/Rocket/ repo up to now.
It is not clear who steps in the Rocket-Org.
So @najtin you can add me at the moment.
We need also a issue label for 0.4 and 0.5 branch.

I'm currently pushing Rocket forward by myself here: rocket-org#3
The dependencies are up to date and the ./scripts/test.sh --all should run successful or it will be fixed asap.

Now I'm finishing to bring in all the PRs from https://github.com/SergioBenitez/Rocket/pulls and the finish is near.
I've linked the PRs in my commits or commented a PR if it is questioning to merge it.

There is also rocket-org#4 which should be done before we are thinking of releasing a 0.5.0 version. And you are welcome to take the task and have some insights on this!

Searching the repository for "TODO" or "FIXME" and thinking and commenting about what needs to be done really with these or with off-commented code blocks, would be also helpful.

Well similar job needs to be done for the 0.4-branch! I've not touched this branch.

The next task would be to go through the issues https://github.com/SergioBenitez/Rocket/issues and create a priority list of issues which should be worked on here: https://github.com/rocket-org/Rocket/issues
Most might be closable.

[snaggen]

@najtin Could you please look at the Comment #2011 (reply in thread) and add the relevant people to the organisation, so this can get moving... it seems that everything is stalled waiting for access to the organisation? It would be a shame to loose momentum again...

[najtin]

Sorry for my long absence here, thanks for your patience. I invited @somehowchris @kolbma and @SergioBenitez . @jebrosen has no activity since December last year, so i did not invite him. If there are people that should be invited, please comment. I am in direct contact with @somehowchris .

UPDATE: I got in contact with @somehowchris . We should assemble a team of future maintainers. @somehowchris is the first to join. I am now trying to get in direct contact with @kolbma . Please let me know in case you see yourself as a future maintainer.

[somehowchris]

@kolbma you've been off for 14 days, left you a mail

[wezm]

An update from Sergio on Matrix:

[tianlinzx]

@somehowchris When will you start to update the Rocket project under https://github.com/rocket-org/Rocket ??

[somehowchris]

There has been some movement, trying to get ideas, debates and more together as issues. To some extent we have updated some further crates which are maintained by @SergioBenitez and used inside Rocket.

I currently do not have any permissions to do productive work on the repository as I lack Organisation permissions + my laptop broke down so -1 on productivity currently.

@najtin owns the project

@kolbma didn't respond yet

[tianlinzx]

Thanks for updates.

[somehowchris]

BTW @SergioBenitez is back at it, so I guess the effort was for nothing and the org can be closed

[snaggen]

But didn't his sudden silence put the spotlight on a single point of failure? Wouldn't it be a good idea if he could take ownership of the org and move his development there.

Wouldn't that make it easier to get more contributions to the project?

[somehowchris]

Yes, I asked him the same question. He read the message and ignored it. As always.....

[commandline-be]

Certainly also with Rocket/Rust more does not mean better. Surely it would makes sense to not have this project depend on one person. But it is his code he shares with the world. People can always fork and write on improvements on their own while giving back to upstream Rocket (this repo) where Sergio Benitez is then at liberty to accept, refuse, improve that code. Just my thoughts on the topic. I think that's how it is i supposed to work and supposed to work best. Personally i think forks can happen for just a few reasons: the need for a copy [ continuity] , building on code to build something different [ evolution ], keeping a codebase from going stale or miss out on patches (example: security) [ improvement ] At this point in time i think for the community it would be more interesting to think about how to fund Rocket rather than to fork I mean, mabye Sergio went pole-dancing for a few months just to keep Rocket going, who knows, open source people are very smart and comitted to deliver. Br, JL

…

On Thu, 2022-02-17 at 08:11 -0800, Mattias Eriksson wrote: But didn't his sudden silence put the spotlight on a single point of failure? Wouldn't it be a good idea if he could take ownership of the org and move his development there. Wouldn't that make it easier to get more contributions to the project? — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.

[viniciusd]

You might be missing the point. Most of the discussion about having an organization was not merely about having more people, but actually about reducing the bus factor and making it easier to move forward if Sergio isn't able to keep the project going in the future.

[nathanielford]

And, for that matter, the single solid concern raised was not necessarily about moving anything forward, but about having a method by which security or other critical patches could be applied even when/if the lottery factor comes into play.

[somehowchris]

@commandline-be again you are missing the point, pointing unnecessary things out. It’s not just about funding, forking to have one or Sergio having a small break.

@SergioBenitez just went offline for more than 6 months. With 0 to a few messages signaling his return until yesterday. None, like nobody else was able to communicate/signal something. This isn't a small project anymore, people were asking all over the place "Why is there no movement?", "Why doesn't this project adopt....", "Should I really use it?".

Again this sounds very negative. But Sergio did a great job. Not only on creating a charming project but he went on and made a name. There were some other maintainers, but everything just went the other way.

Ok, so It happened. Why does this all matter?

Me as a person, as a tech enthusiast. I love rocket; I have it in many projects, from raspberry pi's collecting data in my house to servers managing some my apartment.

As a business person, it looks really different. If I do something, what's going to happen if some security risk arises? What's going to happen if there's a shiny new tech on the block and that framework just doesn't work with it? A lot of concerns with npm module or dotnet nuggets can't happen as we will have the code as long as crates.io exists. To a certain degree we can control security risks with overwriting dependency versions but we can not change rocket if some dependency crate changes its type defintion....which would break rocket. A maintainer returning and acting like nothing happened is just one more risk. A maintainer returning and then neglecting that there needs to be some more people around this project is another.

Then why are you @commandline-be missing on the point?

I personally messaged him on element and via mail. Every time I messaged in the group chat, he responded, messaged him personally, he didn't. He never responded on one of these threads too. I offered him to help, asked him if anything would be missing for the project. He just committed some more code, read the message; and that's it...

(The fork didn't fail, we just never really started and Sergio never pointed out that something like funding is an issue; if it would be, he would have a huge stage and people like myself would love to help out.)

Though this all sounds very negative (and for business reasons I have to reconsider my choices) it's a very well done project and if Sergio really gets back and addresses this point it will all be a thing of the past. Looking forward I hope for the best and may Sergio get better and return.

[nathanielford]

The above is an unprofessional post. I think we can all do better than ad hominem attacks, belittling and guilt-tripping. I would like to see the Rocket community be one noted for its friendliness, so I would ask that we avoid these things going forward. I'd also put in a gentle reminder that no one is owed anything here. In particular Sergio is free to choose his priorities with this project, and making assumptions as to why will only work against us. Personally, I think he is wisely choosing to focus on technical leadership rather than embroiling himself in this thread.

[commandline-be]

Read my earlier comments, this played out as expected Verzonden met ProtonMail Mobile \-------- Oorspronkelijk bericht -------- Aan 17 feb. 2022 18:15, Vinícius Dantas < ***@***.***> schreef:

You might be missing the point. Most of the discussion about having an organization was not merely about having more people, but actually about reducing the bus factor and making it easier to move forward if Sergio isn't able to keep the project going in the future. — Reply to this email directly, [view it on GitHub][], or [unsubscribe][]. Triage notifications on the go with GitHub Mobile for [iOS][] or [Android][]. You are receiving this because you were mentioned.![AID7C3MPMN5KT32KDKJCSTLU3UUMTA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAQYZAY.gif][]Message ID: ***@***.***>

[view it on GitHub]: #2011 (reply in thread) [unsubscribe]: https://github.com/notifications/unsubscribe-auth/AID7C3PMOVVS2SZDSZH7QRTU3UUMTANCNFSM5JV4JUVA [iOS]: https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 [Android]: https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub [AID7C3MPMN5KT32KDKJCSTLU3UUMTA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAQYZAY.gif]: https://github.com/notifications/beacon/AID7C3MPMN5KT32KDKJCSTLU3UUMTA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAQYZAY.gif

[commandline-be]

To tead you think of yourself as a tech and a business person to also read you rant about my proposition to fund rather than fork is hard to digest. Forks fail without funding. This great community does not exist or the fork would have succeeded and were thriving already. Hence a successful fork requires funding so people can dedicate time to work on projects not spare time. Verzonden met ProtonMail Mobile \-------- Oorspronkelijk bericht -------- Aan 18 feb. 2022 07:40, Christof Weickhardt < ***@***.***> schreef:

***@***.***[commandline-be] again you are missing the point and like a little child you are pointing unnecessary things out. It’s not about funding, just forking to have one or Sergio having a small break. ***@***.***[SergioBenitez] just went offline for more than 6 months. With 0 to a few messages signaling his return until yesterday. None, like nobody else was able to communicate, signal something. This isn't a small project anymore, people were asking all over the place "Why is there no movement?", "Why doesn't this project adopt....", "Should I really use it?". Again this sounds very negative. But Sergio did a great job. Not only on creating a charming project but he wen't on and made a name. The one thing he didn't like to thing about is having co-maintainers. At this point in time I believe it's not a "I missed it" but rather a psychological (ADD) extrovert thing on not liking to share things. As I do not know Sergio personally, that's just an assumption. Ok so It happened. Why does this all matter? Me as a person, as a tech enthusiast. I love rocket, I have it in many projects, from raspberry pi's collecting data in my house to servers managing my wealth. As a business person, its looks really different. If do something, what's going to happen if some security risk arises? What's going to happen if there's a shiny new tech on the block and that framework just doesn't work with it? A lot of concerns with npm module or dotnet nuggets can't happen as we will have the code as long as crates.io exists. To a certain degree we can control security risks with overwriting dependency versions but we can not change rocket then if some dependency crate changes it's type defintion....which would break rocket. A maintainer returning and acting like nothing happened is just one more risk. A maintainer neglecting that there needs to be some more people around this project is another. Then why are you ***@***.***[commandline-be] totally missing on the point? I personally messaged him on element and via mail. Every time I messaged in the group chat, he responded, messaged him personally, he didn't care less. I offered him to help, asked him if anything would be missing for the project and just yesterday evening asked him if he fixed the single point of failure thing. He couldn't care less. He just committed some more code and read the message; and that's it... Currently I'm considering to move all my projects off of Rocket — Reply to this email directly, [view it on GitHub][], or [unsubscribe][]. Triage notifications on the go with GitHub Mobile for [iOS][] or [Android][]. You are receiving this because you were mentioned.![AID7C3KSYHYD5YYGPER6CJLU3XSXXA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAQZVHA.gif][]Message ID: ***@***.***>

[commandline-be]: https://github.com/commandline-be [SergioBenitez]: https://github.com/SergioBenitez [view it on GitHub]: #2011 (reply in thread) [unsubscribe]: https://github.com/notifications/unsubscribe-auth/AID7C3N3YYUYZ7A3CJHQUHDU3XSXXANCNFSM5JV4JUVA [iOS]: https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 [Android]: https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub [AID7C3KSYHYD5YYGPER6CJLU3XSXXA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAQZVHA.gif]: https://github.com/notifications/beacon/AID7C3KSYHYD5YYGPER6CJLU3XSXXA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAQZVHA.gif

[viniciusd]

Forks fail without funding.

No one so far has proposed simply a fork. All the discussions have been deeper than that, stating we were discussing simply forking and moving on is oversimplifying it. You are missing the forest for the trees.

Most of us will probably agree that funding is important and an interesting avenue to pursue, but it is perpendicular to most of what has been discussed. It is not an either-or situation, they complement each other.

[commandline-be]

It is what happened. Verzonden met ProtonMail Mobile \-------- Oorspronkelijk bericht -------- Aan 18 feb. 2022 14:49, Vinícius Dantas < ***@***.***> schreef:

> Forks fail without funding. No one so far has proposed simply a fork. All the discussions have been deeper than that, stating we were discussing simply forking and moving on is oversimplifying it. — Reply to this email directly, [view it on GitHub][], or [unsubscribe][]. Triage notifications on the go with GitHub Mobile for [iOS][] or [Android][]. You are receiving this because you were mentioned.![AID7C3OSHFYKVXOMMQDSJGTU3ZFAHA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAQ2JNI.gif][]Message ID: ***@***.***>

[view it on GitHub]: #2011 (reply in thread) [unsubscribe]: https://github.com/notifications/unsubscribe-auth/AID7C3KPDEIEVPYHJ5LI3K3U3ZFAHANCNFSM5JV4JUVA [iOS]: https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 [Android]: https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub [AID7C3OSHFYKVXOMMQDSJGTU3ZFAHA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAQ2JNI.gif]: https://github.com/notifications/beacon/AID7C3OSHFYKVXOMMQDSJGTU3ZFAHA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAQ2JNI.gif

[tianlinzx]

Finally , the hero SergioBenitez is back!

[somehowchris]

Well not really my business what you do. But using cloud scalability its a best practice to have at max 1 core per process. Using Tokios multi-threaded capabilities I do not see the need for an explicit actor model

[nicoburns]

@somehowchris Actix-web does scale better than the rest. It has nothing to do with the actor model (which actix-web doesn't really use anymore). It's because Actix-web uses multiple single-threaded tokio reactors (1 per core) rather than a single multi-threaded work-stealing reactor. And the former is more efficient. Pretty unlikely that this is your bottleneck though.

[somehowchris]

Well, @nicoburns scaling APIs on cloud infra has nothing to do with matching threads per core as much of the infra is over subscribed and has noisy neighbors syndrom. Cloud native applications (designed after the 12 factors) use 1 thread (in terms of compute time, that's max 1 core). Scaling has much more to do with reuse, modularity and actually scaling app instances, not tokio reactors. More on DX such as ease of reading, more text means more to read, less to read usually means more to learn.

I DO NOT say that actix-web is trash or something. Its just by design worse than axum as axum is just so well balanced

[mattfbacon]

Having multiple threads does not mean that each thread will run on a separate core. It just means that the OS is free to multitask as it desires. So having threads is almost always net positive.

[somehowchris]

yes. @nicoburns mentioned that its a 1:1 for actix special handling for multi core things, so I do not see that as a benefit. again cloud infra is messed up. this means unerlying vms and containers are also restrained by the power of the cpu in terms of context switching, which needs a lot of cpu cache which then means keeping track of a lot of threads is either harder or slower.
I'm not a hardware masters in my 9-5, so no guarantee that this is 1:1 sound with how an engineer would describe it.

[commandline-be]

You can always try and rally people to help work on this issue to get WebSocketq to work at a production ready level. #1639 \- - - ***@***.*** \-------- Oorspronkelijk bericht -------- Aan 7 apr. 2022 01:50, Matt Fellenz < ***@***.***> schreef:

Actix Web is a great alternative. A lot of Rocket's architecture is inspired by it. That said, to me Rocket seems a lot simpler and more straightforward compared to Actix Web which is why I like it so much. I'm sad to have to use Actix Web, but between lack of important features (WebSockets, Unix socket listening) and inadequate maintainership I don't feel like I have much of a choice. — Reply to this email directly, [view it on GitHub][], or [unsubscribe][]. You are receiving this because you were mentioned.![AID7C3J4MVJPVVVNDBHZPGDVDYPMTA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAATHGBA.gif][]Message ID: ***@***.***>

[view it on GitHub]: #2011 (reply in thread) [unsubscribe]: https://github.com/notifications/unsubscribe-auth/AID7C3NFBPF4UNPYMMZDEP3VDYPMTANCNFSM5JV4JUVA [AID7C3J4MVJPVVVNDBHZPGDVDYPMTA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAATHGBA.gif]: https://github.com/notifications/beacon/AID7C3J4MVJPVVVNDBHZPGDVDYPMTA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAATHGBA.gif

[mattfbacon]

The problem with Rocket + WebSockets is not lack of effort. It's that the Rocket architecture doesn't have a good way to insert WebSocket handlers. Whereas Actix is perfect for it with its actor-based architecture.

[commandline-be]

Thanks for pointing this out. My impression was the developers are on track and know how to iron things out yet require more time and resources to achieve a workable approach. There's no shame in this so helping hands seemed like a sensible thing to suggest. \- - - ***@***.*** \-------- Oorspronkelijk bericht -------- Aan 7 apr. 2022 02:12, Matt Fellenz < ***@***.***> schreef:

The problem with Rocket + WebSockets is not lack of effort. It's that the Rocket architecture doesn't have a good way to insert WebSocket handlers. Whereas Actix is perfect for it with its actor-based architecture. — Reply to this email directly, [view it on GitHub][], or [unsubscribe][]. You are receiving this because you were mentioned.![AID7C3KOY5ZIPRSM6Z2OIV3VDYSAVA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAATHGUI.gif][]Message ID: ***@***.***>

[view it on GitHub]: #2011 (reply in thread) [unsubscribe]: https://github.com/notifications/unsubscribe-auth/AID7C3IOVSCC7H2VKEAQKNTVDYSAVANCNFSM5JV4JUVA [AID7C3KOY5ZIPRSM6Z2OIV3VDYSAVA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAATHGUI.gif]: https://github.com/notifications/beacon/AID7C3KOY5ZIPRSM6Z2OIV3VDYSAVA5CNFSM5JV4JUVKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAATHGUI.gif