At one point I was doing a PhD in programming a custom FEM program written in Java. I ended up not completing that program, but have been using FEM for many years to design things.

One of the ways I play around with programming languages is try to make a small Finite Element solver. I think so far I've made them in Matlab, Python, JavaScript, and Rust. Maybe I made one in C or C++ as well.

Whenever I do, I realize that a lot of the barrier is getting good Matrix solving tools in that language. Rust was a bit difficult because I was forced to choose between 1 or 2 main linear algebra codes. However, these codes are not optimized and will not be as fast as the Fortran based codes that a lot of the Python libraries now reference (LAPACK and BLAS if I rembember correctly).

It comes down to how you store the information in the Matrix. Physical problems solvable by FEM are symmetric and linearly independent, or some tricks are done to make them so. They also end up being quite Sparse. Those Sparse solvers from LAPACK and BLAS, as well as all of the past optimizations that are probably made for dealing with cache size (I'm speculating here, I really don't know), really make a huge difference in the problem.

Last I touched the Rust libraries to make a simple code, I just stuck with non-sparse solvers. There's an enormous difference between storage size and computational effort to go through a non-sparse matrix in comparison, especially when the problem is large. I think past a few million degrees of freedom on typical mechanical engineering problems, it started to become unmanageable on a local cpu.