zlacker

>>lukast+(OP)
When writing some IO bound application, async Rust is great. Less great for libraries that want to support both async and sync without having to make an async runtime a dependency if you just want the sync interface. Mutually exclusive features are taboo unfortunately. One thing I really love about Haskell is you can make any function run in a green thread by simply composing it with the 'async' function. There's nothing special about it. This works much better than say Go, because Haskell is immutable.

>>xedrac+zh
I'm not clear what your last sentence has to do with anything else? What does immutability have to do with Async/sync conversions?

>>XorNot+ri
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.

>>polyga+Ol
Immutability 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.

>>wredue+pD
Completely 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)

>>throwa+zN
I 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.

>>tgv+wX
Yeah, 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.

>>throwa+a01
Immutability “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.