Why Rust fails hard at scientific computing

&gt; Consequences ? You can’t use Rust arrays to represent a matrix bigger than 4×8, how useful is that?<p>I went and Google&#x27;d &quot;rust linear algebra library&quot; and immediately found <a href="https:&#x2F;&#x2F;nalgebra.org" rel="nofollow">https:&#x2F;&#x2F;nalgebra.org</a> which can represent such matrices just fine, and even integrates with LAPACK. Did the author do this most cursory of research before springing to write their rant? This is like saying &quot;Python fails hard at scientific computing&quot; because the default list type isn&#x27;t an efficient basis for representing matrices, while entirely ignoring NumPy.<p>Also, those are <i>memory slices</i>, not arrays: they aren&#x27;t pointers to heap-allocated data. So [[f32; 9]; 5] corresponds to a contiguous block of memory representing a 5x9 matrix of 32-bit floats. It has the same memory structure as [f32; 45], but you can index it as eg. my_matrix[3][2] to access the element in the 2nd column of the 3rd row. Again, I guess it&#x27;s much easier to bash something than try to understand it.

What happened to the readability of code? This looks dreadful. I am sure there is a way to come up with a better syntax without sacrificing the type safety aspects.<p><pre><code> fn main() { let my_str: Rc&lt;RefCell&lt;Box&lt;MyStruct1&gt;&gt;&gt; = Rc::new(RefCell::new(Box::new(MyStruct1))); my_trait_fn(Rc::new(RefCell::new(Box::new((**my_str.borrow()).clone())))); my_str.borrow().my_fn(); } </code></pre> I come from a Python&#x2F;Java world and I remember when I first delved into embedded MCU programming in C&#x2F;C++, it was a cognitive overload and a half. I think we need to take a step back and while I understand the differences between high level languages (Java&#x2F;Python) and C&#x2F;C++ having the burden to allow for low-level programming; readability aspects of code often gets the lowest attention.<p>If we, humans, spend so much time writing&#x2F;parsing code through our vision system, programming languages need to take this aspect seriously and optimize the syntax over readability than expressivity.<p>I recall Kernighan&#x27;s &quot;The Elements of Programming Style&quot; where he talks about making the code more understandable than &quot;clever&quot;. The syntax of a programming language directly facilitates (or impedes) this idea.<p>Edit - Everyone seems to keep pointing out it is a contrived example. Yes, I agree but the syntax has nothing to do with making the contrived example even more difficult to read?

I wish the HN community would collectively decide to downvote posts like these, which reward people who use clickbaity titles to get attention at the cost of hiding more careful analyses.<p>The post can be summarized as a critique of a programming language that did not meet the author&#x27;s desires, but sections of the critique is (1) dislike of the syntax, (2) a specific missing feature, and (3) a very specific feature which doesn&#x27;t exist in any of the popular scientific computing languages. It&#x27;s fine to talk about not liking a tool, but it doesn&#x27;t merit &quot;fails hard&quot;.

Aside from all the discussion around these low-level complaints, the Rust community is well aware of the lack of higher-level scientific computing libraries, which IMO is the more relevant reason not to use Rust today: <a href="http:&#x2F;&#x2F;www.arewelearningyet.com&#x2F;scientific-computing&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.arewelearningyet.com&#x2F;scientific-computing&#x2F;</a><p>Hell, Rust doesn&#x27;t even have stable bindings around BLAS&#x2F;LAPACK&#x2F;LINPACK and friends which are the lifeblood of <i>every</i> language capable of scientific computing.<p>Give it time. Scientific computing was never the primary thrust for Rust, and other more pertinent domains have yet to reach complete maturity.[0]<p>[0]: <a href="http:&#x2F;&#x2F;www.arewewebyet.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.arewewebyet.org&#x2F;</a>

Lack of multidimensional arrays as a language primitive is a problem. It was a problem in C, C++, and Go, too. There, you either have arrays of arrays, or some macro&#x2F;template that does a multiply on the subscript. The reply in one of the Rust forums is that multidimensional arrays are only found in &quot;domain-specific languages&quot;, like FORTRAN.<p>When someone brings this up the usual excuses are trotted out:<p>- &quot;It can be done with templates&quot;.<p>- &quot;You can have an array of arrays&quot;.<p>Then there&#x27;s bikeshedding. Some people want to be able to extract an arbitrary subarray slice from an N-dimensional array and treat that like a regular array. This is possible but complicated, and if implemented slows down the simple operations. Then there are people who want N-dimensional arrays where N is determined at run time. (This now includes the machine learning people.) Endless arguments between these groups resulted in nothing being done in Go. I haven&#x27;t followed that discussion for Rust.<p>The big advantage of doing this in the language is that there&#x27;s a lot of hardware support for doing number-crunching fast on dense arrays, and you want the compiler to be using it effectively. Matrix multiply on arrays of arrays is much slower than on a dense array where the compiler knows the spacing between the rows at compile time.<p>At least have arrays as good as FORTRAN. This is why some heavy number-crunching work is still done in FORTRAN.

I am going through the rust by example thing every weekend and also trying to write some Rust code on my own and I found the &#x27;too much symbols&#x27;&#x2F;unreadable code and just the general complexity of the language very off putting.<p>If I have to write low level code, I might just stick with C or C++ - the devils I know rather than trying to tame a new incarnation of the devil that is Rust. The complexity and learning curve costs of Rust far outweigh the benefits at this point.<p>Edit: If I sounded like I am giving up on Rust above, that&#x27;s not yet the case. I am currently enjoying challenging myself to learn something complex and to that effect, Rust is holding my interest.

&gt; then your matrix is allocated on the heap not the stack, meaning slower operations<p>This doesn&#x27;t seem right at all... Does anyone know more? Maybe they meant slow to allocate &#x2F; deallocate? The author&#x27;s problem appears to require you to generate a lot of temporary data and then throw it away. They might benefit from just writing their own pool allocator, so they don&#x27;t have to wait for heap allocates (assuming that&#x27;s their problem).

Extensive discussion on &#x2F;r&#x2F;rust: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;76olo3&#x2F;why_rust_fails_hard_at_scientific_computing&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;76olo3&#x2F;why_rust_fails...</a>

Re: (2), this RFC was merged: <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rfcs&#x2F;pull&#x2F;2133" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rfcs&#x2F;pull&#x2F;2133</a>

I don&#x27;t know if Nim would be my first choice for a future scientific computing language. I think I&#x27;d be more focused on Julia or, recently, Crystal.<p>Julia has some extreme magic that it can do to make your life easy. Crystal will attract the Ruby-like crowd of people who will create very neat and effective libraries.

I suspect Rust also fails hard at interactive code (UIs).<p>Why? Because Rust&#x27;s memory management doesn&#x27;t work well with cyclic structures, and closures are such structures. Closures have shown to be very useful for interactive code (see Javascript).<p>Someone please prove me wrong. (I&#x27;m wondering how Firefox deals with this).

&gt; You might say, 30 lines, easy no? Well except that Go can be played on 9x9, 11x11, 13x13, 15x15 and 17x17 too, any oddxodd size, no way I&#x27;m implementing those 30 lines x 6 times, this is not fun<p>I&#x27;m curious if the author has tried using macros, which would require him writing the code only once.

Scientific Computing doesn&#x27;t really happen in low level language spaces today. FORTRAN, C and C++ are what powers the Higher Level languages.<p>Most is done in R, Matlab, Python, and Julia and for good reason. Most people doing scientific computing are not coders that can do the work at a higher level at a productive level.

for one point, an efficient programm probably wouldn&#x27;t need to pack memory intensive arrays on the stack all at once.

&gt; <i>I’m not even talking about Rc, RefCell and Box which seems like security through obscurity.</i><p>What do you mean?