What's so great about Immutability?

github logo Updated on ・1 min read

Please add to the conversation by writing a little bit about why you feel Immutability is such a good idea. Please!

I recently used an Angular component, whereby it contained a table of data, immutable data. I found out later that the only way to change any row being displayed was to make a copy of the row to be edited by the user, show it in another control, then to mutate the entire collection with the new value inserted once the user made the change.

In the past, we would just mutate the data and save it off to the data store. Never had issues with that in 25+ years.

I feel the work to get the immutable data to mutate was way more work than just changing the row that needed it.

twitter logo DISCUSS (7)
markdown guide
 

by having immutable data you can guarantee atomic access to you application's state. Not only does it means that you will eliminate race conditions where you read a value as it's being changed, you also make it safe to access the same resource from different processes.

 

Jose, does "different processes" mean multiple asynchronous access to the same data?

 

That's right. In the browser/node this can happen due to async stuff like promises resolving at different times.

By the by, your table data structure may be the wrong one–it sounds like changing a row was not easy. You may want an immutable tree structure to store the table. It can make replacing rows very easy. See this great explanation of such a data structure: youtu.be/Wo0qiGPSV-s

Thank you for your input Yawar!

You are saying, Immutability is good because of Asynchronous data concerns. The concern of multiple async jobs not knowing the state of the data.

 

The biggest benefit, IMO, is not something that can be achieved unless it's baked in at the language level.

Put simply, immutable data done right is potentially very efficient.

The BEAM runtime environment (used by Erlang, Elixir, and a few other languages) demonstrates this nicely. Because all data in BEAM is immutable (and they use reference counted garbage collection):

  • Sharing data between processes is trivially safe (in that the data won't just vanish or change while you're accessing it).
  • Local messaging is wicked fast. Sending a message between two processes on the same node just creates a new reference to the message data, so it's almost instant.
  • Many sequence operations are insanely fast, because the new sequence they generate references the old one wherever possible. Concatenation of sequences, manipulation of the first element in a list, etc.
 

Immutability ensures quick change detections. If we are guranteed that any change will create a new version of our data, knowing that a change has happened becomes a matter of a simple reference compariason between the current and the previous data. Thus eleminating costly deep object comparaisons. This is particularly helpful with deep nested data structures that would be expenisve to traverse and compare.

 

Yes, reference comparisons tell us there is a difference quickly.

Classic DEV Post from Feb 20

SOLID design principles: Building stable and flexible systems

SOLID is one of the most well-known sets of software design principles. It can help you avoid common pitfalls and think about your apps’ architecture from a higher level.

John Peters profile image
Angular, React, Typescript and JavaScript. The wave of now!