The fact that safe language implementations have to think hard about how to handle null pointer exceptions safely should have been a warning sign that null pointers are a bad thing to have in a language. Sadly nearly always unheeded.
Conversation
This Tweet is from a suspended account. Learn more
Don't have automatic zero initialization (or uninitialized data usage) and don't support null as a value for assignment to pointers. You won't have null pointers. An optional value isn't usually what's wanted and when it's desired it can and should be done explicitly instead.
1
1
3
I think the main reason that Go has null pointers is because for whatever reason they really wanted to support automatic zero initialization as the solution to uninitialized data, instead of forcing initialization before possible use via very trivial basic flow control analysis.
1
1
This means that every type in Go has a 'default' zero-based initialization, despite that often not making any sense. It causes a whole class of issues including but not limited to null pointers. I don't think it's good language design. I don't see a compelling reason to do this.
1
1
1
I like using languages with first-class tagged unions (sum types) and it steers a lot of the language design in the right direction. It covers the optional value case, provides a nice composable way to handle errors via type system support and steers it away from ugly features.
It makes it far less likely that the language is going to have exceptions and I'm not a fan of invisible control flow. Unpopular opinion based on wanting robust code compile-time errors instead of runtime: Java's checked exceptions are way less bad than the unchecked exceptions.
2
2
This Tweet is from a suspended account. Learn more
Show replies