I really appreciate the work and the effort that went into this. However, such an approach has previously not really worked for C++ with LLVM offload. Why would it work for Rust?
They're very different languages, with different semantics. Without reading more than the synopsis of the paper, they're 100% leveraging the substructural type system and will have a really tight requirement for you to use a certain kind of Rust code at the CPU/GPU boundary.
I think that will depend on the exact reason(s) C++ with LLVM offload didn't work out? If Rust differs from C++ in a way that addresses pain points/failure modes/etc. from the C++ attempt, for instance, then perhaps it isn't unreasonable to think Rust could succeed where C++ didn't (c.f., Mozilla's pre-Rust attempts to parallelize Firefox's CSS styling engine). Inversely, if Rust doesn't do things differently in the right way perhaps one might expect the effort to also not work out. Or maybe the problems are entirely non-technical and things could work out in either language.
... isn't Metal shading language just C++17 compiled with LLVM ? working on every Mac and iPhone in the world is not what I would call "not really worked". Likewise, SYCL works just fine.
> just C++17 compiled with LLVM
i invite you to attempt to compile/run absolutely any C++17 codebase on your iphone's GPU lol!
If they really wanted a vendor neutral solution for Rust GPU, that already exists: you write the CPU side code, including buffering, allocation, concurrency, etc through Vulkan binding and consume the compute kernel in SPIR-V from HLSL/GLSL/WGSL etc. As it stands, the way they use Rust here feels more like using it like TypeScript types/interfaces than anything else.
Again, the size of most operations that should be done on the GPU is known ahead of time before compilation, so it's very much possible to statically allocate memory at compile time instead of going through all this trouble to write what's essentially a Rust shaped DSL for GPU compute.
Maybe it doesn't matter in a post AI world but perhaps it will allow better abstractions.
No need to yuck someone else's yum.
But yeah, I think Python's dominance in science/ML will eventually pass, just as FORTRAN and Matlab did before.
https://rustc-dev-guide.rust-lang.org/offload/internals.html https://github.com/rust-lang/rust/issues/131513
also, seems like this is mostly targeted towards HPC audience?
Why is it a blocking issue?
I feel like this is very aligned with the goals of rust-gpu.
Edit: Oh, async/await was a bigger and more recent one, 2019. I've heard that this wasn't an easy decision for them but was kinda needed.
It’s not javascript where you need to support all possible browsers.
Even with a style guide in C++... Google is known for having one. I was forced to change how I use basic strings multiple times there. They also changed the rules around refs (&).
This might be an relevant read: https://smolmachines.com/engineering/gpu-over-vsock