5 ms·
"For Dart, we chose the path of sound null safety." Null Safety is the killer feature of modern programming languages like Swift and Kotlin. It provides a clar
by johnthuss 4y ago
"For Dart, we chose the path of sound null safety."
Null Safety is the killer feature of modern programming languages like Swift and Kotlin. It provides a clarity you just can't get otherwise and saves you from runtime errors. And it requires very little additional ceremony to use.
- IshKebab 4y agoI'd say it is more like a basic requirement than a killer feature at this point.
- johnthuss 4y agoWhile I love null safety, It's hardly a given. For Dart in particular, it sounds like there was a serious discussion about the choice, and it could have gone the other way. (edit: removed incorrect statement about Python's type safety)
- masklinn 4y ago> languages like Python that don't provide any static type safety https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html https://github.com/python/mypy https://github.com/python/mypy > let alone null safety https://docs.python.org/3/library/typing.html#typing.Optional https://docs.python.org/3/library/typing.html#typing.Optiona...
- The_Colonel 4y agoFWIW my (1 year old) experience with mypy was very poor. Stuff breaking between releases, wrong resolution, bugs. It kinda felt like a 3rd party fun project, not an official high quality solution. The fact that the source can contain completely wrong declarations and Python will happily run it anyway felt really bad. It's kinda like JavaDoc rather than a classic type system.
- IshKebab 4y agoLanguages like Java, Go and C were all designed before it became obvious that `Option<>` or `?` were obviously the right thing to do. You can live with it, but most language eventually add some way to deal with it. Java has @NonNull. Javascript and Python both have static type annotations that are non-nullable. Even C++ has some attempt at it (std::option<>). The only one I know of that hasn't bothered trying is Go.
- mrkeen 4y agoBut the absence of nulls is the feature, not the presence of Option.
- the_gipsy 4y agoZero-values and pointers-as-options is not even half as good as Option<T>. At best, it was easy to implement, and convenient to use, until you actually had to run the program.
- Quekid5 4y agoGo absolutely wasn't. It has been obvious since ML and Haskell.
- pjmlp 4y agoC yes, Standard ML was already a thing when Java and Go came to be, and even plenty of other ML derived languages.
- munificent 4y ago> For Dart in particular, it sounds like there was a serious discussion about the choice Yes, we debated it for years. Literally the day we launched, a user filed an issue requesting support for null safety: https://github.com/dart-lang/sdk/issues/22 https://github.com/dart-lang/sdk/issues/22 For most of Dart's history, that was the #1 upvoted issue on the issue tracker. Back in 2011 before I worked directly the language, I proposed null safety: http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-null-safety-in-dart/ http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-... I'm immensely glad we finally did it, even though the migration has been a ton of work.
- gogogogogogogo 4y agoGo doesn't have null-safety, so it seems more like a nice-to-have based on Go's success.
- satvikpendem 4y agoPlease don't make new accounts to reply to a single comment.
- foverzar 4y agoI dunno, we had a terrible experience with Go nils at my current job: - It's super-easy to create a situation where some some obscure code fragment can cause a panic and crash the whole app due to nil pointer access, especially in multithreaded scenarios - We had to start using linters to track possible nil errors early on - Eventually we just moved to Kotlin, where this is not an issue - And don't get me started on nil interfaces, good luck properly checking nilability and tracking these kind of issues
- masklinn 4y agoAn other fun one is that methods may or may not receive nils depending whether they’re defined with a value or a pointer receiver.
- gogogogogogogo 4y agoI mean all of those things are downsides to having unsafe nullability. However, my point was that those things obviously aren't deal breakers for many, many people as Go is still extremely popular.
- mrkeen 4y agoI feel the same. My problem is that my teammates (future and past) will continue using null deliberately. Makes it a bit hard to eliminate.
- kaba0 4y agoI don’t know, it is quite trivial to statically analyze nulls, so even with basic IDE analysis I don’t even remember the last time I got an NPE in Java. To put such a basic thing as a “killer feature” doesn’t make for a good advertisement :D
- mrcrumb1 4y agoYes, but the ergonomics of working with nullable data in Java are generally bad, and you have to do it everywhere
- kaba0 4y agoWell, try to minimize the usage of nulls in your programs then :D For mappings between objects’ deeply nested properties I found mapstruct to be the best tool which will handle it correctly either way.
- mrcrumb1 4y agoI don't have 100% control of my coworkers or library writers. Knowing whether a library or a coworker can hand me back an optional value seems like a pretty basic thing for a language to tell you
- geyforkotlin 4y ago> Well, try to minimize the usage of nulls in your programs then :D I am a java guy since 1.1 and it seems to me that a lot of problems in Java come down to it being designed for a time when a application mainly consisted of in-house / in-org / self-written code. In $currentYear, however, we mostly plug libraries into frameworks and it's just a pain to check every call and every return value for the possibilities of null. Yeah, it can be done but I just don't like having to read library source code to find out if it will return a null in some cases.
- KMag 4y agoOpen-source libraries were much less common when Java first arrived, but third-party C / Fortran libraries were very common in many domains much before Java arrived. Nulls, arrays degenerating into pointers (losing size information), and accidentally crossing enum types across libraries were all huge sources of bugs. Java doesn't have much of an excuse for its treatment of nullability, other than they were trying to court C/C++ developers.
- pjmlp 4y agoThey are so modern, catching up with ML in 1976....
- didibus 4y agoI feel null isn't the real problem, the problem is the lack of semantics attached to null. NotNull, or so called "null safety" makes it that when you know something is not optional, if a null is passed to it, you know it's a bug. But when you do have null again, by making something nullable, the million dollar problem is back, in that you don't know why it's null? Is it null because it's missing, false, errored, eof, leaf node, etc. You don't know. In my opinion what we would need is union types, and simply never use null for anything, remove it completely. Instead you could declare a function returns a Value or Missing. Or it would return a Value or False. Or it would return a Value or EndOfFile. And similarly you could say: User { String|NotProvided email; } Where email on user can be either a String or NotProvided. You wouldn't want the NotProvided, EndOfFile, and all that to be full on classes though, just like type aliases of some sort, similar to null in a way, but it adds semantics. if (email == NotProvided) { ... } And the language compiler would error if you try to use it where it doesn't work without checking: String email = user.email; // Error if (user.email != NotProvided) { String email = user.email } // No error
- scotty79 4y agoTypescript does pretty much exactly what you want. Also try Rust. It's close to what you want.
- rpigab 4y agoThat's exactly why I love Rust. Of course, if you don't want to write good Rust or are lazy, you can "reimplement" null with the Option enum and unwrap() it everytime, so your code panics everytime, or do the same by returning errors without thinking about if your code should move on. You still have to think about it, but at least you're not doing null checks AND Option.NONE checks, which is extremely tedious in Java, for instance. So, for a quick script or rapid prototyping, just unwrap/panic if you don't care about the result, like in a short code contest, and for any other use, refrain from using these, match all possibilities, implement a strongly typed Error management.
- geyforkotlin 4y agobasically that's how it works in Kotlin (and Dart and others) already. String? is String|null and it's a compiler error to reference a member without a prior null check. In Kotlin (and others) it's extremely ergonomic, too. You just say foo?.bar and coalesce with ?: so val baz = foo?.bar ?: "foo or bar is null" In certain cases the Kotlin compiler will infer non-nullable type after an explicit null check just like in your example such that fun bestFunction(foo : String?) { if(foo == null) return foo.baz <- //now legal to call without .? }