adamch

I'm glad to see the donations from big companies to open source maintainers are making measurable difference to the Rust experience. Telling these companies that their employees spend 5% less time waiting for compilation might motivate future investment in people like Nick and the others mentioned.

Lovely to see Cloudflare Tunnel frontpage on HN. Working on Tunnel was the highlight of my career. It was a fun product with a lot of bugs to fix, features to add, architecture to design. We were all working in-person, solving incidents together, getting lunch together every day. Taught me so many important skills that have helped me in every other project I've ever worked on.

PRs are welcome.

They'll announce that along with M5 Pro and Max in March or so.

My guess is that users can select a query at runtime, sending it to you via http or any other text.

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).

Wow, I've been using tokio for years and never knew about this. Thanks!

I love ligatures. First thing I do in a new machine is install this font. I won't use a terminal or IDE that doesn't support them.

You don't need a websocket proxy. CF tunnel supports TCP and UDP just fine.

Really excellent simulation and explanation. Thank you!

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.

It's both!

Funny, I know a decent amount about k8s these days, but I've never really used AWS. I think there's a lot of systems that try to solve the same problems: "define these services, keep them running, here's how to check if they're down, here's how to restart them, keep resource usage to this level." Systemd, kubernetes, and individual cloud providers all have their own way to describe these.

One of the upsides of k8s is that it gives you a general, platform-agnostic way to describe this, on AWS or GCP or self-hosted or whatever. The downside is that it's more flexible and therefore more abstract than any particular provider. The upside is that you only have to learn one set of concepts (in theory).

Update: I did go through every `match` statement in my 16k-line Rust project at work, and I found a number of places where it was useful. My commit to use let-else had 10 files changed, 27 insertions(+), 48 deletions(-).

Except the let-else version has one big disadvantage. The 'match' version has bound the error to `e`, so you can log that error or inspect it. The 'let-else' version can't read the error, so its log message can't be as useful. You can't check if it's a specific error, or include the error in logged messages.

It's still convenient, but in really limited circumstances, AFAICT. This week I'll be going through the various Rust projects I maintain at work, seeing if there's useful places for let-else.

They also received a very large amount of funding from some successful tech founders, Brian Acton and Pavel Durov

I think HPBN and Beej's guide are perfect companions to each other. They've been the most useful resources on my journey to learn more about networking.

This is really noticeable with video chat. I never use Bluetooth when talking with my family... between the Texas - Australia lag and the Bluetooth headphones - Android phone lag, it's enough to impair conversation.

Now the problem is just how to manage all the cables that come from having a gaming PC and work laptop that use the same keyboard and monitor. I have a KVM switch but I can't hide it under the desk if I want to press it.

Hello, friendly Cloudflare employee here... there's a much simpler alternative to managing cache policy if your whole website is static. We built a tool for deploying static websites to Cloudflare [1]. It watches your Git repo for changes, then rebuilds your site and serves _all_ the assets from our edge servers. No need to configure page rules or cache policy, because there's no more origin. The free tier covers 500 builds per month (at most, you'll do 1 build per commit, so you should be covered just fine).

I helped develop Tunnel over the last ~3 years, and I love it, but it's definitely overkill if you just want to serve some static files on the edge.

(Please delete if this goes against HN policy, I'm trying not to be a shill here, just help tristor avoid spending an hour configuring page rules and cache policies)

[1] https://pages.cloudflare.com/