Announcement

Collapse
No announcement yet.

AMD Is Hiring To Work On New Radeon Driver Tooling Written In Rust

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by dwagner View Post
    I hope they fell not victim to the illusion that the choice of programming language determines the quality of the software.
    I agree, especially considering how most things written in Rust are just wastes of time so they have COLORZ!!1 and GIT INTEGRATIONZ!!!

    And the projects are so negative, like Rust and dust... and Corrode... and "rip"grep...

    Comment


    • #42
      Originally posted by tildearrow View Post

      I agree, especially considering how most things written in Rust are just wastes of time so they have COLORZ!!1 and GIT INTEGRATIONZ!!!

      And the projects are so negative, like Rust and dust... and Corrode... and "rip"grep...
      And nushell, fish, Amethyst, servo, maidsafe, valora, eureka, funzy, rav1e,...

      Comment


      • #43
        Originally posted by oleid View Post
        The point is : you have to handle both cases with option, for nullable types you don't have to. And if you forgot, then bad things may happen.
        But in some languages (such as Kotlin) you cannot pass a variable of a nullable datatype as argument to a function that accepts a non-nullable datatype.
        I don't know if there is any difference.

        Originally posted by mmstick View Post

        Sadly, all of these statements are not true.

        - Async methods are supported
        - String interpolation is supported, though I personally prefer fomat
        - Not sure if you're actually serious about Option vs null.
        Oh, I wasn't aware of these third-party crates. Rust still doesn't natively support that without use of third-party crates though.

        Comment


        • #44
          Originally posted by uid313 View Post
          Oh, I wasn't aware of these third-party crates. Rust still doesn't natively support that without use of third-party crates though.
          It kinda does though. That fact that those crates exist and don't rely on any non-standard hacks is the point. There is nothing non-native about that. Copy-pasting their code into std would make them more native. It's not C++ there if something is not in STL, it pretty much a huge pain in the ass to get. Those crates are just one line away. No sane person would argue that Rust doesn't support regular expressions because those live in a separate crate.

          Comment


          • #45
            Originally posted by uid313 View Post
            But in some languages (such as Kotlin) you cannot pass a variable of a nullable datatype as argument to a function that accepts a non-nullable datatype.
            I don't know if there is any difference.
            It depends, I guess. I don't know any Kotlin, so I can't tell,especially how the conversion between nullable and non-nullable happens. Maybe it is sane, maybe not.

            Comment


            • #46
              Originally posted by uid313 View Post

              Oh, I wasn't aware of these third-party crates. Rust still doesn't natively support that without use of third-party crates though.
              The thing about Rust is that just about everything is a third-party crate. The only stuff in the standard library is the absolute minimum needed. This keeps the standard library from bloating over time as the result of adding improved APIs.

              Originally posted by oleid View Post

              It depends, I guess. I don't know any Kotlin, so I can't tell,especially how the conversion between nullable and non-nullable happens. Maybe it is sane, maybe not.
              There are three types of nullability in Kotlin:

              1. Non-nullable
              2. Platform-nullable
              3. Nullable

              And the compiler knows with absolute certainty which type any variable is.

              1. Non-nullable may be coerced to both platform-nullable and nullable.
              2. Platform-nullable may be coerced to non-nullable, but will incur a runtime check to verify that it is not null.
              3. Platform-nullable may be coerced to nullable.
              4. Nullable may never be coerced to non-nullable.
              5. Nullable may be coerced to platform-nullable.

              Platform-nullable is not talked about a lot. And it is not possible to explicitly declare a type as being platform-nullable. This type is only used for interfacing with the Java API, which almost never returns null values, but theoretically can. As such, the Kotlin compiler allows developers to assume that a value returned from Java is not null. The compiler will still insert the aforementioned runtime check, which will throw an exception upon failure.

              Comment


              • #47
                Originally posted by wswartzendruber View Post
                The compiler will still insert the aforementioned runtime check, which will throw an exception upon failure.
                Thanks for the explanation! These automatically inserted checks sound a lot like rust's unwrap() on options and results. It is a good thing, that those 'pointers' are checked automatically,
                but I imagine it could be difficult to keep track of where exceptions are thrown, at least after the 1st bigger refactoring.

                Comment


                • #48
                  Originally posted by wswartzendruber View Post
                  There are three types of nullability in Kotlin:

                  1. Non-nullable
                  2. Platform-nullable
                  3. Nullable

                  And the compiler knows with absolute certainty which type any variable is.

                  1. Non-nullable may be coerced to both platform-nullable and nullable.
                  2. Platform-nullable may be coerced to non-nullable, but will incur a runtime check to verify that it is not null.
                  3. Platform-nullable may be coerced to nullable.
                  4. Nullable may never be coerced to non-nullable.
                  5. Nullable may be coerced to platform-nullable.

                  Platform-nullable is not talked about a lot. And it is not possible to explicitly declare a type as being platform-nullable. This type is only used for interfacing with the Java API, which almost never returns null values, but theoretically can. As such, the Kotlin compiler allows developers to assume that a value returned from Java is not null. The compiler will still insert the aforementioned runtime check, which will throw an exception upon failure.
                  So is Rust and Kotlin equally safe in regards to nullability?
                  Is the Kotlin way easier than the Rust way?

                  Comment


                  • #49
                    Originally posted by oleid View Post
                    Thanks for the explanation! These automatically inserted checks sound a lot like rust's unwrap() on options and results. It is a good thing, that those 'pointers' are checked automatically,
                    but I imagine it could be difficult to keep track of where exceptions are thrown, at least after the 1st bigger refactoring.
                    It's somewhat difficult to get platform-nullable types out of the function they originate in. You can do it if you don't declare a function's return type and let the compiler infer it. As far as I know, it is impossible to pass a platform-nullable type into a Kotlin function, or to put one into a collection of any kind. In these cases, the compiler will automatically null-check it and then convert it to non-nullable.

                    So your NullPointerException is almost always going to be thrown in the block that sets the platform-nullable value in the first place.

                    Originally posted by uid313 View Post
                    So is Rust and Kotlin equally safe in regards to nullability?
                    Is the Kotlin way easier than the Rust way?
                    Rust is a little more strict with nullability. Something is either wrapped inside an Option<T> construct or it is not. There's no real equavalent in Rust to Kotlin's platform-nullability. Kotlin's approach is easier, but incurs some runtime overhead with platform-nullability due to runtime checks.

                    Comment

                    Working...
                    X