zlacker

[parent] [thread] 8 comments
1. wredue+(OP)[view] [source] 2024-01-20 03:10:20
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.

replies(3): >>throwa+aa >>Fire-D+Fc >>whatev+7H1
2. throwa+aa[view] [source] 2024-01-20 05:14:26
>>wredue+(OP)
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+7k
3. Fire-D+Fc[view] [source] 2024-01-20 05:48:22
>>wredue+(OP)
Immutability frees the mind from so much baggage when developing that i'm always shocked it didn't become mainstream
◧◩
4. tgv+7k[view] [source] [discussion] 2024-01-20 07:47:10
>>throwa+aa
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+Lm
◧◩◪
5. throwa+Lm[view] [source] [discussion] 2024-01-20 08:27:26
>>tgv+7k
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+3l1
◧◩◪◨
6. wredue+3l1[view] [source] [discussion] 2024-01-20 16:44:03
>>throwa+Lm
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.

7. whatev+7H1[view] [source] 2024-01-20 18:37:14
>>wredue+(OP)
> Congratulations, nobody is going to sneakily update an object on you

I've seen Heisenbugs where some random code calls a setter on an object in a shared memory cache. The setter call was for local logic - so immutable update would've saved the day. It had real world impact too: We ordered a rack with a European plug to an American data center (I think a human in the loop caught it thankfully).

Also, how often do you even use mutability really? Like .. for what? Logic is easier to express with expressions than a Rube Goldberg loop mutating state imo.

replies(1): >>wredue+tK3
◧◩
8. wredue+tK3[view] [source] [discussion] 2024-01-21 14:26:22
>>whatev+7H1
>how many Heisenbugs

I suspect, given the real, actual measurements, the number of difficult to deal with bugs is pretty consistent between immutability and mutability. Actual measurements does not support claims of “easier to reason about”, or “reduced bugs”.

>how often do you use mutability

Whenever something should change and I don’t specifically need functionality that immutability might provide (literally 99.99999999% of every state change).

replies(1): >>whatev+gQ3
◧◩◪
9. whatev+gQ3[view] [source] [discussion] 2024-01-21 15:05:12
>>wredue+tK3
I'm just confused as to what you need mutability for exactly? I get needing it for communicating between processes (STM has you covered there). But for "normal" code that is doing pure logic, what is the benefit of using mutability?

Immutability has some big advantages for pure logic, such as allowing containers to be treated as values the same as numbers. And efficient immutable data structures of all kinds are commonplace now.

[go to top]