mre

Many moons ago, I hacked together a similar app with Python [1]. It broke because of some MacOS changes and ever since then I hoped that someone would build a "native" alternative with Swift. Good job! Now I can finally point people there and archive my repo.

[1]: https://endler.dev/2020/timelapse/

Hey, host here. Thanks for sharing this. I started the podcast because I was looking for some real-world Rust stories and couldn't find much; so I started 'Rust in Production'. It is closely modeled after the 'On the Metal' podcast by Oxide Computer (https://oxide.computer/podcasts/on-the-metal).

Should anyone have thoughts on potential guests or know someone who would be an incredible guest, I'd love to hear about it.

Yes. Brings back some memories.

I've used Tree Style Tab before and switched to Sidebery (https://addons.mozilla.org/en-US/firefox/addon/sidebery/). Never used Vivaldi, but you might want to give that a try. It works well in combination with container tabs.

Author here. The link is fixed thanks to M3t0r on GitHub: https://github.com/corrode/corrode.github.io/pull/6 The source code of the blog is open source. Contributions like these are very welcome.

The idea is that tools for all programming languages are accepted. If there's a missing tool, you can contribute by opening a pull request.

Maintainer here. Thought we fixed that. I'll look into it.

Great point! That could be the subject of a follow-up article. Noted!

Author here. It took me about 2 hours to code the Go service and maybe 4 to do the Rust part. The reason why Rust took longer was mainly because of the better error handling and the few more higher level abstractions. I could have added unwraps everywhere to get about the same experience, but yeah.

Indeed, while the Send bound can safeguard against potential concurrency issues, it also dictates a specific architectural direction for applications. Consider a web server: with the Send bound, you might be encouraged to design it such that each incoming request is handled by potentially any thread in a thread pool. Without that bound, you might lean towards a more lightweight, single-threaded model similar to Node.js, which doesn't require Send bounds and still excels at handling I/O-bound tasks.

"Doing the right thing" can vary based on the context. For instance, in embedded systems where threads aren't available, requiring futures to be Send is unnecessary. Thankfully, the standard library does not enforce this and neither does Tokio with spawn_local, but embassy exists because there's a genuine need for async frameworks tailored to the unique constraints and requirements of embedded systems.

Go doesn't have native async support per se, but its approach to concurrency with goroutines and channels simplifies the process considerably. Synchronous code resembles asynchronous code, eliminating the need to isolate goroutines.

Rust, on the other hand, took a different route. Green threads don't integrate smoothly with code interfacing through FFI. Moreover, Rust's async model doesn't require a garbage collector.

There's always a trade-off. By promoting Send futures, Tokio prioritizes safety and parallelism. However, this does add complexity for developers, especially newcomers. They need to be aware of the Send and 'static requirements and might have to use synchronization primitives more often. Because of this, I think promoting Send futures as the default is the wrong way to go.

LocalSet + spawn_local are great, and I wish more developers would know about them, but the Tokio tutorial [1] doesn't mention that and focuses on the multi-threaded runtime instead. AFAIK LocalSet is only mentioned in the docs [2]

[1]: https://tokio.rs/tokio/tutorial [2]: https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html

Author here. The benchmark part could be clearer; I acknowledge that.

Interestingly, when working with a limited number of threads, the thread approach is actually faster in that benchmark. So in practical applications, the differences are marginal and likely lean towards threads.

But even if this weren't the case, context matters. A 10ms discrepancy in a web request might be acceptable. However, in a high-performance networking application - which, let's be honest, isn't a common project for most - it could be significant.

Stefan, the author of the course, is hands down one of the best Rust instructors out there. Huge kudos for getting him on board, shuttle.

I used to feel the same way as you about the one-row enter key. However, over time, I've come to prefer the US layout. The main reason is the ease with which I can reach the enter key using my right pinky finger. In fact, I've grown so accustomed to it that I now find the L-shaped layout a bit cumbersome. Funny how preferences change when you give something new a shot!

Maintainer of the list here. Thanks for mentioning it. I have not heard of Microsoft's analyze. Could you paste a link here? I will add it to the list, then. Alternatively you could send a pull request to the repository. ;) https://github.com/analysis-tools-dev/static-analysis

AFAIK Flightradar and some others provide a VIP service for blocking flight data. Elon's Jet is blocked there, too. Ironically, the owner of the elonjet account even told Elon how he could hide flight information on these platforms...

> Last week, Sweeney noticed he couldn't locate Musk's jet, and realized Musk was attempting to hide his flight patterns from the @ElonJet using the blocking software Sweeney had recommended to him.

Source: https://techxplore.com/news/2022-05-college-student-tracks-e...

Apparently they still do [1], even though I have an M1 and never experienced any of the "micro vibrations" that I had on the old Intel Macs.

[1]: https://forums.macrumors.com/threads/macbook-pro-m1-max-almo...

Original author here. Thanks for the submission. I built the service mostly for myself because I have an old Kobo eBook reader and the browser is pretty basic. This works very well, though.

Only after building it I realized that there could be more use-cases; for example when traveling and working from a bad connection. The pages are usually much more lightweight than the original ones and don't contain any trackers.

I don't even have metrics for that service. No idea how many people are using it and I don't care for the most part. That said, if anyone is interested in using the service you can run your own instance and be completely independent.

The code is here BTW: https://github.com/readable-app/readable.

> Stackoverflow is reliably adopting the latest and greatest .NET technology. They are always at the leading edge using early releases of ASP.NET Core. They handle insane amounts of traffic with excellent performance.

I guess that's mostly a testament to the effectiveness of caching. My guess is that 95% (maybe more?) of all the traffic on SO is read-only. A caching-layer like Varnish/Nginx would be performant in front of any backend. We used to have a similar amount of traffic with PHP in the backend and it was just fine.

Fully agree with the rest of the post, though. Keep it simple.

Amen, sister! (In)consolas, sans serif, beautiful.