4 ms·
Immutability is great for multithreaded/async programs because every thread can rest assured knowing no other thread can sneakily modify objects that they are o
by polygamous_bat 3y ago
Immutability is great for multithreaded/async programs because every thread can rest assured knowing no other thread can sneakily modify objects that they are operating on currently.
- candiddevmike 3y agoGo can prevent this with the race detector among other things
- stouset 3y agoSometimes.
- binary132 3y agoThe race detector needs to actually encounter a race in order to detect it, it's not a complete static analysis.
- omginternets 3y agoDetectors detect, they don’t prevent. All detectors suffer misses.
- IlliOnato 3y agoHow Haskell deals with access to shared resources which are mutable by their nature, like file system, or the outside world? (A honest question, I start to think that I'd like to learn more on this language)
- andyferris 3y agoAFAIK they tend to operate through the IO monad, which serves to order read/write events and mark parts of your code as interacting with the global mutable state that lives outside your program. So the mutable (or is it “volatile”?) environment is there, but you explicitly know when and where you interact with it.
- whateveracct 3y agoHaskell has full support for IO and mutability. It even has software transactional memory in its standard library.
- wredue 3y agoImmutability is, quite possibly, the dumbest “silver bullet” solution ever to be praised as a solution to anything. Congratulations, nobody is going to sneakily update an object on you, but also, nobody knows about your updates either. It’s not a worthwhile trade off given the massive extra work it causes.
- throwawaymaths 3y agoCompletely uninformed take. Some of the most impressive update notification systems are built off of pass-as-immutable runtimes (for example: phoenix live view + phoenix pubsub). Try implementing that in just about a y other language. You will trip over yourself eight ways to hell The whole idea of CQRS is to build separate (segregated) pathways for updates. Immutable passing plays extremely well with CQRS. The alternative is the complete clusterfuck that is two way data bindings (e.g. out of the box angularjs)
- tgv 3y agoI think you both are referring to the same point: you can't update an immutable object, so you have to set up some mechanism to keep changes in sync.
- throwawaymaths 3y agoYeah, and update mechanisms are not created equal. two way data bindings suck because they elide the challenges of distributed consistency. When you're immutable, you can still delete or replace data.
- wredue 3y agoImmutability “maybe” (and that’s a massive grain a salt, because this is not a specific thing I’ve ever worked on to say any different) having certain use cases where it works well is not the same thing as making literally every single object in your entire application immutable. I agree that immutability is a tool. My issue with it is when you treat it as a rule.