6 ms·
Sane languages have pointers which either can't be null or require you to check explicitly. Rather than leaving it to explode at runtime.
by xdfgh1112 4y ago
Sane languages have pointers which either can't be null or require you to check explicitly. Rather than leaving it to explode at runtime.
- tedunangst 4y agoTell me more about these unexplodable languages.
- giraffe_lady 4y agoMaybe Some other time.
- dtech 4y agoIf this question is in good faith, for example Kotlin differentiates between the nullable T? and the non-nullable T. An if x != null check automatically casts T? to T. You can't call a method on T?, preventing null pointer exceptions. C# and Typescript have similar language support. Other languages push users away from the problem by favoring monadic Optional/Maybe solutions.
- adastra22 4y agoT? is just syntactic sugar for Optional/Maybe, no?
- MrJohz 4y agoRoughly, yes. But that's the point: an Optional type along with static typing preventing misuse can prevent these sorts of errors entirely.
- shirogane86x 4y agoI don't think that's quite true. It's sort of the same in how it's used, but the main difference is that T? (or T | null) is a union, and Optional/Maybe/Option is a sum type. Out of all the implementations I've seen, T? can't be nested - you can't have T??, whereas it's quite possible to have a Option<Option<T>> (and it's sometimes useful).
- dtech 4y agoIt's semantically similar but not syntactic sugar, since it is not translated to Optional or wrapper types, so it also doesn't incur the overhead of Optional. I actually like the language support more, as it flows a lot better than the (flat)map chain you get in monadic style. Similar to async/await v.s. Future.
- tedunangst 4y agoThere are some differences here, but you can't for instance use a string pointer with string functions in go either. IMO The distinction between pointer and optional is not as vast as people make it out to be. (But thanks, I overlooked T? conversions inside if.)
- morelisp 4y agoYou can call a value method on a nil pointer and it panics, though, which I think was a mistake.
- akavi 4y agoThe distinction between pointer and optional is not vast. The distinction between pointer and not optional is. The whole idea of optional is to make not optional possible.
- ricardobeat 4y agoNo you can't, but Go will happily de-reference the pointer without a null check, and your "string" will blow up in production: https://go.dev/play/p/7EVa7q6VgIM https://go.dev/play/p/7EVa7q6VgIM
- nemothekid 4y ago>The distinction between pointer and optional is not as vast as people make it out to be. The billion dollar mistake is overblown?
- adastra22 4y agoRust being the popular example. But even C++ has this with std::optional, for example.
- tedunangst 4y agoSo rust doesn't explode if I unwrap None?
- avgcorrection 4y agoThe comment that you respondend to: > > Sane languages have pointers which either can't be null or require you to check explicitly. You cannot try to dereference a nullable pointer in safe Rust. It has got nothing to do with Optional (Some/None).
- tedunangst 4y agoThat would make a rust pointer rather less useful for representing sql null, no?
- imron 4y agoCorrect, which is why you'd use Option<T> instead.
- avgcorrection 4y agoWhat? The comment that you -- with aloof disbelief -- replied to only talked about pointers. I don't know what point you think you are proving with these pithy replies. It sure does go above my head. :)
- tedunangst 4y agoWell, this is a thread about storing sql null. I'm trying to suss out how sane languages represent sql null in a way that can't go wrong. So far the answers mostly seem to be use a type that can't represent sql null or use a type that explodes when you use it wrong. With a side of real programmers don't let bugs pass code review.
- worik 4y agoYou cannot use a null pointer in Rust. I am a Rust novice but I have not found a way to get to uninitialised memory in safe Rust. Yet.
- tedunangst 4y agoHow do you create a pointer to uninitialized memory in go?
- Gwypaas 4y agoYou can't. But a runtime panic also very easily causes an outage. At least it's not as subtle. Still. Rust is infinitely better in this regard. Go feels like a crude hammer, especially regarding the default interaction between deserialization and missing struct members.
- TheDong 4y agoAll it takes is a specially formatted comment /* int g() { volatile int x; return x; } */ import "C" import "fmt" func main() { fmt.Printf("%d\n", C.g()) } But I know you'll say that 'import "C"' or 'import "unsafe"' is the same thing as using an unsafe block in rust or such, and really shouldn't count against go. Which is fair and true, but you're chasing down a pointless detail. The point isn't that go is memory unsafe. It's not. The point is that Go's type-system is not powerful enough to express various types of type-safety, and as such it's an error-prone language where you can expect null pointer exceptions frequently.
- stouset 4y agoYou can't. But you can absolutely have a `nil` that will unavoiad runtime panics if you don't check it. And further, you only can't do this because go defines by fiat that the zero-value of a type must be legal. Of course, this is wildly inconvenient and annoying for many types, including those that come bundled in the standard library. There are other, very convincingly better options to this that many in this thread have been trying to teach you about in the expectation that your responses have been in good faith.
- 4y ago
- stouset 4y agoType systems can enforce that types always contain a value of that type and cannot be null. There is another type that is either null or a value of the enclosed type. At any boundary where something might be null, you do the null check. If it's null, you do whatever logic is necessary right there and only right there. That might be to skip the computation, to use a default value, to get the value from somewhere else, to return an error, or whatever. If it's not null, you use the internal value and from then on every user can operate on a guarantee that it's not null.
- saghm 4y ago>> Sane languages have pointers which either can't be null or require you to check explicitly. Rather than leaving it to explode at runtime. > Tell me more about these unexplodable languages. I don't think anyone else mentioned an entire language being unexplodable, just a pointer type. Later on the thread you talk about `Option` in Rust, which is not what I think most people would consider a pointer type, but even if it is, it's certainly not the only one. I think GP was talking about the basic reference type (i.e. `&T`), which will not ever be null in safe code, so dereferencing it will not explode.
- anonymoushn 4y agoZig encodes optionality separately from pointer-ness, like Rust. You don't have to ask about unwrapping None in cases where None is not a member of &T.