edit: don't vote the guy/gal down just because they are admitting some ignorance and seeking clarity

I would quickly disabuse yourself of the notion that all values are immutable in JavaScript, as otherwise you will cause yourself and colleagues a lot of pain in future. As someone that has to write or maintain a lot of JavaScript, saying that I don't have to think about data changing over the course of a program doesn't strike me as true at all (I wish it was).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data...

As linked, only some of the primitive values in javascript are immutable. So while you can be confident in this:

const x = 'a perfectly well formed string';

// lots of code in between

console.log(x) // will always print 'a perfectly well formed string'

You cannot be confident in this at all:

const x = {

  a: 'a perfectly well formed string within an object'

};

// lots of code in between

console.log(x.a) // absolutely no guarantee that x.a will point at the same string as at the time x was initialized as an object, or that the key will even exist (will fallback to the type 'undefined' if you attempt to read it).

JavaScript has references and values like most languages, but you aren't dealing with memory as explicitly as Rust or C. The reason is in large part because memory is garbage collected in Javascript.

That's like saying the pointer 0x123456 is immutable. Which is strictly speaking true, even in a language as lax as C. But it's clearly not what people mean when they talk about pointers (or references) being mutable. What people mean is that either variables are mutable, or memory is. So if you say:

    // suppose initially x == 0x123456 and x has type char *
    x++
    // x == 0x123457

this is really changing the value of a variable (neither of the pointers 0x123456 or 0x123457 have been changed in any way).

Or if you say:

    *x = 'a'

now you're modifying the memory at the address 0x123457 (again, the pointer itself has not changed).

The fact that the pointer itself, as in the address to memory (as opposed to the variable holding that address or the contents of the memory being referred to) is immutable is of approximately no value to anyone.

And frankly, it makes no difference (for these examples) whether this is a language with pointers or references. You can still set variables holding references to new values (if the language allows mutable variables), and you can still mutate the memory that references address (if the language allows mutation of the objects referred to by references), and that's plenty of rope to hang yourself on even without being able to do pointer arithmetic on the address values.

The semantics of a programming language isn't determined by how you talk about it or even how the language specification talks about it.

The original statement was: "(I program in JavaScript where all values are immutable)" Its meaning depends on the semantics of 'values' and 'immutable'. If by 'values' you only mean primitive values (excluding objects and arrays) or by immutable you only mean immutable identity (excluding mutable state), you're comparing apples to oranges instead of Rust to JavaScript.

Immutable.js and PureScript exists for a reason: in JavaScript, not all values are immutable.

If we have the same concept of "value" in Javascript, then values are certainly not immutable. E.g.:

    const a = {x: 1, y: 2};
    console.log(a.x);  // 1
    a.x = 2;
    console.log(a.x);  // 2

Note that 'a' remained constant indeed, but the object it points to can certainly take on different values.

with immutable I mean that a value (value 1 and 2 in your example) can never change, you can reassign the variable to a new value though. If I understand the article correctly values in Rust and C++ can change eg. the memory location of the bits representing the value. Making it possible to shoot yourself in the foot if you don't know how the internals work, more so then in JavaScript as it's much more to keep track of. Even though it seems to be Rust's motto to limit such cases. And I agree? that using const in JavaScript is like wearing a tin foil hat - it will rarely save you. If I have something that can change globally I make it upper case so it stands out and don't collide with other variables. And "use strict" should tell if you forgot to var(let/const) a variable. (unless there's a HTML id attribute with the same name) =)

If that is what you mean, then yes you are right.

Pointers point at bits of memory (its literally an address to a physical piece of memory or virtual memory allocated by something else - an OS for example) which store things like the 64bit floats '1' and '2' you are referring to in Javascript, and that is something someone writing C needs to think about pretty explicitly and is a source of errors. In Javascript you don't have to think about it very often in explicitly those terms as the runtime takes care of thinking about that for you.

You create all of these string, numbers, objects, etc... that the runtime has to keep track of for you using pointers, and once it thinks you are done with that memory it frees it up.

https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

However, as I and other have said, while someone writing JavaScript doesn't have to think much about memory, you still have to think about references and values. Its also the case that the Garbage Collector isn't perfect, and sometimes as a JavaScript programmer you can accidentally create memory problems of your own:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memo...

a.x isn't a variable, it's a part of an mutable object. JS arrays are also mutable.

You are working under dangerously incorrect assumptions. JavaScript data structures are all mutable, except some primitives.

Yes, they do. The value of Rust is that it makes it safe to do: if there's a reference (Rust's safe "pointer" type) to something, it can't change or move in surprising ways.