Hacker News Reader

Comment by jdoliner | Hacker News Reader

C programs tend to call nil-pointer panics "segfaults" even though go runtime doesn't print the word "segfault" anywhere. I'm guilty of the same thing.

View on HN

Well, I think they're worth separating.

I've seen a raw SIGSEGV in Go due to a runtime bug years ago, and the only safe outcome is process termination.

On the other hand, dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine. For common cases like HTTP and RPC handlers, no big deal, safely recoverable.

Edit: on second thought, forget that. I agree that it's not a good thing (not safe) for recovery from goroutine crash to be possible.

> dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine.

Yeah, these are exactly the things I don't want to see: production log messages saying that something or other referred to a nil pointer and thus crashed some process. I don't think they belong to modern programming.

Sure, segfaults are even worse since you don't even get the log message, but I still kinda lump both of these problems together as "errors from the 1900s that shouldn't happen anymore".

Totally agreed. A modern type system should make these errors fundamentally impossible. If you see them in production, it means there is definitely a logic or error handling issue somewhere in your code and I find it weird that there's no support for a known technique for eliminating them.

You can't actually accomplish that without making the language really complicated.

Are Crystal, Kotlin and Swift really complicated? Is Rust's complications due to null protections or something else?

Are you joking? They're all way more complicated than Go.

Okay, let's pretend that's true.

Are the complications due to null protection being there, or are they due some other things?

Some of the complications are necessary. You either need generics or a whole bunch of primitives to have non-nullable references. Go would also have to replace slices with something different. Return types and the shape of the interfaces would have to be changed. Algebraic datatypes or some complicated way of defining return types would need to be added for it to be usable. Defer statements that can modify the function's return value would need to be handleable by the type system, or dropped.

NULL exists in every programming language. There must be something to designate a missing value, a non assigned pointer or reference.

Most languages, sure, but not all; Haskell doesn’t have NULL. You can express the absense of a value with a Maybe:

    Just “value” -> Maybe String
    Nothing      -> Maybe a

If your function returns a “Maybe String”, it can either be just a value, or Nothing. However, if a function returns a “String”, you can’t return Nothing, only an actual String.

There’s no null in Haskell.

yeah... no. most notably rust, which might be surprising as it can be used (and has been) to write a kernel in, only has null pointers in unsafe code.

rust is hardly the first one, too.

> NULL exists in every programming language.

No.

> There must be something to designate a missing value, a non assigned pointer or reference

Option types are something like 45 years old, they're not exactly futuristic technology.

There has to be a way to represent a missing value, but the key point in languages that don't have NULL is that you can only represent missing values using a type that supports missing values - e.g. option types such as Haskell's Maybe.

This achieves two things:

1. It allows you to define functions that cannot return NULL, and the compiler guarantees this. This is a huge win - you no longer have NULL as a possible return value for many functions.

2. Values belonging to the option type have to be unwrapped to access their contents, so it's not possible to unknowingly dereference a missing value. This is an even bigger win than #1, because it can literally eliminate null pointer errors.

A caveat to #2 is that depending on the language, it may be possible to override safety, for example Haskell's fromJust can throw an exception if used on a missing value. But this tends to require conscious effort, and can easily be checked for automatically, since it involves the use of unsafe function calls.

> A caveat to #2 is that depending on the language, it may be possible to override safety, for example Haskell's fromJust can throw an exception if used on a missing value. But this tends to require conscious effort, and can easily be checked for automatically, since it involves the use of unsafe function calls.

A much scarier example there is C++, where std::optional can be deref'd (literally `*opt`, the easiest and shortest thing you can do with it)… and just UBs on an empty optional. Because C++ hates both type-safety and memory-safety.

It is extremely easy to get a SIGSEGV by creating a double pointer and then attempting to assign something to *p.

Reply on news.ycombinator.com