4 ms·
> dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine. Yeah, these are exactly the things I don't want to see:
by vesak 8y ago
> dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine.
Yeah, these are exactly the things I don't want to see: production log messages saying that something or other referred to a nil pointer and thus crashed some process. I don't think they belong to modern programming.
Sure, segfaults are even worse since you don't even get the log message, but I still kinda lump both of these problems together as "errors from the 1900s that shouldn't happen anymore".
- matthewmacleod 8y agoTotally 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.
- user5994461 8y agoNULL exists in every programming language. There must be something to designate a missing value, a non assigned pointer or reference.
- ancarda 8y agoMost languages, sure, but not all; Haskell doesn’t have NULL. You can express the absense of a value with a Maybe: Just “value” -> Maybe String Nothing -> Maybe a If your function returns a “Maybe String”, it can either be just a value, or Nothing. However, if a function returns a “String”, you can’t return Nothing, only an actual String. There’s no null in Haskell.
- baq 8y agoyeah... no. most notably rust, which might be surprising as it can be used (and has been) to write a kernel in, only has null pointers in unsafe code. rust is hardly the first one, too.
- masklinn 8y ago> NULL exists in every programming language. No. > There must be something to designate a missing value, a non assigned pointer or reference Option types are something like 45 years old, they're not exactly futuristic technology.
- antonvs 8y agoThere has to be a way to represent a missing value, but the key point in languages that don't have NULL is that you can only represent missing values using a type that supports missing values - e.g. option types such as Haskell's Maybe. This achieves two things: 1. It allows you to define functions that cannot return NULL, and the compiler guarantees this. This is a huge win - you no longer have NULL as a possible return value for many functions. 2. Values belonging to the option type have to be unwrapped to access their contents, so it's not possible to unknowingly dereference a missing value. This is an even bigger win than #1, because it can literally eliminate null pointer errors. A caveat to #2 is that depending on the language, it may be possible to override safety, for example Haskell's fromJust can throw an exception if used on a missing value. But this tends to require conscious effort, and can easily be checked for automatically, since it involves the use of unsafe function calls.