21–30 of 174 posts
Earlier quoted context omitted.
Kotlin's version is even better: val & var Super clear. The "let" version smells a lot of "I have a CompSci PhD".
Practically, 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.
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
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.
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
Kotlin's version is even better: val & var Super clear. The "let" version smells a lot of "I have a CompSci PhD".
30 years ago I think it would have reminded people more of BASIC or Fortran than (say) Scheme.
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
But everyone is cheering them on.
The same story [0] was posted several hours ago by the author I suppose. [0]: https://news.ycombinator.com/item?id=27016848
Yep, this needs a `dup` mark somewhere. Edit for down-voters: the typical HN behaviour. Don't be lazy and take a time to explain why you downvote.
> Are reposts ok?
> If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates.
> Please don't delete and repost the same story. Deletion is for things that shouldn't have been submitted in the first place.
Dupes are not against the rules. You're likely getting downvoted by people aware of that.
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
It's bastardized OCaml. Instead of OCaml's mutable they inexplicably chose mut , which is ugly (same as pub ). But everyone is cheering them on.
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
In 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`.
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.
Earlier quoted context omitted.
Kotlin's version is even better: val & var Super clear. The "let" version smells a lot of "I have a CompSci PhD".
It'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.
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.
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
A 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 disappe…
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.
Earlier quoted context omitted.
How is it not clear that var is variable?
Yes. I think the problem may be with the other one. "val" (and "let") don't seem obviously constant to me.