3 ms·
I'd say it's because it's not obvious in the languages we use what is and is not an atomic operation. Different languages do provide different levels of protect
by jemmyw 3y ago
I'd say it's because it's not obvious in the languages we use what is and is not an atomic operation. Different languages do provide different levels of protection by default as well, making it even harder to know what is and is not safe. Personally when I'm in a language that makes things obvious then it becomes easier to reason about. Rust helps, verbosly. I don't have any problem in JavaScript because the runtime usually doesn't allow for your own code to be running concurrently. Each way here has trade-offs.
- 01HNNWZ0MV43FF 3y agoJavaScript, Lua, and Qt have all given me cases of single-threaded concurrency because you can poll the event loop from inside a function. (I don't remember what loop I was using in Lua) So you don't get memory unsafety (except in Qt) but you do get immutable variables changing when you're not looking at them. Actually maybe it was c#. I wrote a coroutine in c# once and I regret that I did not make it an explicit state machine. Having to re-check all my shared state after each await point made it worthless. Sure state machines look like mashed potatoes compared to "wow it's just communicating processes" threads but it represents the complexity of the program more accurately at a glance. Maybe the domain really is mashed potatoes
- whaleofatw2022 3y agoI mean, the semi fun thing in C# is you can still YOLO the async state machine to where it is clean to consumers, But agree, sometimes to solve the problem best you gotta get dirty.