7 ms·

"Compare Rust where, unless you have explicitly used the unsafe features of the language, all pointers are guaranteed non-nil and valid. Instead of a function r

by dscrd 14y ago

"Compare Rust where, unless you have explicitly used the unsafe features of the language, all pointers are guaranteed non-nil and valid. Instead of a function returning a nil pointer, it returns an `Option` type which is either `Some ptr` or `None`. The type system guarantees you have considered both possibilities so there's no such thing as a runtime null pointer dereference. Scala has a similar `Option` type, as does Haskell, calling it `Maybe`. In 2013 I don't want to still constantly check for a nil pointer, or have my program blow up at runtime if I forget." So how is nil checking different from when I write a function that pattern matches against a Maybe in a way that I only match against the "Just" case?

abhinavg 14y ago
I believe graue was referring to the case when you are not using such a type in the code; then you have a guarantee that the value is non-null. The purpose of the Some/Option/Maybe types then becomes to indicate when a value can be null, but outside that wrapper type it is guaranteed to be non-null. So code where it must always be non-null does not have to confirm that that's the case. I think it is less about efficiency and more about not having to worry about it.
alecbenzer 14y ago
Guess: the compiler knows you forgot to check the "Nothing" case and will tell you.
- dscrd 14y ago
  Ah, I see. I was confused by Haskell not doing that by default... at least the last time I wrote code on it. Is there actual data that says that null pointers are actually causing bugs in production software? I always thought they are just a symptom of lazy programmers, and no language can fully protect against that. Witness my awesome Haskell snippet of code: foo (Just x) = x+2 foo Nothing = undefined Ok, so it's somewhat better since the lazyness is now explicit and cannot happen so accidentally.
  - friendly_chap 14y ago
    "Is there actual data that says that null pointers are actually causing bugs in production software?" Have you ever written even one line of code in your life?
    - MBlume 14y ago
      This comment really clashes with your user name =P
  - Peaker 14y ago
    http://www.computerworld.com.au/article/261958/a-z_programming_languages_c_/?pp=3 http://www.computerworld.com.au/article/261958/a-z_programmi... Anders estimates 50% of the bugs in C# and Java are due to null dereferences. Your example illustrates the unsafety of undefined, not the unsafety of nulls/Nothing. And you can of course grep for use of partiality in Haskell code and get warnings about partiality in your own functions. I've seen NULL causing a lot of trouble in production in every setting I've been. It is very rare to see people mis-handling a Maybe value in Haskell, simply because you have to be explicit about ignoring the Nothing case. Also, in Haskell, if you get a Maybe value it is a very clear indication that the Nothing case actually exists and you have to handle it. In C, C#, Java, Go, when you get a reference, it is unclear whether it could be null or not in practice. Checking for null when it isn't warranted is dead code you never test. Avoiding checking for null risks missing checks in cases you actually need to check. All of this is simply not a problem when the types don't lie.
jcurbo 14y ago
To me it's about the existence of the nil pointer itself. If there is a pointer, it is guaranteed to be valid by the type system. The other case (which would be represented by a nil or null pointer in other languages) is represented by the "None" type. There's no null pointer to dereference (and no way to blow up).
kibwen 14y ago
In Rust at least, pattern matching on enums must consider all possible cases. Option is just an enum, so it's a compiler error if you don't handle the None case.
bad_user 14y ago
We have been using Scala lately for a couple of web services that are now running in production at our startup. The difference is huge, because Option[T] references are type-checked at compile-time. Whenever a reference can be either Some(value) or None, then you are made aware of it and you are also forced to either handle it (by giving a default value, or throwing a better documented exception) or you can simply pass the value along as is and make it somebody else's problem. Option[T] in Scala is also a monadic type, as it implements filter(), map() and flatMap(). It's really easy and effective to work with Option[T]. In comparison with "null", which isn't a value that you can work with other than doing equality tests, None on the other hand is an empty container for which you know at compile-time the type of the value it should contain and in Scala it's also an object that knows how to do filter(), map() and flatMap(). My code is basically free of NullPointerExceptions. This doesn't mean that certain errors can't still be triggered by null pointers, but those errors are better documented. What's better? A NullPointerException or a ConfigSettingMissing("db.url")? Of course, to tell you the truth, Option[T] (or Maybe as it is named in Haskell) is only really useful in a static language. In a dynamic language, such as Clojure, especially if you have multi-methods or something similar, well in such a case Option[T] is less useful. And before you ask, no, Go is not dynamic and people saying that Go feels like a dynamic language, don't really know what they are talking about.
- blablabla123 14y ago
  >My code is basically free of NullPointerExceptions. This doesn't mean that certain errors can't still be triggered by null pointers, but those errors are better documented. What's better? A NullPointerException or a ConfigSettingMissing("db.url")? Almost always it is a matter of 2 seconds to find the source of a nil pointer error. Given that I would almost never forward raw error messages to the user, I cannot really see a gain. However having a language that combines this Scala feature with Go's exception-free error handling, would be awesome and a true solution that would make software run more reliable and with less crashes.
  - Peaker 14y ago
    There was a quote from .NET authors about roughly 50% of the field issues with .NET code being Null Pointer exceptions.
tomjen3 14y ago
There is a huge difference: null/nil is a valid value for a pointer, but Option[string] is not a valid value for a string argument, so the compiler forces you to deal with it. How is that any different from always checking it? When you program in C, you essentially always have to check it, when you program in Scala/Haskell/etc you only have to check it once.
zwass 14y ago
You should also consider Haskell's Maybe monad, which makes the pattern matching on Just/Nothing unnecessary.

by dscrd 14y ago

abhinavg 14y ago

I believe graue was referring to the case when you are not using such a type in the code; then you have a guarantee that the value is non-null. The purpose of the Some/Option/Maybe types then becomes to indicate when a value can be null, but outside that wrapper type it is guaranteed to be non-null. So code where it must always be non-null does not have to confirm that that's the case. I think it is less about efficiency and more about not having to worry about it.

alecbenzer 14y ago

Guess: the compiler knows you forgot to check the "Nothing" case and will tell you.

dscrd 14y ago
Ah, I see. I was confused by Haskell not doing that by default... at least the last time I wrote code on it. Is there actual data that says that null pointers are actually causing bugs in production software? I always thought they are just a symptom of lazy programmers, and no language can fully protect against that. Witness my awesome Haskell snippet of code: foo (Just x) = x+2 foo Nothing = undefined Ok, so it's somewhat better since the lazyness is now explicit and cannot happen so accidentally.
- friendly_chap 14y ago
  "Is there actual data that says that null pointers are actually causing bugs in production software?" Have you ever written even one line of code in your life?
  - MBlume 14y ago
    This comment really clashes with your user name =P
- Peaker 14y ago
  http://www.computerworld.com.au/article/261958/a-z_programming_languages_c_/?pp=3 http://www.computerworld.com.au/article/261958/a-z_programmi... Anders estimates 50% of the bugs in C# and Java are due to null dereferences. Your example illustrates the unsafety of undefined, not the unsafety of nulls/Nothing. And you can of course grep for use of partiality in Haskell code and get warnings about partiality in your own functions. I've seen NULL causing a lot of trouble in production in every setting I've been. It is very rare to see people mis-handling a Maybe value in Haskell, simply because you have to be explicit about ignoring the Nothing case. Also, in Haskell, if you get a Maybe value it is a very clear indication that the Nothing case actually exists and you have to handle it. In C, C#, Java, Go, when you get a reference, it is unclear whether it could be null or not in practice. Checking for null when it isn't warranted is dead code you never test. Avoiding checking for null risks missing checks in cases you actually need to check. All of this is simply not a problem when the types don't lie.

jcurbo 14y ago

To me it's about the existence of the nil pointer itself. If there is a pointer, it is guaranteed to be valid by the type system. The other case (which would be represented by a nil or null pointer in other languages) is represented by the "None" type. There's no null pointer to dereference (and no way to blow up).

kibwen 14y ago

In Rust at least, pattern matching on enums must consider all possible cases. Option is just an enum, so it's a compiler error if you don't handle the None case.

bad_user 14y ago

We have been using Scala lately for a couple of web services that are now running in production at our startup. The difference is huge, because Option[T] references are type-checked at compile-time. Whenever a reference can be either Some(value) or None, then you are made aware of it and you are also forced to either handle it (by giving a default value, or throwing a better documented exception) or you can simply pass the value along as is and make it somebody else's problem. Option[T] in Scala is also a monadic type, as it implements filter(), map() and flatMap(). It's really easy and effective to work with Option[T]. In comparison with "null", which isn't a value that you can work with other than doing equality tests, None on the other hand is an empty container for which you know at compile-time the type of the value it should contain and in Scala it's also an object that knows how to do filter(), map() and flatMap(). My code is basically free of NullPointerExceptions. This doesn't mean that certain errors can't still be triggered by null pointers, but those errors are better documented. What's better? A NullPointerException or a ConfigSettingMissing("db.url")? Of course, to tell you the truth, Option[T] (or Maybe as it is named in Haskell) is only really useful in a static language. In a dynamic language, such as Clojure, especially if you have multi-methods or something similar, well in such a case Option[T] is less useful. And before you ask, no, Go is not dynamic and people saying that Go feels like a dynamic language, don't really know what they are talking about.

blablabla123 14y ago
>My code is basically free of NullPointerExceptions. This doesn't mean that certain errors can't still be triggered by null pointers, but those errors are better documented. What's better? A NullPointerException or a ConfigSettingMissing("db.url")? Almost always it is a matter of 2 seconds to find the source of a nil pointer error. Given that I would almost never forward raw error messages to the user, I cannot really see a gain. However having a language that combines this Scala feature with Go's exception-free error handling, would be awesome and a true solution that would make software run more reliable and with less crashes.
- Peaker 14y ago
  There was a quote from .NET authors about roughly 50% of the field issues with .NET code being Null Pointer exceptions.

tomjen3 14y ago

There is a huge difference: null/nil is a valid value for a pointer, but Option[string] is not a valid value for a string argument, so the compiler forces you to deal with it. How is that any different from always checking it? When you program in C, you essentially always have to check it, when you program in Scala/Haskell/etc you only have to check it once.

zwass 14y ago

You should also consider Haskell's Maybe monad, which makes the pattern matching on Just/Nothing unnecessary.