3 ms·
Totally agreed. A modern type system should make these errors fundamentally impossible. If you see them in production, it means there is definitely a logic or e
by matthewmacleod 8y ago
Totally agreed. A modern type system should make these errors fundamentally impossible. If you see them in production, it means there is definitely a logic or error handling issue somewhere in your code and I find it weird that there's no support for a known technique for eliminating them.
- SamReidHughes 8y agoYou can't actually accomplish that without making the language really complicated.
- vesak 8y agoAre Crystal, Kotlin and Swift really complicated? Is Rust's complications due to null protections or something else?
- SamReidHughes 8y agoAre you joking? They're all way more complicated than Go.
- vesak 8y agoOkay, let's pretend that's true. Are the complications due to null protection being there, or are they due some other things?
- SamReidHughes 8y agoSome of the complications are necessary. You either need generics or a whole bunch of primitives to have non-nullable references. Go would also have to replace slices with something different. Return types and the shape of the interfaces would have to be changed. Algebraic datatypes or some complicated way of defining return types would need to be added for it to be usable. Defer statements that can modify the function's return value would need to be handleable by the type system, or dropped.