rust-playground VS tokio

Here's an example I threw together: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Hopefully that gets the gist of how you might approach it. I'm not sure I'd use the HashSet myself, to be completely honest, because it makes it needlessly complicated to get an element out of it. I'd probably just use a Vec.

If you have a StackOverflow account, consider asking it there instead! StackOverflow shows up much higher in search results, so having your question there also helps future Rust users (be sure to give it the "Rust" tag for maximum visibility). Note that this site is very interested in question quality. I've been asked to read a RFC I authored once. If you want your code reviewed or review other's code, there's a codereview stackexchange, too. If you need to test your code, maybe the Rust playground is for you.

Well if it's easy, why don't you do it :-) https://github.com/integer32llc/rust-playground/issues/544

alternative

+1 for Axum. I recently moved [1] the Rust Playground's backend to Axum and have been very happy with it and the team producing it.

[1]: https://github.com/integer32llc/rust-playground/pull/777

As other people have mentioned, the Docker image is not created at code submission time. Instead, each of the six images are built each night and uploaded to Docker Hub. During the build, we do some trickery to compile all of the dependencies so that they are ready to go later on. The playground machines try to pull these containers every so often (30 minutes, IIRC).

I was looking into the source code of the rust playground but I'm not sure how it really works, It creates, build and runs a docker container with the code send for each request?

File an issue here, perhaps?

This PR says it's the first stage of https://github.com/integer32llc/rust-playground/issues/357 where this is discussed.

The main focus of the CLI tool would be around working on filesystem, and also making several network requests simultaneously. Although some may argue it would be easier/faster writing in other languages, this is more for my own learning to write in Rust. It will be a simple toy project at first, but I'd like to prepare for more complex Rust programming in the future with it. For instance, I see different directory / file / module structures used, Rust version / edition differences here and there, some common dependencies such as Tokio, etc.

Our project is based on Tokio, which conveniently encapsulates cooperative task running and scheduling in .await calls. However, users who are unfamiliar with the underlying principles may encounter issues and obstacles.

Ah yes, std, that famous crate that is unusable for systems programming. God forbid anyone do any "systems" programming that uses std.

Tokio

The tokio project provides a non-blocking, asynchronous framework (like nodejs) upon which other frameworks are built. As you specifically want to use WebSockets, I'd recommend actix, as it covers all your REST/WebService/WebSocket needs in one easy to use package.

staticpi, is a websocket forwarding service. Basically, it enables one to keep a Raspberry pi, or any computer, “connected”, in order to send and receive messages to and from any client, without having to deal with a static IP address, open ports on your router, or similar. Built in Rust, using axum, which in turn uses tungestine-rs for the websocket connections, tokio, sqlx, redis-rs and others.

I'd highly recommend checking out Rust if you haven't already. There's some great resources for full stack web development with it. Such as tokio and dioxus.

It's still a possibility, and I remember a discussion somewhere in the Tokio community in which they wanted to solve potential blocking in this and similar combinators reliably by having "leaf" streams return Poll::Pending once in a while even when the stream is ready. See also this PR providing a cooperative solution.

There's now also consume_budget (PR #4498) for tasks that don't need any Tokio-managed resources to opt-in to cooperative scheduling anyway.

Not all projects want semver-minor lints. That's fine! Tokio started using cargo-semver-checks and wanted to disable minor lints, and the new --release-type flag allows doing that — see the link above for details.