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?
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.
> 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).
I would choose [axum](https://docs.rs/axum) as my default Rust server framework. It compiles quickly, it's very ergonomic, and it integrates well into the rest of the ecosystem.
Never wrote a Java web server sorry cannot compare.
I would love to use Haskell. The main reason I stopped writing Haskell and started writing Rust was that I could more easily teach new programmers Rust due to better compiler error messages, and Cargo is 10000x easier to use than the Haskell package managers, which never seem to be able to resolve the right set of versions for me.
Being able to write a lot of functional Rust and drop down to imperative/mutation when necessary also eases the curve compared to Haskell.
Hello, author here. My coworker Olivia (of https://losslessbits.com/) really likes SQLx, I haven't personally used it though. I'd love to try it for a future project, as long as it can help typecheck my SQL queries.
I started a personal blog two years ago, roughly. Even if nobody had read it, I'd feel successful, because I only write about things I'm confused about or learned recently. Then I can link them to my coworkers and they get an exact guide about this particular issue.
But, people _have_ actually read it, which is nice. I've hired at least one person through my blog (he emailed me after reading it), and he was awesome to work with. A lot of coworkers have messaged me saying "hey, I was googling for this problem I'm having, and I found your blog, and I realized you work at the company, so thank you!" I've benefited so much from reading developer blogs throughout my career, so it's nice to be able to give back and help others too.
I think it's helped me get better at technical writing and show employers that I can do more than just write code too.
I really like the design of this blog. It's clean and simple but has enough character from the carefully-chosen decorations. The rainbow hyperlinks are a nice touch! Great styling.
This is a really cool feature, thanks very much for adding it. I'd love to see this in more languages. I'd love to use it in my Rust integration tests.
I work on network services, but generally my server's requests start on a user's computer, get to my service, get proxied to some upstream destination elsewhere on the internet, and then the responses flow back. Point is, I work with networks, but generally the latency and throughput is bottlenecked somewhere outside my code. Probably by the user's internet connection, or the server's.
So it was _really_ interesting to listen to this podcast live and think about truly high performance networking. When your requests and responses are all within one rack on your data center, the bandwidth, latency and throughput bottlenecks are MUCH more likely to be your code and hardware. So Oxide has to think about all these high-performance use-cases that I've never once had to stop and think about.
This episode felt like peeking behind the curtain into forbidden knowledge. Great episode.
K8s probably wouldn't make sense for a lot of startups -- it's designed to solve a lot of different problems, and you're probably not going to be interested in solving most of those.
On the other hand, once you know k8s, it means you don't have to learn the specifics of any cloud platform. For most of my career I've worked in places that can't use cloud providers. I honestly dread having to learn all the different GCP or AWS tools/apis at a future job. But now that I have spent a lot of time learning k8s, it's nice to know that I can build on any cloud platform in the future, or self-hosted servers, and reuse the standard k8s APIs that I use at this job.
If I was building a startup, I'd use whatever the majority of engineers were already familiar with -- k8s, aws, gcp, whatever.