-- Leo's gemini proxy
-- Connecting to gemini.tuxmachines.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;lang=en-GB
Tux Machines
Posted by Roy Schestowitz on Jul 01, 2023
> For a while now I've been trying to find a good way to explain what structured concurrency is, and how it applies to Rust. I've come up with zingers such as: "Structured concurrency is structured programming as applied to concurrent control-flow primitives". But that requires me to start explaining what structured programming is, and suddenly I find myself 2000 words deep into a concept which seems natural to most people writing programs today 1.
> Instead I want to try something different. In this post I want to provide you with a practical introduction to structured concurrency. I will do my best to explain what it is, why it's relevant, and how you can start applying it to your rust projects today. Structured concurrency is a lens I use in almost all of my reasoning about async Rust, and I think it might help others too. So let's dive in.
> This post assumes some familiarity with async Rust and async cancellation. If you aren't already, it might be helpful to skim through the earlier posts on the topic.
> A significant portion of cost of software infrastructure at a technology organization is due to CI/CD (Continuous Integration/Continuous Deployment). It is easy to overlook CI cost since CI isn’t strictly required to operate a software application, but it’s a critical component of the software development lifecycle.
> A less obvious aspect of CI cost is that, in some cases, it can increase at a quadratic rate over time. John Micco, the ex lead of the Google Test Automation Platform group, mentioned that Google would spend more on CI than the rest of its compute combined if it didn’t introduce serious optimizations along the way.
> For example, we use the phrase “teaspoon languages” and not “teaspoon programming languages.” The term “teaspoon” comes from the shorthand “TSP” for “Task-Specific Programming.” So, the “programming” bit is already in there. But in particular, I don’t want to generate the reaction, “But, hey, that doesn’t look like a real programming language…”
> Harold Abelson once said that code should be written for humans to read and only incidentally for computers to write. It follows that, like any form of communication, code can carry emotions. Programming perversity, then, is code that conveys morbid fascination, the kind of amused horror where you cover your eyes but peek through your fingers. Take some innocuous features of a programming language and then bend it all into a pretzel. Congratulations, you've made performance art.
> Over the last week, I have been working with contributors on new documentation and charting a path toward deprecating Python 2 support, which was consumed by a few applications. Indeed, backwards compatability has been at the heart of microformats: standards require long-term, robust support. We collectively decided that the work required to maintain support would have been extensive, while holding us back from taking on an important task: modernize the library.
-- Response ended
-- Page fetched on Thu Jun 13 07:08:41 2024