You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Yes, it is related to a performance and ergonomics issue. Currently, RustScan uses async_std for asynchronous programming. While async_std is a great library, it has been observed that Tokio provides better performance and more ergonomic APIs in some cases.
Describe the solution you'd like
I would like RustScan to switch from async_std to Tokio for handling asynchronous tasks. This would involve refactoring the existing code that uses async_std to use Tokio instead. The goal is to improve the performance of RustScan and make the internal code more ergonomic (highly opinionated).
Describe alternatives you've considered
An alternative would be to continue using async_std and try to optimize the current implementation. However, given the reported performance and ergonomic advantages of Tokio, switching to Tokio seems pretty promising.
Additional context
For users who use this crate as a library, users of async std would not be able to use it, although tokio users would benefit greatly as there is no longer a need to startup an invisible background async_std runtime, and given that tokio is much more popular I belive this is worth it
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Yes, it is related to a performance and ergonomics issue. Currently, RustScan uses async_std for asynchronous programming. While async_std is a great library, it has been observed that Tokio provides better performance and more ergonomic APIs in some cases.
Describe the solution you'd like
I would like RustScan to switch from async_std to Tokio for handling asynchronous tasks. This would involve refactoring the existing code that uses async_std to use Tokio instead. The goal is to improve the performance of RustScan and make the internal code more ergonomic (highly opinionated).
Describe alternatives you've considered
An alternative would be to continue using async_std and try to optimize the current implementation. However, given the reported performance and ergonomic advantages of Tokio, switching to Tokio seems pretty promising.
Additional context
For users who use this crate as a library, users of async std would not be able to use it, although tokio users would benefit greatly as there is no longer a need to startup an invisible background async_std runtime, and given that tokio is much more popular I belive this is worth it
The text was updated successfully, but these errors were encountered: