rust VS leaf

You can use Tensorflow for Rust to simplify that task and avoid pain with regex. Just have the right mindset.

What is the benefit of this compared to using bindings/a wrapper to Tensorflow, or other ML libraries written in C/C++, such as this community hosted project on tensorflow's github. If it's just for fun that is a valid enough reason imo, just curious since you describe it as a better Tensorflow because of the typing vs using the python wrapper, when there already exist ways to interact with tensorflow with both Rust and other statically typed languages, also including C++ (officially supported), C#, Haskell and Scala, as well as probably having bindings not mentioned on the documentation for more niche languages.

(3) You could use TensorFlow as your executor: https://github.com/tensorflow/rust

TensorFlow has language support for TypeScript well as Rust.

Thank you for the restponse! With tensorflow I am probably better of with something like; [tensorflow rust bindings](https://github.com/tensorflow/rust/tree/master/src). But I believe some useful extensions are still written in python for example; [TFDV](https://github.com/tensorflow/data-validation).. and how about scikit-learn or even something that is simpler like fb-prophet that is entirely written in python?

Tensorflow bindings exist, technically, but they're in a pretty rough state AFAIK.

tensorflow/rust (Rust): Rust language bindings for TensorFlow

I used a lot of the dependencies behind the leaf framework which was abandoned by its authors a while back due to funding issues, as I implemented it in Rust and most bindings were maintained while the leaf framework itself wasn't anymore.

I tried to create a ML framework[0] that would work on both CUDA and OpenCL (and natively on the CPU) around 2015/2016, which included creating FFI wrappers for both CUDA and OpenCL. This is where my experience on the subject (and my contempt for NVIDIA) comes from.

Me memory isn't perfect, but IIRC the situation was roughly the following: We were quite short on resources (both devtime and money), which meant that we had to choose our scope wisely. Optimally we would have implemented both CUDA and OpenCL 2.0, but we had to settle for OpenCL 1.2 (which offered reduced performance, but was "good enough" for inference). IIRC OpenCL 2.0 was very very similar in what capabilities it assumed and offered to the CUDA version at the time, and cards like the GTX Titan X had "compute capabilities" that supported features like shared virtual memory between CPU and GPU in CUDA at the time. In fact the advances around memory management (and async copying) that were present in CUDA and not in OpenCL 1.x were the main source for the performance differences between the two.

From everything that I can tell at that point in time, if NVIDIA would have wanted to support OpenCL 2.0 they could have done so based on technical requirements. What the reason for not doing so is, is just pure speculation (lack of internal resources due to focusing on devtools?), but to me it always looked like they were using the edge they got via their proprietary libraries like cuDNN to get a foot into the field of ML and then purposefully neglected OpenCL to prevent any competitors from catching up. Classic Embrace, Extend, Extinguish.

[0]: https://github.com/autumnai/leaf