3 ms·

I agree the concept of 'non-nil' vars is very useful (and we have that in Nim), but I'm not entirely convinced by the rest of that argument. Namely, I don't agr

by filwit 11y ago

I agree the concept of 'non-nil' vars is very useful (and we have that in Nim), but I'm not entirely convinced by the rest of that argument. Namely, I don't agree that nil is rare enough to justify the verbosity Rust uses for it. Non-nil vars may be seen more often, but that doesn't mean nil vars aren't also often used, either. In Nim, both nil and non-nil vars are at roughly the same reach.. while in Rust non-nil vars are significantly easier work with. You may see that as a positive argument for Rust's safety (and you may be right for some domains), but I see it as more a negative argument for Rust's practicality.

steveklabnik 11y ago
Fair enough. My argument here is more general than Rust itself, it's relevant to all languages with an Option type and no null. The verbosity can of course vary by language.
pcwalton 11y ago
> Namely, I don't agree that nil is rare enough to justify the verbosity Rust uses for it. Non-nil vars may be seen more often, but that doesn't mean nil vars aren't also often used, either. It's not verbose. "Option" is 6 characters. ".map" is 4. > In Nim, both nil and non-nil vars are at roughly the same reach.. while in Rust non-nil vars are significantly easier work with. Option values are really easy to work with. Just use map or unwrap if you don't care about handling the null case. If you do care about handling it (which you should, after all!) the code using "if let" is the same as the equivalent "if foo == null".
- filwit 11y ago
  > It's not verbose. "Option" is 6 characters. ".map" is 4. I just want to note that verbosity isn't just about symbol length, but also about operator noise and the number of available or required commands used to achieve a goal. Just counting these characters isn't very relevant, and isn't even the best Rust can do (as someone pointed out you can use 'Some()' to get an Option var, which is only 4 chars). That said, I agree this is rather subjective, and can't be well compared outside the context of the rest of the language.
  - dragonwriter 11y ago
    > (as someone pointed out you can use 'Some()' to get an Option var, which is only 4 chars) Some() is 6 chars.
    - filwit 11y ago
      I was measuring with pcwalton's ruler.
beagle3 11y ago
What's the rust name/syntax for non-nil vars?
- steveklabnik 11y ago
  let foo = 5; // cannot be null let bar = Some(5); // technically also can't be null, but could be None // instead of Some(val) `foo` has the type `i32` here, and `bar` has the type `Option<i32>`.
Dewie3 11y ago
> I agree the concept of 'non-nil' vars is very useful ( non-zebra numbers[1] are also very useful. But why have a "non-zebra number" when I can just have plain numbers? [1] A "number" which is either a number, or a zebra
- filwit 11y ago
  ...because zebra's are not a universally useful modelling tool to programmers like references are. Thus, the absence of a reference, ie nil, also becomes a useful, commonly used modeling tool. If we all wrote software using african wildlife metaphor, 'non-zebra' might then be just as useful.
  - Dewie3 11y ago
    > ...because zebra's are not a universally useful modelling tool to programmers like references are. References are not the zebras. Nil-references are. We might as well say that the underlying number that the reference are represented by are useful modelling tools, in some circumstances. That doesn't mean that you want pointer arithmetic for references all the time.
seanwilson 11y ago
I think that 1) the vast majority of variables don't need to be nullable and 2) nullable variables are a source of common runtime errors, is a solid argument that not nullable by default is a good idea. OCaml and Haskell don't even have the concept of null. Mutable state should be discouraged in general as it makes code harder to reason about and more buggy.

by filwit 11y ago

steveklabnik 11y ago

Fair enough. My argument here is more general than Rust itself, it's relevant to all languages with an Option type and no null. The verbosity can of course vary by language.

pcwalton 11y ago

> Namely, I don't agree that nil is rare enough to justify the verbosity Rust uses for it. Non-nil vars may be seen more often, but that doesn't mean nil vars aren't also often used, either. It's not verbose. "Option" is 6 characters. ".map" is 4. > In Nim, both nil and non-nil vars are at roughly the same reach.. while in Rust non-nil vars are significantly easier work with. Option values are really easy to work with. Just use map or unwrap if you don't care about handling the null case. If you do care about handling it (which you should, after all!) the code using "if let" is the same as the equivalent "if foo == null".

filwit 11y ago
> It's not verbose. "Option" is 6 characters. ".map" is 4. I just want to note that verbosity isn't just about symbol length, but also about operator noise and the number of available or required commands used to achieve a goal. Just counting these characters isn't very relevant, and isn't even the best Rust can do (as someone pointed out you can use 'Some()' to get an Option var, which is only 4 chars). That said, I agree this is rather subjective, and can't be well compared outside the context of the rest of the language.
- dragonwriter 11y ago
  > (as someone pointed out you can use 'Some()' to get an Option var, which is only 4 chars) Some() is 6 chars.
  - filwit 11y ago
    I was measuring with pcwalton's ruler.

beagle3 11y ago

What's the rust name/syntax for non-nil vars?

steveklabnik 11y ago
let foo = 5; // cannot be null let bar = Some(5); // technically also can't be null, but could be None // instead of Some(val) `foo` has the type `i32` here, and `bar` has the type `Option<i32>`.

Dewie3 11y ago

> I agree the concept of 'non-nil' vars is very useful ( non-zebra numbers[1] are also very useful. But why have a "non-zebra number" when I can just have plain numbers? [1] A "number" which is either a number, or a zebra

filwit 11y ago
...because zebra's are not a universally useful modelling tool to programmers like references are. Thus, the absence of a reference, ie nil, also becomes a useful, commonly used modeling tool. If we all wrote software using african wildlife metaphor, 'non-zebra' might then be just as useful.
- Dewie3 11y ago
  > ...because zebra's are not a universally useful modelling tool to programmers like references are. References are not the zebras. Nil-references are. We might as well say that the underlying number that the reference are represented by are useful modelling tools, in some circumstances. That doesn't mean that you want pointer arithmetic for references all the time.

seanwilson 11y ago

I think that 1) the vast majority of variables don't need to be nullable and 2) nullable variables are a source of common runtime errors, is a solid argument that not nullable by default is a good idea. OCaml and Haskell don't even have the concept of null. Mutable state should be discouraged in general as it makes code harder to reason about and more buggy.