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

[oleid]

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,...

[uid313]

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.

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.

[flashmozzg]

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.

[oleid]

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.

[wswartzendruber]

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.

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.

[oleid]

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.

[uid313]

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?

[wswartzendruber]

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.

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.

[deusexmachina]

Does this mean AMD hardware will let us use the most rust-based drivers possible on any OS? I'd like to experience running an OS with as many rust-based drivers as possible to see if I can discern a reliability difference