3 ms·

Scala seems to be the only language that recognizes the merit of having both unions and ADTs. It even has GADTs!

tobz619 2y ago
Haskell also has GADTs: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/gadt.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/gadt..., firstly as an extension and now it's built into the latest version of this year's compiler
- kyjasdfwus 2y ago
  Yep, Scala is influenced by Haskell.
- iso8859-1 2y ago
  You're misinterpreting 'GHC2024'. It's just a language edition, a short hand of enabling a bunch of extensions. You have been able to enable GADTs for many years now, with just a single pragma. It has been built in to GHC for all these years.
cubefox 2y ago
Yet ironically Scala is not null safe I believe.
- vips7L 2y ago
  https://docs.scala-lang.org/scala3/reference/experimental/explicit-nulls.html https://docs.scala-lang.org/scala3/reference/experimental/ex...
  - cubefox 2y ago
    Opt-in is better than nothing, but in practice I assume this sees little use because it breaks compatibility with old code. Null safety (and type safety in general) has to be present in a programming language from the start; it can't realistically be added as a feature later.
    - vips7L 2y ago
      I don't think I agree. C# added it and its gone well and Java is adding null safety without breaking backwards compatibility at all.
      - cubefox 2y ago
        Types in old code may be nullable, or not, the compiler doesn't know, so the only way the compiler can ensure null safety for using old code is by enforcing you to do null checks everywhere. That's not very practical. Moreover, the old code itself may still produce null pointer exceptions.
        vips7L 2y ago
        But that doesn't break compatibility like you claimed and it also doesn't support your conclusion that it will not likely be used. > he compiler doesn't know, so the only way the compiler can ensure null safety for using old code is by enforcing you to do null checks everywhere This isn't necessarily true. Java's approach is to have 3 types: nullable, non-null, and platform (just like Kotlin). Platform types are types without nullness markers and don't require strict null checks to prevent backwards compatibility breaking. Yes, old code may still product null pointers, but we don't need 100% correctness right away. At some point platform types will be 1% of code in the wild rather than 100%.
        cubefox 2y ago
        > At some point platform types will be 1% of code in the wild rather than 100%. In the case of Java this could take decades. Or people simply continue to write platform types because they are lazy (the compiler doesn't force them). Then platform types will never decrease substantially.
        vips7L 2y ago
        I don't think that's true and I don't think there is any data to back that up. We've already seen in the C# community rapid adoption of nullness markers. This whole goal post moving and the idea that if we can't have 100% we shouldn't do it at all is a bit exhausting so I think I'm done here. Cheers man.
- dionian 2y ago
  I have been doing scala professionally for a decade, I have probably have 1 NPE per year on average, max. And pretty much never from an established scala lib. It's by convention not to use null - heavy use of Option, etc.

Haskell also has GADTs: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/gadt.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/gadt..., firstly as an extension and now it's built into the latest version of this year's compiler

kyjasdfwus 2y ago
Yep, Scala is influenced by Haskell.
iso8859-1 2y ago
You're misinterpreting 'GHC2024'. It's just a language edition, a short hand of enabling a bunch of extensions. You have been able to enable GADTs for many years now, with just a single pragma. It has been built in to GHC for all these years.

cubefox 2y ago

Yet ironically Scala is not null safe I believe.

vips7L 2y ago
https://docs.scala-lang.org/scala3/reference/experimental/explicit-nulls.html https://docs.scala-lang.org/scala3/reference/experimental/ex...
- cubefox 2y ago
  Opt-in is better than nothing, but in practice I assume this sees little use because it breaks compatibility with old code. Null safety (and type safety in general) has to be present in a programming language from the start; it can't realistically be added as a feature later.
  - vips7L 2y ago
    I don't think I agree. C# added it and its gone well and Java is adding null safety without breaking backwards compatibility at all.
    - cubefox 2y ago
      Types in old code may be nullable, or not, the compiler doesn't know, so the only way the compiler can ensure null safety for using old code is by enforcing you to do null checks everywhere. That's not very practical. Moreover, the old code itself may still produce null pointer exceptions.
      - vips7L 2y ago
        But that doesn't break compatibility like you claimed and it also doesn't support your conclusion that it will not likely be used. > he compiler doesn't know, so the only way the compiler can ensure null safety for using old code is by enforcing you to do null checks everywhere This isn't necessarily true. Java's approach is to have 3 types: nullable, non-null, and platform (just like Kotlin). Platform types are types without nullness markers and don't require strict null checks to prevent backwards compatibility breaking. Yes, old code may still product null pointers, but we don't need 100% correctness right away. At some point platform types will be 1% of code in the wild rather than 100%.
        cubefox 2y ago
        > At some point platform types will be 1% of code in the wild rather than 100%. In the case of Java this could take decades. Or people simply continue to write platform types because they are lazy (the compiler doesn't force them). Then platform types will never decrease substantially.
        vips7L 2y ago
        I don't think that's true and I don't think there is any data to back that up. We've already seen in the C# community rapid adoption of nullness markers. This whole goal post moving and the idea that if we can't have 100% we shouldn't do it at all is a bit exhausting so I think I'm done here. Cheers man.
dionian 2y ago
I have been doing scala professionally for a decade, I have probably have 1 NPE per year on average, max. And pretty much never from an established scala lib. It's by convention not to use null - heavy use of Option, etc.