An important one is missing from this overview: using a const. This is sometimes useful, because it does not require the type to be Copy; only that the value is a constant:
SEEKING SPONSOR: I work on the Rust standard library and compiler. As of a few months ago, I'm part of the Rust library team, which is the team that manages everything in and around the standard library. I'm currently working on the panicking infrastructure, improving the synchronization/locking primitives*, and on a new (more efficient) implementation of how formatting arguments are represented**. I also spend a lot of time reviewing incoming pull requests for the standard library, and am working on streamlining the organization around all this.
*: Much of which has already landed: On Windows, mutexes etc. are no longer heap-allocated. And on many platforms, thread parking now directly uses futex(-like) syscalls/APIs.
**: That is, how a format_args!() is represented at runtime, which is relevant for all println!(), format!(), etc. macros that do any formatting.
`T: 'a` means that you may keep values of type T around for lifetime 'a, but not that they will. So `T: 'static` means that you may keep values of that type around forever, as they do not refer to anything that doesn't live forever.
So neither `&'a i32` nor `MutexGuard<'a, i32>` are 'static (unless 'a is), because you shouldn't keep references like that around longer than the stuff it points to. But i32 by itself satisfies i32: 'static, because it's perfectly fine to keep an i32 around forever. (But that doesn't mean that every i32 will stick around forever.)
At work, we make high performant drone control systems in Rust. But for testing and debugging, we simply use Matplotlib (a Python library) to make plots of simulations, etc. So we prefer Rust for the control systems themselves for the speed and reliability, but for plotting results of simulations, we don't care much about performance and rather just use something with all the features we need.
My grandpa used to make drone control systems with operation amplifiers (in the 1980s). I have a picture of him with a big plotter on a stand in a field flying a drone.
How does this interact with Rust memory safety? I am not familiar with the PyToObject trait, so I am guessing that this has some kind of safety wrapper?
In Python, all data (even simple integers) are all allocated on the heap. ToPyObject makes a deep copy of everything, converting everything to `PyObject` on the heap, so all data is owned.
The numpy crate helps if you need to convert large arrays to Python, as numpy does not store every element separately on the heap.
It uses the same Python interpreter, but each macro invocation is considered its own module. A later version of the crate will have the possibility to keep the context around to be re-used by a later invocation such that, for example, you don't need to import things again.
It doesn't translate Python to Rust or anything like that, it uses CPython both to compile to Python bytecode and to run it. It doesn't launch a separate interpreter, the interpreter is used as a library, so runs in the same process.
Yes! I'm founder of a start-up (about 10 employees now) that makes flight controllers for Drones, and all the software that runs on them is written in Rust.
We don't use STM chips though. Since the way we do state estimation and fault tolerant control requires a lot of computational power, we settled on 64-bit ARM Cortex A series processors. Since there was nothing available that fit our requirements, we produce the hardware ourselves as well.
When we started a bit more than two years ago, we started in C++, but have been slowly switching to Rust starting less than a year later. Now that everything is in Rust, our productivity went up a lot, together with the reliability of our systems (which is our main selling point).
The thing we miss most from C++ is the Eigen library, but the alternatives in Rust are pretty okay, though less complete. We are adding features and optimizations to some of these libraries, which we'll publish open source in a few months probably.
Me and the company I am at are on the fence with Rust because the type system still can't do Eigen but probably will eventually. I worry all of the current array libraries for Rust will go obsolete in a year or ten and Rust will only then start building up a convincing ecosystem for numerical computing.
Yes, this was our main worry as well. At first we switched to Rust only for the lower level code, the parts that interfaces with sensors and the motors, that do the data logging, our inter process communication library, etc. The part with the control algorithms (where all the interesting linear algebra code is) was still in C++ until recently.
For all the small vectors and matrices, things like Vector3 and Matrix3x3 from nalgebra work fine. A few generic things we had to change from statically sized to dynamically sized arrays/matrices, but since these were rather big already, the difference in performance was neglegible. The type safety was maintained by directly wrapping those in a generic struct where the template parameter describes the contents of the matrix or vector. Such template parameter is basically a struct where the members describe the meaning of all the columns/rows of the related vector/matrix. A custom derive proc macro generated the conversions to and from this type (which are all optimized away by the compiler). It looks something like this:
We were already doing something like this in C++, but with some hacky preprocessor macros instead of Rust's procedural macros.
In the end, keeping track of the meaning of the entire vector/matrix in the type system provides us with even a lot more safety than only keeping the size of them in the type system. And it has the advantage that you don't need const generics, since you're keeping track of whole types, and not just numbers. The downside is that we have to maintain a few procedural macro implementations.
Cool! I knew it was being worked on; I look it up every few months but keep forgetting the name. RFC 2000 const generics. Any talk yet of a standard ndarray type once that lands? C++ doesn't have one and numeric library compatibility really suffers. Python has one (the buffer interface basically blessed numpy arrays). At our shop python is our glue language mainly because you can pass data between libraries and expect it to work and work efficiently (without unnecessary copies).
We'll be changing our company name in a few weeks, followed by the launch of a new website which should have a lot more information than the current one.
