6 ms·
Haven’t learned Rust yet. I see they debated this: let and let mut let and var And went with the verbose option. Swift went with the succinct option,
by melling 6y ago
Haven’t learned Rust yet. I see they debated this:
let and let mut
let and var
And went with the verbose option.
Swift went with the succinct option, which I love about the language. In practice I suppose I do mostly type “let” in Swift so it doesn’t matter much
Swift, however, chose ‘func’ instead of ‘fn’, after much debate.
Those little things that are debated initially, then forever
- jerryluc 6y agoIn rust it played out well due to the usage of mut in other places. As in: fn (&mut T)
- dom96 6y agoSame for Nim which uses let and var: proc (x: var T)
- MrBuddyCasino 6y agoKotlin's version is even better: val & var Super clear. The "let" version smells a lot of "I have a CompSci PhD".
- melling 6y agoPractically, I prefer let and var because of autocompletion. Type one letter then tab. Of course, if I could dictate I might prefer something else. I think of it as being more math like rather than PhD. Nothing wrong with borrowing from math.
- rocqua 6y agoFrom the perspective of "language designers influencing programmers", the difficulty of auto-completing to `let mut` could be seen as something positive.
- fuck_google 6y agoObviously you haven't had to maintain code written by mathematicians that prefer to use one letter names for functions and variables among other peculiarities.
- BiteCode_dev 6y agoA good IDE will let you type "mu", and autocomplete with "let mu", cycling on tab will give you more options.
- wink 6y agoNo, not at all. I hate var & val because I never can remember which is which (from Scala, which I never really used a lot). let vs let mut is /clear/ - you can simply not mix them up.
- akvadrako 6y agoHow is it not clear that var is variable?
- mkl 6y agoYes. I think the problem may be with the other one. "val" (and "let") don't seem obviously constant to me.
- jeltz 6y agoYes, whenever I get confused I recall that var is obviously variable so therefore the other one must be val.
- nicoburns 6y agoLet is definitely confusing given that JS has let and const (with let being mutable)
- wink 6y agoBut that is cross-language, which is not ideal but not an internal problem if you work in one code base. (O)Caml also has `let` and is quite a bit older than JS.
- jodrellblank 6y agoC# uses “var” to mean “infer the type”, nothing to do with mutability or not. “Let” feels like some in-joke, coming from a math via lisp heritage of “let k be any number...” to distinguish it in English from the surrounding writing. I have to guess that in early lisp (= k 5) would be an error as k isn’t defined and (k 5) errors because k isn’t a function and (let (k 5)) comes out of need for a binding function and why not “let”. In c-like languages “k=5” is an established binding that both programmers and compilers can deal with. What does “let k=5;” add to Rust over “k=5;” ?
- mjw1007 6y agoIt's interesting if "let" nowadays has mostly 'academic' connotations. 30 years ago I think it would have reminded people more of BASIC or Fortran than (say) Scheme.
- Macha 6y agoI think this would have been more true 10 years ago when Haskell and Lisp were the most likely place for people to have encountered "let". Now? It's in Javascript in its ES6 evolution and related languages, Swift, Rust, and probably other "newer" languages I'm not aware of. Scala had it ten years ago also, but is more mainstream than it was then.
- Ar-Curunir 6y agoThe hamming distance between val and var is tiny; easy to miss in a code review.
- MrBuddyCasino 6y agoWhen assigning to val more than once: in a statically checked language the compiler will complain, and devs default to 'val' anyway. In a dynamic language you'd quickly get a runtime error. Using 'var' instead of 'val' where possible: the compiler/linter will tell you this. Or do you mean something else?
- Thiez 6y agoIn Rust the `mut` does not apply to the `let`, but to the variable binding. So you can do this: let (x, mut y) = (5, 10); After this statement `x` will not be mutable, but `y` will be. You cannot do let mut (x, y) = (5, 10); So the way Rust currently works just doesn't map clearly on `let` and `var`.
- Macha 6y agoThis is true, but the decision was made far back enough that other design decisions would have been weighed with consistency with the short behaviour in mind had that been the option chosen, and Rust would work slightly differently than how it currently works. This is in the era of a new version having patch notes like (paraphrased) "Of the four pointer types with special syntax, we've converted two of them to regular types with names and deleted the fourth" - it predated that much concern with backwards compatibility.
- chrismorgan 6y agoA relevant period of history here is the mutpocalypse, where the question was raised “why are we calling this &mut and teaching it as being about mutability when what we actually care about (for memory safety) is uniqueness and aliasing?” Had that side prevailed, &mut would have been renamed (the main candidates presented were &uniq and &only), and all bindings would have become mutable (`let mut` would have disappeared), because that concept wouldn’t make a great deal of sense any more. These are the only technical changes that it would have entailed (the biggest change would have been in pedagogy). In the end, social factors and inertia trumped technical precision and consistency. I am strongly inclined to think this was a mistake. Mutability is easier to explain initially, but teaches an incorrect mental model that hinders a correct understanding of Rust’s approach to memory safety, falling apart as soon as you touch things like atomics, RefCell or Mutex, which mutate self despite taking it as &self, a supposedly immutable reference.
- jeltz 6y agoI agree with that thinking about it in terms of mutability is a bit missleading but I am not sure how your idea would fix the issues with RefCell and Mutex. Additionally I think that some code is clearer with enforced single assignment in the syntax.
- NanoCoaster 6y ago> Mutability is easier to explain initially, but teaches an incorrect mental model that hinders a correct understanding of Rust’s approach to memory safety, falling apart as soon as you touch things like atomics, RefCell or Mutex. Could you elaborate or link to some material / discussion regarding that? I'd be very interested in how the alternative approach you're describing would change (or make unnecessary) constructs like RefCell.
- chrismorgan 6y agoThe changes I described for the mutpocalypse vision are basically all there is to it, because &mut has always been a misnomer, never about being a mutable reference as its name replies, but rather about being a unique reference, that nothing else holds a reference while you have that one. The main thing the mutpocalypse sought to achieve was to adjust Rust’s syntax to match its semantics (including to remove mutability tracking on bindings, because that wasn’t part of Rust’s necessary semantics, and wouldn’t make as much sense after the trivial syntax change). The thing I’m noting about atomics, RefCell and Mutex is how they have methods that (safely) mutate themselves, despite taking &self, a supposedly immutable reference. (I’ve modified the final sentence in my original comment to clarify this.)
- pkfoo 6y agoIt's bastardized OCaml. Instead of OCaml's mutable they inexplicably chose mut, which is ugly (same as pub). But everyone is cheering them on.
- rtoway 6y agoI think their reasoning for things that are shortened is that if it's something you will be writing a lot, it's nicer to have it shortened. So pub fn mut etc. are shortened, but return isn't