zlacker

[parent] [thread] 3 comments
1. throwa+(OP)[view] [source] 2024-01-20 05:14:26
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)

replies(1): >>tgv+X9
2. tgv+X9[view] [source] 2024-01-20 07:47:10
>>throwa+(OP)
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.
replies(1): >>throwa+Bc
◧◩
3. throwa+Bc[view] [source] [discussion] 2024-01-20 08:27:26
>>tgv+X9
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.

replies(1): >>wredue+Ta1
◧◩◪
4. wredue+Ta1[view] [source] [discussion] 2024-01-20 16:44:03
>>throwa+Bc
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.

[go to top]