4 ms·

Just changed from having a bottom null type for all types to everything being a boxed Option type. It’s equivalent. The actual difference is the reliance on pa

Just changed from having a bottom null type for all types to everything being a boxed Option type. It’s equivalent. The actual difference is the reliance on pattern matching and the compiler enforcing coverage on those languages.

LessDmesg 7y ago
Option types don't have to be boxed and are specifically optimized in Rust and, if I remember correctly, in Haskell. The Nothing is represented much like a null pointer, i.e. with a special value that can't be dereferenced.
- tome 7y ago
  Not in Haskell, FYI. Maybes are boxed.
Sharlin 7y ago
Huh, what? You don’t need or want most values to be potentially absent.
- thu2111 7y ago
  Yes, the difference is a combination of types being non-null by default and compiler enforced checking. This doesn't require an option type. Option types are actually quite awkward compared to language integration. Kotlin doesn't use an Option type yet still delivers all the same benefits as Rust/Haskell's approach, with benefits (e.g. zero overhead, integrated syntax). Note that Option type overhead isn't merely about heavyweight syntax and the need for the compiler to successfully scalarise: using language integration around standard null pointers means the CPU spends no time on checking the 'maybe' branch. If the type system wasn't violated and a value is present, it's used immediately without any additional instructions or code bloat. If it's not then that will trigger a page fault at some point in the CPU pipeline and transfer control to an exception handler. If the type system indicates nullability and you need to actually do more than just unwrap it, then you have to take a branch of course but it's fully inlined and cheap.
  - strbean 7y ago
    Doesn't that approach make the "nothing branch" extremely expensive? Makes sense in scenarios where you really always expect Something and not Nothing. In practice, Options are very often used where something is optional, and you can expect to get Nothing a good percentage of the time. Using exceptions in such cases seems silly.
    - thu2111 7y ago
      Yes if you expect nothing, you test for it obviously. The problem is when you want high quality errors for the case where you didn't expect it and you e.g. casted away the nullness, or it was casted away for you due to language interop.
james_s_tayler 7y ago
In Java the Option of T type blows up the same way a NullPointerException does if you try to use the Option's value when it contains none. I agree. In Java at least the semantics are practically identical. I can't comment on Rust. I suspect it does a slightly better job. Crystal is another language where there is no null. It's quite cool.
- steveklabnik 7y ago
  Rust refuses to compile, because an Option<T> type is a different type than T, so if you try to use it like one, you get a type error.
  - swsieber 7y ago
    Java would also refuse to compile using an Optional<T> where T is expected. Java and Rust are practically the same regarding the differences between Optional<T> and T (java), and Option<T> and T (rust). Optional<String> in Java has the `.get()` method which corresponds to the `.unwrap()` method in Rust. And in both are different different types than String in their respective languages. But in Java you can have an Optional<String> that's null, not just empty. So that's three states - null, wrapping null, or wrapping a value. I'd say the big difference is that in Rust you can have places that refuse nulls (e.g. using T instead of Option<T>), so you have well defined points of control/checking. That, combined with the difficulty in recovering from a panic (the equivalent of a null pointer exception when trying to unwrap a value that's missing) and the Result type, are Rusts real strength wrt. missing values.
    - steveklabnik 7y ago
      I think we are saying the same thing, from slightly different perspectives. That Option can be nullable means that it can be used where it is not actually that type, without a type error, is what I’m saying.
deleted 7y ago
[deleted]

LessDmesg 7y ago

Option types don't have to be boxed and are specifically optimized in Rust and, if I remember correctly, in Haskell. The Nothing is represented much like a null pointer, i.e. with a special value that can't be dereferenced.

tome 7y ago
Not in Haskell, FYI. Maybes are boxed.

Sharlin 7y ago

Huh, what? You don’t need or want most values to be potentially absent.

thu2111 7y ago
Yes, the difference is a combination of types being non-null by default and compiler enforced checking. This doesn't require an option type. Option types are actually quite awkward compared to language integration. Kotlin doesn't use an Option type yet still delivers all the same benefits as Rust/Haskell's approach, with benefits (e.g. zero overhead, integrated syntax). Note that Option type overhead isn't merely about heavyweight syntax and the need for the compiler to successfully scalarise: using language integration around standard null pointers means the CPU spends no time on checking the 'maybe' branch. If the type system wasn't violated and a value is present, it's used immediately without any additional instructions or code bloat. If it's not then that will trigger a page fault at some point in the CPU pipeline and transfer control to an exception handler. If the type system indicates nullability and you need to actually do more than just unwrap it, then you have to take a branch of course but it's fully inlined and cheap.
- strbean 7y ago
  Doesn't that approach make the "nothing branch" extremely expensive? Makes sense in scenarios where you really always expect Something and not Nothing. In practice, Options are very often used where something is optional, and you can expect to get Nothing a good percentage of the time. Using exceptions in such cases seems silly.
  - thu2111 7y ago
    Yes if you expect nothing, you test for it obviously. The problem is when you want high quality errors for the case where you didn't expect it and you e.g. casted away the nullness, or it was casted away for you due to language interop.

james_s_tayler 7y ago

In Java the Option of T type blows up the same way a NullPointerException does if you try to use the Option's value when it contains none. I agree. In Java at least the semantics are practically identical. I can't comment on Rust. I suspect it does a slightly better job. Crystal is another language where there is no null. It's quite cool.

steveklabnik 7y ago
Rust refuses to compile, because an Option<T> type is a different type than T, so if you try to use it like one, you get a type error.
- swsieber 7y ago
  Java would also refuse to compile using an Optional<T> where T is expected. Java and Rust are practically the same regarding the differences between Optional<T> and T (java), and Option<T> and T (rust). Optional<String> in Java has the `.get()` method which corresponds to the `.unwrap()` method in Rust. And in both are different different types than String in their respective languages. But in Java you can have an Optional<String> that's null, not just empty. So that's three states - null, wrapping null, or wrapping a value. I'd say the big difference is that in Rust you can have places that refuse nulls (e.g. using T instead of Option<T>), so you have well defined points of control/checking. That, combined with the difficulty in recovering from a panic (the equivalent of a null pointer exception when trying to unwrap a value that's missing) and the Result type, are Rusts real strength wrt. missing values.
  - steveklabnik 7y ago
    I think we are saying the same thing, from slightly different perspectives. That Option can be nullable means that it can be used where it is not actually that type, without a type error, is what I’m saying.

deleted 7y ago

[deleted]