Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming Google

Google's Dart Programming Language Soon Won't Take 'Null' For an Answer (theregister.com) 43

Posted by EditorDavid from the death-null dept.
"When the third major release of the Dart programming language debuts in mid-2023, null values will no longer be allowed where they're not expected," reports the Register: Null in this context is an assignment value indicating the absence of a value or referenced object.... Dart, an object-oriented, garbage-collected C-like language that once aspired to replace JavaScript, supported sound null safety — a way to prevent errors from accessing variables set to null — as of version 2.12. But it maintained modes for running code without null safety or with partial null safety. Dart 3 will no longer entertain those suboptimal possibilities.

"Our next release, Dart 3, completes the journey to a fully sound null safe language," explained Michael Thomsen, product manager on Dart and Flutter, in a blog post. "As the last step of that journey, we're removing several historical Dart language and SDK artifacts, including removing support for running without sound null safety." Sound null safety, Thomsen explains, means that a non-nullable variable never contains a null value. Not every implementation of null safety is so certain: TypeScript, for example, is unsound — you can assign a null value to a non-null variable. C# has exceptions to its null checks. And Kotlin also has exceptions.

Dart's transition will help catch type-related bugs at compile time, and should improve code readability, maintainability, and ahead-of-time (AOT) compilation. There's a cost however. Sound null safety will be the only option so pubspec files — Dart package metadata — with an SDK constraint set for less than 2.12 will no longer resolve in Dart 3. According to Thomsen, about 85 percent of Flutter code (which is written in Dart) supports sound null safety at this point. Those with apps and packages in the remaining 15 percent are urged to adapt their code prior to Dart 3's arrival....

Following the release of Dart 3, the next significant milestone for the language is likely to be support for compiling Dart code into WebAssembly (Wasm), which will allow Flutter Web apps to run as native code in browsers.
This discussion has been archived. No new comments can be posted.

Google's Dart Programming Language Soon Won't Take 'Null' For an Answer More

Google's Dart Programming Language Soon Won't Take 'Null' For an Answer

Comments Filter:

  • shoot the messenger (Score:4, Interesting)

    by bugs2squash ( 1132591 ) on Saturday December 10, 2022 @06:01PM (#63119806)

    you didn't handle the problem when your resource allocation did not work ? Let's blame null.

    you want to put in a sentinel when you've reached the end of the data ? Let's re-invent null

    just don't call it null

    • Re: (Score:2)

      by znrt ( 2424692 )

      it makes total sense that they are obsessed with fool-proofness for a programming tool that only a fool would use.
       

      • Given Google's penchant for dropping things almost as fast as they create them, yes, only a fool would use one of their languages.

        • imho this is only true for beta consumer apps. Not technologies they are also using internally. They have been maintaining GWT for way longer than any sane person round have considered using it..

          Fwiw, dart is already 11 years old and instead of killing it and developing something from scratch they painstakingly developed a migration path and lots of tools to migrate from the new nnbd type system. I've migrated quite a bit of code, certainly not easy.. but considering the paradigm shift from the first dart v

    • just don't call it null

      I called it null once, but I think I got away with it!

    • Re:shoot the messenger (Score:4, Informative)

      by _xeno_ ( 155264 ) on Saturday December 10, 2022 @08:53PM (#63120224) Homepage Journal

      Strong null safety doesn't get rid of null, it just makes it so you have to explicitly mark where it can happen. It tends to make the code cleaner because, turns out, most of the time, you don't want to allow null values.

      If you have a valid reason to allow a value to be null - and they exist, and exist in the Dart API, and will continue to exist even in Dart 3 - you still can. You just have to mark a variable or argument or return value as being nullable. (Which I'm fairly sure is done by just adding a ? to the type name, so instead of "object" you'd say "object?".)

      What the compiler does is insist that every time you dereference a reference that could be null, you check for null. This makes it so that you can prove that a variable that's marked as non-null can never be null: it must be initialized to a non-null reference, and it must never be set to a reference that could be null.

      If you have a reason to return null, it's still there, ready for use. It just has to be used "safely."

      • This works when the compiler is perfect and infinity smart.

        Rust with its no Null and borrow checker just works, most of the time. But when it does not work, it literally prevents you from coding. It is fantastic getting the compiler to do more work to verify your program, no one wants to just wrap 1% of their program in `unsafe` just because the compiler is too stupid to understand fairly simply linear code.

        • And even when it does work it takes code like this V

          if(split_str){//null == false
          int [] arr = "5,6,3,78,2,4,7,34,6,4,2".split(split_str);}

          And turns it into this V

          if(split_str.is_some){ //need to clone or ref if you need to use split_str again anywhere else I think
          let arr = "5,6,3,78,2,4,7,34,6,4,2".split(split_str.as_ref().expect("I just checked if this is not null, why do I need to check again?"));}

    • you didn't handle the problem when your resource allocation did not work ?

      That's the ENTIRE point of null safety. It's not supposed to be optional, then why is it optional? You get the expected type or deal with an exception. That's all null safety is, a language enforcing that basic premise.

      You're saying don't shoot the messenger when a null is like having a process server leave a document on a front porch and walk away. That is 100% a messenger problem.

    • The point with non-nullability is to _not_ use flag values, but where possible, change the flow such that it's not an issue. At the very least your code will have more specific exceptions closer to the source of the error than 'null encountered.' I realize it's not that useful with libraries designed around having null, but new code can benefit. It also cuts down on null check code smells when you know it isn't gonna be null, but can't prove it heuristically.
  • Now if only someone would just use Dart, they could see how cool non-nullability is!
  • How does that work with the dart:ffi C interoperability API?
    • You can still have nullable values in dart. They just have to be explicitly used.

      int foo = null; // Trying to assign null to a variable of type integer will cause a compile time error.

      int? nullableFoo = null; // This is A.O.K. as the variable is declared as a nullable integer.

      This headline is not really news for anyone who is using Dart. It is a change that has been in the works for a long time, and null-safe dart (what we are talking about here.) has been standard for years now. Users of legac

  • Go came and went and now Dart is darting across the language landscape?

    • Re: (Score:2)

      by Entrope ( 68843 )

      They've co-existed for quite some time. They have different target use cases. Go is meant for developing server software and command-line applications. Dart is designed for user interfaces, whether in a web app or a mobile device.

    • Go went? Go is still growing strong as far as I am aware.
  • Next release: Dart removed digit zero as a way to prevent division by zero errors. Dart will no longer entertain those suboptimal possibilities. Only digits from one to nine shall be allowed.
    • They will then be able to take the next step, which is to require all numbers to be expressed in Roman numerals.

    • Next release: Dart removed digit zero as a way to prevent division by zero errors. Dart will no longer entertain those suboptimal possibilities.

      This isn't a joke, should a processor figure 8 / 0 = 0 and set an error bit somewhere instead of firing an interrupt? It's your fault for not checking the error bit after doing a "potentially dangerous" division after all.

      • Zero is nothing, so 8 divided by nothing is still 8. What's the problem? This is how computers should have treated division by zero from the start! One less problem to worry about.

        • If you divide 8 by 0 ... it does not matter what the compiler or the hardware is doing, or what exactly the result is: you have a problem.

          A compiler or runtime system showing the problem, or even a processor halting: is showing you that you gave a problem

          Pretending there is no problem just because there is no ERROR, is idiotic.

          Hint:
          8 / 2 yields 4
          8 / 3 yields 2
          8 / 4 yields 2
          8 / 5 yields 1 ...
          8 / 8 yields 1

          I'm sure you notice a trend on the right side. Why the funk you think that 8 / 0 yielding 8 makes any se

      • huh? 8/0=Infinity... Dart gets that one right..

        • huh? 8/0=Infinity... Dart gets that one right..

          Try & Catch In Dart:

          void main() {
          int a = 18;
          int b = 0;
          int res;

          try {
          res = a ~/ b;
          }
          catch(ex) {
          print(ex);
          }
          }

          Output:
          IntegerDivisionByZeroException [dart.dev]

          • Errr... that's undefined. If you want to return infinity you would need to find a way to express the type of infinity. Not all infinities are equal.
        • Not for integers. The IEEE specification for floating point numbers has a way to represent the special values like infinity or NaN, but the integer types don't. If you wanted some kind of automatic behavior the result should probably be the maximum value for the type, which is what you would expect if you performed floating point division on the numbers and them explicitly converted the the result back to an integer.

          This is still a bad idea though because it doesn't handle the case where you take 0/0 whi

  • Coders everywhere are breathing a sigh of apathy...

    • For the first time in years, I actually RTFA, and I've got to agree. It is a nice gauge of the boredom level of language developers though.

      • It's actually surprisingly great.

        It's easy to see ways for the feature to be annoying--nobody likes to spend their time jumping through hoops to make the compiler happy-- but fortunately the way it's designed strikes an extremely fine and good balance between stopping bad things and getting out of your way.

        For example, a variable or field can be marked "late" to say: I know the compiler can't prove this will be initialized before it's accessed, but I promise to do that, so pretend it's proved. Then the comp

        • It's probably because I've been doing this too long that now the only interesting cases of null reference/pointer exceptions are the ones that come out of those situations where you'd have to mark it "late". The regular, "doh!" cases that this really helps with have been trained out of me...at least until senility sets in.

  • Will this solve the problem when people's last name [wired.com] is Null [bbc.com]?

  • Just define a null_object for every type (Score:3)

    by khchung ( 462899 ) on Saturday December 10, 2022 @08:05PM (#63120092) Journal

    Then you masked away the real the cause for having null references, but that wouldn't solve anything.

    You can do that in Java/C++/C# too, just (in Java as example)

    public class X
    {
          public static final X null_x = new X(); ...
    }

    Then you use null_x instead of null, and initialise every object of X with null_x. Voila! No null references. Wouldn't actually solve anything though.

    • You've missed the point.

      The point isn't to replace null with something else, the point is to create null safety by ensuring that references can only be null if they're declared to be allowed to be null, and if you ever dereference a nullable reference -- or assign it to a non-nullable reference, even implicitly -- you must check it for null first.

  • can relate...

  • There are a lot of people here bashing dart. I for one really enjoy using it. I find it easy to understand and use. Unfortunately it is a bit pigeon-holed at the moment as the Flutter language. I'll admit the dart ecosystem does need more diversity, but the language itself seems to be attracting unwarranted disdain.
    I don't know. Perhaps it is cool to hate on things you don't personally like? If dart is not for you I can understand that, but why does everyone want to rain on Dart's parade?

  • Sounds like Dart is just doing the same thing Swift does (and I'm sure a bunch of programming languages before it).

    If a variable can have a value of null, it's a different data type, e.g.:

    var alwaysHere: String
    var sometimesHere: Optional[String]

    now if you want to assign a value to a never null from a sometimes null, you just have to tell it what to do in case of null e.g.

    alwaysHere = sometimesHere or "empty"

    They are not getting rid of the concept of null.

Slashdot Top Deals

The biggest difference between time and space is that you can't reuse time. -- Merrick Furst

Close