Rust doesn't have to replace anything. It can be used to create complementary packages especially ones that use C/C++. The point of introducing Rust into your ecosystem is for safety + performance which is hard to achieve without discipline.
Rust doesn't have to replace anything. It can be used to create complementary packages especially ones that use C/C++. The point of introducing Rust into your ecosystem is for safety + performance which is hard to achieve without discipline.
https://www.youtube.com/watch?v=86seb-iZCnI
https://www.youtube.com/watch?v=VogqOscJYvk
With Intel just releasing oneAPI (aka Data Parallel C++) last month, and Khronos pushing SYCL as alternative to CUDA C++.
It took 30 years for C++ to reach this stage, and in some domains (like embedded) it is still fighting for relevance.
That is something to keep in mind whenever to advocate Rust as replacement for Domain XYZ.
Rust has yet to define a memory model.
I also can't find any details on the CUDA project you mention, it seems counter-intuitive to me. At least with graphics data, it's mostly just large buffers of structs, defined with vertex attrib pointers or whatever. What advantages would a more complex memory model yield?
https://arxiv.org/pdf/1803.04432.pdf
https://people.mpi-sws.org/~viktor/slides/2016-01-debug.pdf
A language memory model is a mathematical specification on how the language semantics map to actual CPUs and the basis how to write lock-free algorithms.
If you bothered to follow the YouTube videos you would found the CUDA projects I mentioned.
Rust currently doesn't have such mathematical model.
Dude, you linked to two hours worth of video. Give people a break.
Just clicking on the links would show the info.
consistency
I'm not sure that I understand correctly - are you suggesting that people use Rust as an additional layer between Python and C++?
Mostly regarding using BLAS etc in Rust rather than C++. It seems a little pointless as the unsafe nature is within the underlying code, so it only santises input/output.
Adding a thin wrapper over an insecure library won't magically make it secure. That's why pure Rust or pure Swift versions of various algorithms and functionalities are worth so much - guaranteed memory-usage correctness.
For single threaded applications, as fast is the goal. There is potential for it to be faster due to stronger restrictions around pointers.
Multithreaded code is slated to be faster mainly because rust provides safety for patterns that would be difficult to do right in C++ (see servo css handling).
That is to say, you could do the same thing in C++, but getting it right is harder to do.
The same environmental conditions don't apply to other software and it's perfectly possible to write blazing fast multithreaded software in C++. In fact that's SOP.