pollster
pollster | storages-api | |
---|---|---|
3 | 5 | |
443 | 9 | |
- | - | |
3.6 | 0.0 | |
6 months ago | 8 months ago | |
Rust | Rust | |
Apache License 2.0 | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pollster
-
Rust criticism from a Rustacean
Other than that, I'm using async mostly not in a web-based environment, unlike your assumption that the "so-called web-devs" only want to use it. It's also quite flexible, you want it blocking? Start a blocking executor. You don't want tokio for that? Use a minimal executor like https://github.com/zesterer/pollster for that...
-
Fellow Rust enthusiasts: What "sucks" about Rust?
Check out https://github.com/zesterer/pollster. This can be the solution to the async problem you described
-
Tachyonix: a very fast MPSC async bounded channel
Pollster: https://github.com/zesterer/pollster
storages-api
-
What’s the status of the Storage proposal?
I think here you can find the new repository as there are commits from yesterday. Also this is probably the most recent discussion about the proposal.
-
Fellow Rust enthusiasts: What "sucks" about Rust?
I believe SSO could be solved, in part, with the Storage proposal I made a while ago, which Christopher Duram refined in his storages-api repository.
-
Taking ownership of memory, how straightforward is it?
/u/CAD97 is currently exploring whether storages would be a better alternative: feasibility, API impacts, etc... for example see https://github.com/CAD97/storages-api for a much revised API compared to my initial proposal.
-
Specialized Allocators for containers
This sounds like a less refined version of the storages API: https://github.com/CAD97/storages-api
-
The Better Alternative to Lifetime GATs
The unfortunate asterisk to this is my work on the Storage api; with that abstraction Vec itself could be the small vector type rather than duplicating the entire API onto a second type.
What are some alternatives?
tachyonix - An asynchronous, multi-producer, single-consumer (MPSC) bounded channel that operates at tachyonic speeds
tinyvec - Just, really the littlest Vec you could need. So smol.
getrandom - A small cross-platform library for retrieving random data from (operating) system source
dislike-in-rust - A list of the few things I don't like about rust
rust-delegate - Rust method delegation with less boilerplate
storage - An exploration of Storages
any_vec - Rust type erased vector.
SHLL - An experiment of high level code optimization
unsafe-code-guidelines - Forum for discussion about what unsafe code can and can't do
rust-orphan-rules - An unofficial, experimental place for documenting and gathering feedback on the design problems around Rust's orphan rules
rust - Empowering everyone to build reliable and efficient software.