Hacker News Reader

Comment by SomeHacker44 | Hacker News Reader

Given a reasonable choice, I would almost never use a language like Golang that doesn't enforce memory safety (at least, by default). Null pointers, ugh.

View on HN

Most of the traditional definitions of "memory safety" are not violated by having null pointers, as long as they just crash when used incorrectly. nils in Go don't let you start accessing things you shouldn't or anything. Golang is memory safe by most definitions. (Possibly not by a definition that includes concurrent memory safety. I expect in 20 or 30 years the term "memory safe" will indeed involve that. But at the moment, it doesn't, because almost no language has that right now.)

This doesn't invalidate your underlying point that you want to use a language without implicit nulls... it's just the wrong terminology.

I'd put that one under type safety, and it definitely seems bizarre to me to make a new language that claims to have strong, static typing and allow arbitrary types, or pointers to arbitrary types to be null.

Pascal has null. Does that mean it is dynamically typed?

It means every type in Pascal is actually a union of itself and null.

Go's nil is statically-typed. The nil keyword is polymorphic (as numbers in the source code are) but individual nils that occur at runtime in Go are actually typed. You can actually put methods on them and they execute just fine:

     type S struct{}

     func (s *S) Test() {
         if s == nil {
             fmt.Println("Nil pointer")
         } else {
             fmt.Println("Not nil pointer")
         }
     }

     func main () {
         var p *S
         p.Test()
     }

That will print "Nil pointer", not crash.

While I'm actually still in agreement that I don't love a language with nil pointers, it is less bad in Go because they are less pointy and stabby. It's not like C where they are automatically a crashing offense; they are valid values treated in sensible ways in a lot more places than in C, because in Go they still have their type associated with them. But I'd still like to be able to declare a non-nillable pointer type.

Please do note carefully the difference between less bad and not bad.

The type of s/p there can't be guaranteed to be (S not nil) at compile time, which is a bizarre decision in an otherwise-statically-typed language where the type system is designed to provide runtime type safety. You still have to do a null check at runtime if you want to be safe here

While it's nicer that you can perform the check inside Test() instead of before the call, I don't understand why the type system doesn't just prohibit this and make you use a union type if you want (S or nil) given that a lot more situations call for (S not nil) than (S or nil).

I don't use Go, but I thought that nulls in it were memory safe (i.e. they abort rather than corrupt); am I wrong?

If I'm not wrong, this is a non-sequitor on a post about Common Lisp as Common Lisp is untyped, but (by default; some implementations allow you to disable safety) safe.

Technically Common Lisp is optionally typed. You can add static typing if you feel like it, and it can give you a significant performance boost when you do.

Fortunately, I don't have to bother with it most of the time since the amount of code that is time-critical enough for it to matter is very small.

Reply on news.ycombinator.com