6 ms·

To be fair, all new serious languages now don't have null pointers. ... but we'll still struggle with java.lang.NullPointerException in 2080.

by tormeh 7y ago

gdy 7y ago
And serious languages are those that don't have null pointers?
- fortran77 7y ago
  The original 8-bit BASICs didn't have null pointers. They were _serious_ languages!
  - pg_is_a_butt 7y ago
    PHP is moving away from that... what a joke
jsjohnst 7y ago
So is Go not a “new serious language”? You can definitely have nil pointers panic in Go if written poorly.
- grapehut 7y ago
  Go is even worse. They just use the word "nil" instead of "null". Go does a lot of really silly things too, like the nil pointer receiver's (basically something that allow you dereference null in certain contexts) ends up having terrible side-effects on the type theory and you end up with really stupid exceptions, like nil represents an empty slice and you can do stuff like get it's size or append to it, but the same operations would cause a panic with a map. But both Java and Go are serious languages.
- tyingq 7y ago
  There are certainly people that feel like it was a mistake. https://getstream.io/blog/fixing-the-billion-dollar-mistake-in-go-by-borrowing-from-rust/ https://getstream.io/blog/fixing-the-billion-dollar-mistake-...
  - hu3 7y ago
    There are only two kinds of languages: the ones people complain about and the ones nobody uses.
- deleted 7y ago
  [deleted]
- lilyball 7y ago
  Go having nil for various types is indeed a problem. In fact, a few weeks ago I caught an issue where a map in Go was unexpectedly nil when it should have been full of data (missing initializer), and I caught it because the serialized data was then consumed by the client written in Swift which doesn’t have this issue. Go thought it was writing data to spec but the client immediately diagnosed it as having an unexpected null before it even tried to work with the data.
davnicwil 7y ago
A null pointer is just a manifestation of a bug, usually unexpectedly missing data. If you can't have nulls, you might have a better chance of spotting the possibility of that missing data and trying to deal with it, granted, but if it happens truly unexpectedly the bug is still going to manifest itself somehow, as an NPE or otherwise. Following all the way through, let's say there is no exception anywhere and the missing data gets all the way through to the UI.. well then that's how the bug manifests. Is the missing data just not appearing better than a 'oops, something went wrong' error or similar in response to a 500 caused by an NPE? Depends on the application and circumstances I guess, but in general probably not. The bug exists in both cases. You can present it in better and worse ways, but the bug is that the data is not there and it should be. The point being, not having NPE doesn't fix any problems, fundamentally. It just shifts them elsewhere. No language feature saves you from bugs.
- akiselev 7y ago
  > The point being, not having NPE doesn't fix any problems, fundamentally. It just shifts them elsewhere. No language feature saves you from bugs. NPE is the problem. The point of type systems with non-nullable references is that they force you to handle the null case explicitly using an Option/Maybe type by throwing a compiler error instead of an exception in production. Nobody expects that getting rid of NPEs would get rid of bugs. It would, however, force one of the most common classes of bugs to be handled when it is cheapest to do so, rather than when the production system is on fire.
  - davnicwil 7y ago
    Respectfully I think you're not addressing the point I'm making, but a slightly different one. In the case where a piece of data can be missing, and that's fine, I completely agree that optional/maybe types are useful to model that explicitly and unambiguously. They let you and future maintainters know that this is the case, via the type system, at compile time. But what I'm talking about here is genuine runtime exceptions (which NPE is in Java, of course), where the design of the system says that this piece of data cannot be missing and yet, at runtime, you encounter a case where it is missing, erroneously, because of some bug somewhere. Types like optionals won't help you here, because you wouldn't have used them at design time anyway. The same applies to languages completely without null references. All type systems do is formalise expectations about how data is going to look. If the real data breaks from those expectations because of some bug at runtime, the type system can't help you.

To be fair, all new serious languages now don't have null pointers. ... but we'll still struggle with java.lang.NullPointerException in 2080.

by tormeh 7y ago

To be fair, all new serious languages now don't have null pointers. ... but we'll still struggle with java.lang.NullPointerException in 2080.

gdy 7y ago

And serious languages are those that don't have null pointers?

fortran77 7y ago
The original 8-bit BASICs didn't have null pointers. They were _serious_ languages!
- pg_is_a_butt 7y ago
  PHP is moving away from that... what a joke

jsjohnst 7y ago

So is Go not a “new serious language”? You can definitely have nil pointers panic in Go if written poorly.

grapehut 7y ago
Go is even worse. They just use the word "nil" instead of "null". Go does a lot of really silly things too, like the nil pointer receiver's (basically something that allow you dereference null in certain contexts) ends up having terrible side-effects on the type theory and you end up with really stupid exceptions, like nil represents an empty slice and you can do stuff like get it's size or append to it, but the same operations would cause a panic with a map. But both Java and Go are serious languages.
tyingq 7y ago
There are certainly people that feel like it was a mistake. https://getstream.io/blog/fixing-the-billion-dollar-mistake-in-go-by-borrowing-from-rust/ https://getstream.io/blog/fixing-the-billion-dollar-mistake-...
- hu3 7y ago
  There are only two kinds of languages: the ones people complain about and the ones nobody uses.
deleted 7y ago
[deleted]
lilyball 7y ago
Go having nil for various types is indeed a problem. In fact, a few weeks ago I caught an issue where a map in Go was unexpectedly nil when it should have been full of data (missing initializer), and I caught it because the serialized data was then consumed by the client written in Swift which doesn’t have this issue. Go thought it was writing data to spec but the client immediately diagnosed it as having an unexpected null before it even tried to work with the data.

davnicwil 7y ago

A null pointer is just a manifestation of a bug, usually unexpectedly missing data. If you can't have nulls, you might have a better chance of spotting the possibility of that missing data and trying to deal with it, granted, but if it happens truly unexpectedly the bug is still going to manifest itself somehow, as an NPE or otherwise. Following all the way through, let's say there is no exception anywhere and the missing data gets all the way through to the UI.. well then that's how the bug manifests. Is the missing data just not appearing better than a 'oops, something went wrong' error or similar in response to a 500 caused by an NPE? Depends on the application and circumstances I guess, but in general probably not. The bug exists in both cases. You can present it in better and worse ways, but the bug is that the data is not there and it should be. The point being, not having NPE doesn't fix any problems, fundamentally. It just shifts them elsewhere. No language feature saves you from bugs.

akiselev 7y ago
> The point being, not having NPE doesn't fix any problems, fundamentally. It just shifts them elsewhere. No language feature saves you from bugs. NPE is the problem. The point of type systems with non-nullable references is that they force you to handle the null case explicitly using an Option/Maybe type by throwing a compiler error instead of an exception in production. Nobody expects that getting rid of NPEs would get rid of bugs. It would, however, force one of the most common classes of bugs to be handled when it is cheapest to do so, rather than when the production system is on fire.
- davnicwil 7y ago
  Respectfully I think you're not addressing the point I'm making, but a slightly different one. In the case where a piece of data can be missing, and that's fine, I completely agree that optional/maybe types are useful to model that explicitly and unambiguously. They let you and future maintainters know that this is the case, via the type system, at compile time. But what I'm talking about here is genuine runtime exceptions (which NPE is in Java, of course), where the design of the system says that this piece of data cannot be missing and yet, at runtime, you encounter a case where it is missing, erroneously, because of some bug somewhere. Types like optionals won't help you here, because you wouldn't have used them at design time anyway. The same applies to languages completely without null references. All type systems do is formalise expectations about how data is going to look. If the real data breaks from those expectations because of some bug at runtime, the type system can't help you.