Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Well....
All things are transactional as long as they're not atomic.
It's just that you can ignore this fact till you need to be aware of it and it rubs a cheese grater through your face...
I think that sums up the experience most people have when having to deal with state's, locking, threading, async, and all the other joyful stuff. -
@IntrusionCM In JS all computations are atomic, the problems start when you have to consult the network.
-
@IntrusionCM It's async alright, but an assertion remains true until I willingly yield control. Collisions are imminent and often elusive because of the highly variant network delay, but they are easy to detect and handle in the code.
-
@IntrusionCM the various strategies of propagating state in single threaded code were the object of this rant, and I used the word mutex to refer to devices of mutual exclusion in the broad sense.
Related Rants
This had to be posted!
Nowadays......¯\_(ツ)_/¯
Ever since I started learning about React with Typescript my respect for design patterns that restrict how state can change has grown massively. On the web, nothing happens when you say it should happen; everything always takes a while to execute and there is always a transactional period between validating an action with client-side state and receiving the result from the server, and if you want to account for that everything becomes infinitely more complex and you eventually end up with mutexes.
rant
ts
network delay
state
react