Hacker News Reader

Comment by cageface | Hacker News Reader

Lack of null safety is still a major shortcoming in my book compared to Rust/Swift/Typescript.

I never had a real issues with null safety in 3 years of using Go regularly. Maybe due to may long experience with Java which might have sharpened my eyes for null safety.

Lack of enums and pattern matching is IMO the bigger issue. I miss that regularly.

null safety: Can you provide us a reference to a working definition of the term?

For example in Typescript, you can specify whether a parameter is allowed to be null in the signature of a function. If you do the compiler will make sure that you don't accidentally pass a null value to that function.

  function foo(x: number) {
    return x + 1;
  }

  let y = null;
  foo(y); // compiler will flag this

In Go

    func foo(x int) { return x + 1 }
    var y *int = nil
    foo(y) // compiler will flag thi

Now add an error to foo and have x=0 as a valid return value, or even worse, having to deal differently with different errors.

That wasn't the greatest example as Go doesn't really have any way to represent it. If it did it might be something like this.

  type MyStruct struct {
    Name string
  }

  var-not-nil myStruct = &MyStruct{"Hello"} // this is a "not-nil" pointer variable

  myStruct = nil // compiler would catch this

The idea being to allow variables to hold and pass pointers to structs like now but ensure they are never nil.

null/nil can only occur in scoped use cases (Option<Foo>, Foo | null, Foo?) and so the compiler can warn you when something could be missing and you don't handle it without being incredibly noisy.

Reply on news.ycombinator.com