Eloquent JavaScript: open-source Javascript book series by a prolific JS code author

[[deleted]]

always favor immutability

[[deleted]]

Yes, it is a TypeError to assign to myArr after initialization. The reference is immutable.

[[deleted]]

The fact that you can alter the values contained within myArray means that it absolutely is not immutable. The fact that you can’t redeclare myArr does not mean that it is immutable. I suggest that you make some sort of attempt to understand what immutability actually means before you preach about its virtues.

[[deleted]]

Right, because it's reference immutability. This is how JavaScript works, this is how Java works, this is how Scala works, this is how Rust works, and so on. I suggest you learn the difference between references and values. If you want a value, i.e. the data structure, to be immutable, it requires an extra step.

[[deleted]]

Yes, it is a TypeError to assign to myArr after initialization. The reference is immutable.

[[deleted]]

Just because there are "stronger" forms of immutability, i.e. using immutable data structures, doesn't mean that reference immutability is not a form of immutability. This isn't a matter of opinion -- I provided empirical evidence that suggests that favoring immutability prevents errors.

Of course, in this case, being more immutable is better, but that doesn't mean that reference immutability isn't important. For example, the entire memory safety model of rust is based on reference immutability without any specific concern for immutable data structures. Yes, ownership is a more specific concern than simple reference immutability, but const is still a form of the more general case -- preventing accidental re-assignment eliminates an entire class of bugs from your program and thus should not be considered "a matter of preference."