I've been using Rust for finite element method research, and I've been pretty happy with the results, the code is faster than my previous effort in Julia. That

I've been using Rust for finite element method research, and I've been pretty happy with the results, the code is faster than my previous effort in Julia. That may be somewhat of a second system effect, though. I had trouble with detecting in Julia what the effect of the garbage collector was, I don't know if that's improved or not. The code in Rust has no shared/gc usage at all, so I'm pretty sure what the effect of garbage collection is :) One thing I like about Rust is that it makes doing allocation-free performance-critical calculations somewhat easier and safer. This is because I can preallocate my data before critical loops, inside the constructors of implementation objects, then hand out borrowed, non-mutable pointers to this data to clients from these objects. That way the clients don't have to pass in buffers to use, which is none of their business -- it would break encapsulation for them to even know what kind and how large of buffers to pass. The clients cannot detect that they are actually receiving a pre-allocated, shared buffer. In other languages that would ordinarily be very dangerous without extra effort, because if they or some other code turned around and called routines that used that same pre-allocated buffer again, then the data would be silently written over, in an "action at a distance" way which would be a nightmare to maintain. But Rust "freezes" the contents behind the immutable borrow, making sure that it can't be borrowed mutably again and thus cannot be changed, while the immutable borrow is in use, from anywhere in the program, all resolved at compile time. This allows getting very aggressive with the pre-allocation strategy.