@flabdablet said:
@studog said:@flabdablet said:Brendan Eich is a really smart guy, Rust looks fairly tidy,
Er... quoting from the Rust link "The let keyword introduces a local variable. Variables are immutable by default." The really smart guy doesn't understand the meaning of a basic english word. This does not inspire confidence."Let" is being used there as a short synonym for "define". I don't understand why that's problematic.
Or is it the apparent contradiction between "variable" and "immutable" that's bothering you? It shouldn't. "Variable" is long-established programming jargon for a name used as a placeholder for a value; using some other word for that thing would cause more confusion than it avoids. If a variable is immutable, that simply means that the value it identifies can't be modified in-place; but that doesn't stop any given immutable variable's name from identifying different values over the course of the program.
Putting that another way: let x = 3 means "until further notice, x refers to some chunk of memory that holds the value 3." As far as I can tell (and I've never used Rust, just read the tutorial) there is nothing stopping you from following that at some point inside the same block with let x = 4, which makes any subsequent use of x mean something different. The name x is indeed a variable, in that it means different things at different points in the course of execution. If x is also immutable, though, you have an additional guarantee that the only way to make x mean something different is to do a new let for it: no other thread or function can change what's inside the memory you've made x a name for.
Immutability is actually a very old pattern. There were FORTRAN compilers for machines such as the CDC Cyber series, whose architecture made loading constant values into registers very inconvenient, that created a presumed-immutable pool of constant values - one for each unique literal value in your FORTRAN program - and used the addresses of those in any machine instruction requiring access to that constant. With at least some of those compilers, immutability was poorly enforced and you could badly screw things up by passing a literal constant to a function as a parameter, then modifying the value of that parameter inside the function. FORTRAN passes parameters by reference, not by value, so if function FUCKUP(X) does X=99 inside and you invoke FUCKUP(2), you'd pollute the "immutable" 2 inside the constants pool, and any subsequent FORTRAN statement including the literal value 2 would behave as if coded using the literal value 99 instead.
I think that we're caught up on the fact that it states that by default you cannot reassign the variable to anything else and that you must explicitly allow the variable to be reassignable AFAICT.
If that is not the case, OK I am wrong. If it is, WTF? Old paradigms don't need to be used anymore for good reason.