Software Engineer and full-time Rustacean. While Rust is my primary language, I am also fluent in Python and Typescript. I'm also currently making a game with Godot using C#.
I wouldn't say that "async-std is the final evolution of Tokio". They are both in some sense competitors and in another sense merely alternatives with slightly different philosophies, strengths and weaknesses. There is passion on both sides which is (I think) overall positive for the community. Personally I've used tokio a little more but I'm keen to try out async-std a bit too once its ecosystem matures a little. So far I haven't found a http client as capable as reqwest (which is built on hyper/tokio) on the async-std side but hopefully that will change soon. Currently looking at surf but it still has quite a way to go in terms of ergonomics and usability I think.
For servers I've used rocket including for a real project at work and it has been running solid for a good 6 months now. I highly recommend watching the youtube talks by its author to learn about all of the ways rocket is designed to prevent you from making common mistakes, while reducing boilerplate as well. I've also used diesel a lot too, and it is fantastic. The ability to have your queries checked at compile time is amazing and saves so much time. In addition to these I've played with websockets both with the websockets and tungstenite crates, and that has been pretty awesome.
One of my more recent projects is a small online multiplayer game - originally written in javascript, then ported to typescript, and recently I converted the server entirely to Rust using async/await. It talks to a typescript client using raw websockets (no socket.io layer) and that actually works pretty well. There are some interesting performance challenges to deal with when interfacing between javascript async/await and Rust's async/await in a game loop running at 30 fps on both server and client. Actually the client runs at 60fps but I only send inputs every second frame. So far it works very well.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I wouldn't say that "async-std is the final evolution of Tokio". They are both in some sense competitors and in another sense merely alternatives with slightly different philosophies, strengths and weaknesses. There is passion on both sides which is (I think) overall positive for the community. Personally I've used tokio a little more but I'm keen to try out async-std a bit too once its ecosystem matures a little. So far I haven't found a http client as capable as reqwest (which is built on hyper/tokio) on the async-std side but hopefully that will change soon. Currently looking at surf but it still has quite a way to go in terms of ergonomics and usability I think.
For servers I've used rocket including for a real project at work and it has been running solid for a good 6 months now. I highly recommend watching the youtube talks by its author to learn about all of the ways rocket is designed to prevent you from making common mistakes, while reducing boilerplate as well. I've also used diesel a lot too, and it is fantastic. The ability to have your queries checked at compile time is amazing and saves so much time. In addition to these I've played with websockets both with the websockets and tungstenite crates, and that has been pretty awesome.
One of my more recent projects is a small online multiplayer game - originally written in javascript, then ported to typescript, and recently I converted the server entirely to Rust using async/await. It talks to a typescript client using raw websockets (no socket.io layer) and that actually works pretty well. There are some interesting performance challenges to deal with when interfacing between javascript async/await and Rust's async/await in a game loop running at 30 fps on both server and client. Actually the client runs at 60fps but I only send inputs every second frame. So far it works very well.