> Having nullability has its own set of issues. I prefer explicit error handling to null checks. Nullability does not preclude explicit checks. In fact it requ

> Having nullability has its own set of issues. I prefer explicit error handling to null checks. Nullability does not preclude explicit checks. In fact it requires them. Which Go currently does not: you can dereference any pointer or use any interface and it will blow in your face if either is nil. > C# is becoming more and more reliant on the compiler to handle type checks, but it also opens up the risk of more developer mistakes. That literally makes no sense. The entire point of moving checks to the compiler is that it catches developer errors upstream and prevents them. > C# needs it for its close integration with mssql and its exception handling. That's a nonsensical just-so story. Go on, explain how Haskell or Swift or Zig have explicit nullability for their close integration with mssql and exception handling (and while at it, do explain the relationship between exception handling and nullability)