<div dir="auto">I haven’t used Async-Await ever, so the following will probably be moot. But here I go:</div><div dir="auto"><br></div><div dir="auto">I learned concurrency at Uni with C#. Most of it was meh/okay. The gist of it is this:</div><div dir="auto">- You have instances of Threads. Each one recieves a function to start in. When they return, they end.</div><div dir="auto">- Threads can be synchronized with “locks”. Basically, mutex.</div><div dir="auto">- Threads can be syncronized with Monitors (idk how they work, it was kinda cumbersome when I was taught).</div><div dir="auto"><br></div><div dir="auto">And finally, a golden nugget:</div><div dir="auto">- Threads can wait for signals/events. Signals are doors where threads wait for someone to open the door and let them keep going.</div><div dir="auto">Signals can be resat automatically (letting only one thread pass before locking again) or manually.</div><div dir="auto">Their design is pretty nice because they are a lot like single UI event-driven tools (from reactive programming).</div><div dir="auto"><br></div><div dir="auto">Everything else in C# threading at the time was pretty much meh. And error-prone, if you only used locks. But I think Signals were a golden nugget in a way. How would they fare in current multithreaded programming? Idk. I have to read a lot about the state of the art now.</div><div dir="auto"><br></div><div dir="auto">Thanks Chris for your manifesto. I’m reading it right now :)</div>