"The Rust ecosystem is indeed rich in ML crates - just take a look at what a quick search for machine learning on crates.io returns. No need to go and rewrite everything from scratch: I picture linfa as a meta-package, a collection of curated algorithm implementations from the Rust ecosystem. The first stop for your ML needs, as scikit-learn for Python."

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.

Right now, NVidia is designing their GPGPUs to run C++ code.

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.

If the GPUs can run C++ code, it is likely that they'll be able to run Rust code as well. If there is an LLVM target for it, Rust usually runs on it.

Watch the second talk, it is all about making CUDA memory model work like ISO C++ memory model, a 10 year long project.

Rust has yet to define a memory model.

Sorry, I tried searching for what you mean by "ISO C++ memory model", I can't find authoritative usage of that term. I find a bunch of references to fences and std::atomic, both ideas of which Rust has supported from the start.

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?

Here are some references about the C++ memory model, introduced in C++11:

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.

>If you bothered to follow the YouTube videos you would found the CUDA projects I mentioned.

Dude, you linked to two hours worth of video. Give people a break.

I don't give a break to people that are too lazy and then issue statements like "I also can't find any details on the CUDA project you mention".

Just clicking on the links would show the info.

> What advantages would a more complex memory model yield?

consistency

Just because it might be possible doesn't mean that it's worthwhile at all.

> Rust doesn't have to replace anything. It can be used to create complementary packages especially ones that use C/C++.

I'm not sure that I understand correctly - are you suggesting that people use Rust as an additional layer between Python and C++?

The original article is proposing that the existing C and C++ libraries be rewritten in Rust for performance reasons (while continuing to use Python to access the functionality).

I guess you meant memory-safety reasons because Rust is attempting to be as fast as C and C++, not the other way around.

Depends on the domain.

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.

Concurrency patterns that are difficult to execute in the decades old codebase of Firefox, which also happens to be a browser aka nightmare of complexity.

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.

I've heard this suggestion fairly frequently - that people use Rust as a wrapper over C++ bindings to add in safety to the C++ underneath.

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.

For that use case it is more productive to actually use static analysis tooling for C++.

"people use Rust as a wrapper over C++ bindings to add in safety to the C++ underneath."

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.

What’s wrong with being compiled?

In python I can write code one line at a time and they are executed immediately. This means that I can write code to print the data if I want, or try different things etc without ever rerunning the program from scratch which can be very slow for training data.

Here, have a go at it with C++.

https://blog.jupyter.org/interactive-workflows-for-c-with-ju...

Being compiled doesn't mean anything, it is a matter of tooling.

Have fun :):

https://github.com/google/evcxr/blob/master/evcxr_jupyter/sa...

pretty cool. i wonder how well it works though

I use the evcxr repl all the time. It has some rough edges but it's incredible to finally have a rust repl that's functional. I had been using rusti on an ancient rustc. One thing I really like is that you can add a crate with one line (`:dep rand = "0.7"`).