This is interesting. But how would you use it? You'd need to open up a new type of socket (neither TCP nor UDP but nyxpsi) and everything along your network route would need to support it. So it wouldn't be useful with existing mobile networks (middle boxes won't speak the protocol) nor within the data center (because it's used for high packet loss situations). So what's the use case? Custom wireless networks with embedded devices?
You'll still run into trouble with anything wanting to allow everything but trying to do NAT. I'd hazard to guess this actually still uses UDP under the covers for that reason (but haven't bothered to verify). QUIC and HTTP/3 went that route for the same reason.
I didn't mind the controls, they were somewhat clunky but fine once you got used to them.
The game suffered imo because the puzzles had nothing to do with the story. They felt arbitrary and disconnected from the world, unlike the puzzles in Myst. Solving them never felt very intriguing, I was motivated to solve them just because that's what you have to do to finish the game, rather than motivated to solve them because they were interesting.
There are some CF SWEs in Australia. But few teams are willing to work across 3 timezones. The SRE teams might be more open to hiring, as there's a big SRE presence in Singapore.
Nice job! I'm glad the team was able to ship a useful subset of the desired functionality. Yes the current implementation shipping next week has limitations, but they're clearly marked, the compiler helpfully explains them and warns you away from some sharp edges.
I'm glad the Rust project is willing to ship useful but limited features quickly, see how people use them, and then iterate and slowly remove the restrictions in the future. I think it'll be more productive than taking another 3 years to solve all the remaining rough edges and problems.
In general, Rust should commit more to stabilizing important features like this. I think because of how easy it is to switch to nightly, there isn't as much pressure to stabilize features as there should be.
> tokio uses a 'static, threaded runtime that has its benefits but requires its futures to be Send and 'static.
This is only partly true -- if you want to `spawn` a task on another thread then yes it has to be Send and 'static. But if you use `spawn_local`, it spawns on the same thread, and it doesn't have to be Send (still has to be 'static).
the audience probably feels more comfortable working with technologies that have a "web" prefix and or can be deployed to a shared webhosting account aka cloud
