6 ms·
as opposed to?
by dabfiend19 5y ago
as opposed to?
- streblo 5y agoOptionals would have been a way to solve this problem
- logical42 5y agoYou know what's fun? Getting a nil where you are supposed to have an Optional.
- joshdev 5y agoSomebody has used Scala
- still_grokking 5y agoMore likely a Java lib form Scala than Scala as such. In "pure" Scala (not in the FP sense, but just without mixing with Java) something like that is almost impossible.
- marwis 5y agoUnless something drastically changed in Scala 3, there is nothing to protect you from null in Scala. In fact even Java is effectively safer thanks to all the null checking done by IntelliJ
- still_grokking 5y agoNull is basically non-existent in idiomatic Scala. So technically you're right but besides calling Java libs there is only an infinitesimal small chance to get NPEs form Scala code. (Scala's NPE is the MatchException ;-)). For Scala 3 there are improvements. It's "null safe" as long as you opt-in (modulo Java libs, and of course doing stupid things like casting a null to some other type). https://docs.scala-lang.org/scala3/reference/other-new-features/explicit-nulls.html https://docs.scala-lang.org/scala3/reference/other-new-featu...
- joshdev 5y agoIdiomatic scala yes, but while on boarding engineers hit many cases, where they ended up returning null in places they shouldn’t.
- still_grokking 5y agoSo you actually complaining about people who don't know what they're doing? How is this related to Scala? When you have people without clue on the team no language will safe you. You can also crash Haskell programs by throwing exceptions or just using List.head…
- marwis 5y agoI'd say safety implies safety from incompetent developers. Similar to the use of the word in memory safety.
- mattnewton 5y agoAfaik this is impossible in swift and kotlin, only optional values can contain nill.
- tbarbugli 5y agoTry Core Data with Swift and you will see that happening. Lazy objects (vaults) are mapped from objc into Swift and will happily crash on something like a = b where both are not optional.
- mattnewton 5y agoThis is happening in objc code or in the swift part? I'm not terribly surprised though, my one experience with core data was miserable once we strayed even a little from the happy path and I ended up rolling my own since we didn't need full functionality anyways. And this was for an internal app, at Apple ┐( ∵ )┌
- logical42 5y agoIt's possible in Java.
- mattnewton 5y agoRight, because the language has the "million dollar mistake" of nullable references by default, which you cannot change without breaking code. And the original comment was bemoaning that Go choose to to have nullable references by default too.
- rowanG077 5y agoso... Just make that impossible. It's not like this is unprecedented at this point. It's a standard feature even C++ of all languages supports.
- magicalhippo 5y agoSo you get an Optional which haven't been set instead of a nil pointer. What's better about that?
- SquishyPanda23 5y agoThe type system knows about it and you're forced to check it
- magicalhippo 5y agoRight, but my point is, the code which would raise an error because the pointer is nil now raises an error because the Optional is not set. Is there really that much of a difference between those cases? I agree though that in an interface, Optional conveys a more explicit meaning than something pointer-like, which is always a good thing.
- SquishyPanda23 5y agoIn practice it does make a big difference because if the type system knows about it then it can enforce handling of the exception. (Or more generally, it can just force you to pattern match on the optional time and make sure you handle the empty case.) Go programs crash at runtime. In general, program failures and bugs should surface as soon as possible. Ideally no later than compile time. Instead, Go makes you wait until the app is running. For an app that has a lot of configuration options, for example, there can be a latent bug that crashes the binary for some options. And that bug may not be detected for months because nobody was using that combination of config options. The only real defense of this is to pepper your code with a bunch of nil checks. But these nil checks are also hard to test, so Go devs just learn to ignore missing code coverage. In fact, your code coverage metrics look better if you don't check for nil. I'm sure at some point Go or a library will offer a version of optional types that is well-adopted. But my point is that by the time Go was designed, null references were already widely considered a bad idea and the source of a huge class of computer bugs. Go still deliberately designed them into the type system.
- drvd 5y ago
- SquishyPanda23 5y agoMost modern languages have solved the problem. There are a variety of ways to do it.
- pkaye 5y agoCan you list the variety of ways?
- mattnewton 5y agoUsually it's forcing the programmer to handle the null case statically, by wrapping the underlying value in something like an optional type and defining the operations that access the underlying value. Think of swift's optional unwrapping in "if let" statements
- SquishyPanda23 5y agoBasically if you need to manipulate pointers, use safe pointers and keep track of pointer ownership. This is how modern C++ and Rust work. If you don't need to manipulate pointers then nil really just represents a degenerate or optional value. For optional values these can be encoded any number of ways depending on the type system. One common pattern is an optional type. Another is to annotate the type to indicate that it might be null. The idea is that if a programmer doesn't check that an nullable or optional type is missing then the program should fail at compile time instead of crashing at runtime. Golang chose to crash programs at runtime. So for whatever reason, Go has decided that null pointer dereferences are not a big deal. But God help you if you try to comment out a variable use without assigning it to "_". Then the program fails to compile.
- Zababa 5y ago> So for whatever reason, Go has decided that null pointer dereferences are not a big deal. But God help you if you try to comment out a variable use without assigning it to "_". Then the program fails to compile. I think that's a good explanation of why people are so frustrated with this. There are lots of features like go fmt, go vet, the compiler checking that you use all variables and all imports that can feel a bit restrictive. But for something like null pointers, there is nothing. It's incoherent.
- still_grokking 5y agoAs opposed to some modern type system feature that would catch such bugs at compile time rather than let them happen at runtime.