Hacker News Reader

Comment by brikym | Hacker News Reader

> No nulls by default ...While many modern languages added some control for doing more null checks to prevent NullReferenceException, F# avoided them from the inception. This means such exceptions are nearly impossible

A great feature that Golang couldn't get right years later.

View on HN

The fact that golang was designed with the "billion dollar mistake" as recently as it was is pretty astonishing.

I agree, but it doesn’t change the fact in my mind that despite golang’s nulls, I’ve found it to be a ridiculously productive language to work with in a lot of cases. I’d credit that to the simplicity of the language (if not the runtime), and, it least from that perspective, it’s something Golang shares with F#. F# has the obvious advantage of a significantly better type system and the disadvantage of not sharing the more familiar Algol/c syntax.

Yes. The concept of references (which includes that of null pointers) and that of optionality (which includes that of nothingness) are orthogonal. The former is just an artefact of computer architecture, the latter is everyday business logic. Go mixes the two into a single concept, which is painful.

As a newcomer to Go, I find myself struggling to express business logic all the time. Zero-valued types make the situation even worse. You’re constantly constructing invalid values of types (nil/zero-valued), by design. Go is “so easy”, but when you inevitably run into one of the footguns it’s “yeah just don’t do that”.

One of the primary reasons for people to dislike Python is its dynamic typing. When Go came out, that was totally fair. But since then, Python has evolved and improved massively. It/mypy now supports type-safe structural pattern matching, for example. It’s very expressive, and safely so.

Meanwhile Go barely evolved. Generics landed just recently. They’re only now experimenting with iteration, lifting it from a purely magic, compiler intrinsic concept. And still, no enums of course. The “type system” are structs, or very leaky type wrappers (nowhere near the safety of Rust new types, for example). People are obsessed with primitives.

I can see the appeal of a simple, stable platform, but Go really ran too far with that idea.

Wait, can you even run into a null pointer reference error in Go?

You can do this much:

    func main() {
       var p *int
       *p = 1
    }

    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x466462]

That's memory safe. It's also common and terrible. As is Java's NullPointerException, C#'s NullReferenceException, Javascript's "is not a non-null object" and all the other, unnecessary and awful, yet memory safe manifestations of the same design mistake plaguing contemporary software.

Understand that when Hoare coined the phrase "billion-dollar mistake," he was referring to his addition of null references to ALGOL W. ALGOL W references are not C pointers that allow willy-nilly pointer arithmetic and all the UB that come's with that. An explicit design goal of ALGOL W was to prevent unsafe dereferences. A dereference of a null reference in ALGOL W is defined behavior and yields a runtime error.

    NULL OR UNDEFINED REFERENCE
        An attempt has been made to access a record field using a null or
        never initialized reference.

That said, ALGOL W isn't memory safe either: it attempts to mitigate memory violations, but this is not comprehensive.

If you add <WarningsAsErrors>nullable</WarningsAsErrors>, the below will not compile:

  var bytes = (byte[]?)null;
  Console.WriteLine(bytes.Length);

That and, well, all variables must be assigned before use. You'd be right to point out it's a band-aid, a convenient one but still.

As you know, that has no benefit for any dependencies you have in play.

What do you mean?

Making these warning into errors applies to the code you're writing. That's great: you're code won't dereference nulls for the most part. However, your code nearly always relies on dependencies. Those dependencies can still dereference nulls, and you can still encounter exceptions.

This is true. This is also rare in modern code, and impossible with standard library. Other libraries too are expected to adhere to nullability, which is a default whenever you create a new project, and many use the same WarningsAsErrors: nullable option on top of Nullable: enable set everywhere.

At the end of the day, scenarios like a library spawning a Goroutine which tries to dereference a null where it doesn't expect and experiencing an unhandled panic, crashing the application, are practically impossible in .NET. It is not necessarily watertight, especially around JSON serialization, but it certainly evokes a "can't believe you guys still struggle with nulls/nils" kind of reaction.

Yes! And people will defend this awful language!

I don't go that far. Mistakes were made, but golang has great properties as well.

I'm just amazed that, given that golang's inception is relatively recent, somehow this old lesson had not been learned by the designers. Accomplished and learned people created this language. How did that happen?

Go's design is laser focused on fast compile times at the expense of everything else.

Which is crazy. Even at Google scale the bottleneck to delivery is human reasoning about code changes, not so much build times.

While it's true that fast compilation was probably the primary asperation of golang's design, it wasn't the only concern, and there is nothing about eliminating nullability that would have compromised compile time. So I'm left to imagine that they just didn't know.

Reply on news.ycombinator.com