This is a weird article. It starts off with Golang, then presents the alternative "Software Transactional Memory (STM)" which appears to be a Haskell feature.
Mutexes have lots of issues, as mentioned. Some are mitigated in other languages, like Rust, which gates access to the data in the mutex via the lock and disallows mutation for shared (multithreaded) data without a mutex.
STM sounds interesting, but it doesn't really seem different to me from a mutex. I'm not very familiar with Haskell, but AFAICT you still need to decide on a call tree root that does the commit, functions can't be blindly composed. I guess if there's an error nothing happens, but I doubt that's a magic bullet when you're dealing with external systems like processes, databases, etc (i.e. if the STM fails to commit, the database could then go out of sync with memory).
This is a weird article. It starts off with Golang, then presents the alternative "Software Transactional Memory (STM)" which appears to be a Haskell feature.
Mutexes have lots of issues, as mentioned. Some are mitigated in other languages, like Rust, which gates access to the data in the mutex via the lock and disallows mutation for shared (multithreaded) data without a mutex.
STM sounds interesting, but it doesn't really seem different to me from a mutex. I'm not very familiar with Haskell, but AFAICT you still need to decide on a call tree root that does the commit, functions can't be blindly composed. I guess if there's an error nothing happens, but I doubt that's a magic bullet when you're dealing with external systems like processes, databases, etc (i.e. if the STM fails to commit, the database could then go out of sync with memory).
Rolling back STM transactions is where the horror occurs. The OP's solution (infinite retries) doesn't really seem sane or sensible.
hell yes