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

  • wswartzendruber
    replied
    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.

    Leave a comment:


  • uid313
    replied
    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?

    Leave a comment:


  • oleid
    replied
    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.

    Leave a comment:


  • wswartzendruber
    replied
    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.

    Leave a comment:


  • oleid
    replied
    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.

    Leave a comment:


  • flashmozzg
    replied
    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.

    Leave a comment:


  • uid313
    replied
    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.

    Leave a comment:


  • oleid
    replied
    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,...

    Leave a comment:


  • tildearrow
    replied
    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...

    Leave a comment:


  • mmstick
    replied
    Originally posted by oleid View Post
    Relm is supposed to be a nicer wrapper for gtk+. It uses message passing to deliver events and thus can easily be used in highly multithreaded code.
    Actually, all operations on GTK have to happen on the main loop on the main thread. Relm just provides a very opinionated way of handling GTK. But you can just as easily write your own event-driven way of handling GTK with an event loop. I personally just use gtk-rs with an async channel + glib async loop so as to not have a middleman decide my architecture for me

    Code:
    let (tx, rx) = flume::unbounded();
    
    let mut app = App::new(tx);
    
    glib::MainContext::default().spawn_local(async move {
        while let Some(event) = rx.recv_async().await {
            match event {
                Event::DoThis(value) => app.do_this(valuie),
            }
        }
    });
    
    gtk::main();

    Leave a comment:

Working...
X