Re:Learn Go: Hand-crafted Go exercises and examples
by SureshG on Sunday May 17, 2020 @12:55PM
(#23213252)
Kotlin is one example where it's difficult to make that mistake. Kotlin does provide nullable type and everything can check at compile time and it so good. So if write code in pure kotlin (java interop has null issues) you can avoid null pointer errors. It's really good.
Re:Learn Go: Hand-crafted Go exercises and examples
by sacado2 on Sunday May 17, 2020 @04:16PM
(#23215024)
I totally agree it's great and tend to enjoy languages that don't provide the user with unchecked nulls. It's a cool tool, but I don't think it's worth a billion dollars. If I had to choose, I'd rather take non-mutability by default rather than compile-time enforced checking of null pointers.
That "billion dollar mistakes" is an excellent marketing expression (nobody wants to make billion-dollar mistakes! We should avoid that null they talk about! It looks so expensive!) but I don't know how actually true it is. Do we have any kind of scientific paper that proves languages without null lead to way less expensive software than languages with null?
I'm not talking about memory unsafe languages like C or C++, but situations where, in a memory-safe language, a null pointer exception in production happened to cost a shitload of money.
I'm pretty sure I never had a nil dereferencing in production with my go code. Invalid array access, off-by-one-errors, yeah, sure, way too many, but very few languages can prevent them at compile time. But nil dereferencing? I can't remember that.