The road to Dart 3: A fully sound, null safe language

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;
    }

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) {
      ...
    }

    String email = user.email; // Error

    if (user.email != NotProvided) 
    {
      String email = user.email
    } // No error

i have a large set of scripts i use to automate the boring parts of my job. i originally wrote them in bash. past a certain amount of complexity, that became unworkable, so i ported it all to python. after about a year, i found python to be too limiting as well, based on my own coding style, so i am porting it all again, this time to dart.

the dart compiler makes it a cinch to create command-line apps that work on basically anything with a terminal.

I really feel that the way forward is something like Graal running multiple languages in the “one VM to rule them all”.

You're speaking from a place of general philosophy, but in practice (at least in my experience), the great majority of unchecked exceptions come from null references. In the TypeScript codebases I've worked on, the only runtime exceptions we really have to think about come from network requests and (unfortunately) JSON.parse(). You quickly learn to always handle those two cases, and with that we see basically zero unhandled errors in production

Of course we're talking about Dart and I don't know how commonly Dart throws unhandled exceptions or where they might come from, but I think it's a dramatic over-simplification to suggest it's not even worth trying to reduce errors just because unhandled exceptions are technically allowed at the language level

One of their headline libraries, angular dart, pushed out a broken release that stayed broken for nearly a year.

Dart was revived with flutter and I'm glad it's doing better. However, I have trust issues with the way google runs their projects. I simply don't know if they'll continue to support Dart/Flutter or if they'll drop it next year for something shiny.

I also don't appreciate the gaslighting that happened on the dart forums. There was a lot of "Oh, dart isn't dead, we are using it heavily and actively in google!" that happened when dart was very clearly abandoned by google. They pulled the exact same stunt with GWT before replacing it with J2CL.

I can't understand how this can be true when JavaScript/TypeScript exists, but I'm open to religious conversion. Can you share details of the desktop/mobile/web app(s) you've created with Dart?

Another mental block for me is the association with Flutter, since every Flutter app I've tried (iOS and web) feels uncomfortably strange.

It doesn't help Dart that Kotlin and Swift have been null safe languages for a decade now.

For anything I might do in Dart, there's a better alternative. For backend stuff, I'm going to write in Java or Kotlin. For frontend stuff, I'm going to write in JS or TypeScript. I like Flutter, but Flutter by itself isn't reason enough to adopt Dart.

Long term, if Jetpack for Desktop actually takes off, I don't see any reason to write in anything but Kotlin.

The null-safe language I've used the most is Rust. It is far from the hardest part of the language to learn, but the biggest impact day-to-day is that when constructing a new object, initial values for all the non-nullable fields have to be provided all-at-once. You can't have a constructor which is passed a `this` object full of nulls then fill in all the values later, instead the object is constructed whole in a single operation.

Otherwise the explicit distinction between T and Maybe T just makes life easier.

I think the sentiment behind the quote and its widespread use is correct however. It definitely does seem like the tradeoffs of null safety are worth it in the vast majority of cases. Most of us who use GC languages with massive runtimes sacrifice a lot more performance for a lot less value.

Close to none.

>Just because some dude with a fancy name said so doesn’t mean it’s true.

The dude is responsible for tons of what we take for granted. He is also the one who invented the null pointer, so there's that.

I'd take his expert opinion and experience on the matter over anybody referring to him as "a dude with a fancy name".

He didn't sit to calculate the money in damages from it's use - it was more of a figure of speech and a guess ("probably").

But it's very likely that the prodictivity losses from null errors, the consequences for security, program downtime, and so on, could trivially have costed 1 billion dollar in damages over the years - actually much more.

A single null error in one of the space code responsible from bringing down a NASA mission, could easily cost close to a billion itself.

In fact the memory safety industry (e.g. static analyzers and in memory analyzing tools), safety checks for nulls by consultants, and so on, industry easily has have 1 billion in profits over the last 40 years, so there's that...

But anecdotally I've experienced many null-pointer runtime errors, to the point where I very strongly believe having strict or even half-decent null checking reduces the amount of runtime errors my code produces non-negligibly. I'm sure not everyone has the same experience, but I strongly prefer languages with null safety (AKA marking a type "non-null", and then the compiler makes a good effort to ensure it's not null).

The billion dollar mistake was not null, it's languages that have a null value but don't support nullability in their type system.

Kotlin and Swift get this right.

Nullability/optionality is clearly useful. References/pointers are clearly useful. The problem is making them a single concept in a type system, thus requiring all references/pointers to be nullable and making it very awkward (such as forcing the user to manually declare a wrapper type holding a boolean and the wrapped value) to have optional values without making them references.

The conflation of referentiality and optionality in the most popular static type systems also bleeds over into mental shortcuts used by many programmers in dynamically typed languages when thinking about the types of parameters expected by functions/methods. Had Algol W, C, etc. kept optionality and referentiality separate in their type systems, I think Python/Ruby/Lisp etc. programmers would likely think more carefully when passing None into fuctions/methods.

It's not that null as a concept is a mistake, since a Option type has both Some and None, it's that in most mainstream languages, people have to implicitly deal with them rather than having the compiler checking it for them explicitly. And if the computer can check our work for us, why do we have to do it ourselves?

That's why it leads to mistakes and is why it's called a billion dollar mistake, because I'm sure at least 1 billion (possibly even 1 trillion) dollars worth of manpower, lost revenue and time have been spent dealing with nulls.

[0] https://en.wikipedia.org/wiki/Option_type

[1] https://en.wikipedia.org/wiki/Standard_ML#Pattern_matching

I don't have any particular side on this battle, I can use both approaches. I just don't think that it's a big deal.

The reason they spouted was due to "Low developer resources" due to the difficulty of C, so they swapped to a language pretty much only used by Googlers. Google now has control of sass, which then gives them greater influence (even greater than just having browser majority) over CSS Spec choices (see CSS Nesting spec).

    extension on Shape {
      double calculateArea() => switch (this) {
        Square(length: var l) => l * l,
        Circle(radius: var r) => math.pi * r * r
      };
    }

    example(Shape someShape) {
      print(someShape.calculateArea();
    }

It's really hard to do both approaches. (The fact that Java has an Option<T> type, but all references to it are also nullable, is sometimes a source of chagrin and sometimes hilarity to me.) If you want a nice user experience, consistency across the ecosystem is huge.

So when we decided what to do about statically checking for null reference errors, we went with nullable types (the same as Kotlin, TypeScript, and C# do) instead of option types (Swift, Rust, etc.). I wrote a long thing about my thinking on it here if you're curious:

https://medium.com/dartlang/why-nullable-types-7dd93c28c87a

It's a real trade-off. There aren't perfect solutions. Option types have some nice composability properties, but they tend to be more verbose and don't play as nice with the imperative control-flow heavy code that's idiomatic in C-derived languages.