Why Rust fails hard at scientific computing | Hacker News Reader

Why Rust fails hard at scientific computing

andre-ratsimbazafy.com

86 pointsalex_hirner85 comments

> Consequences ? You can’t use Rust arrays to represent a matrix bigger than 4×8, how useful is that?

I went and Google'd "rust linear algebra library" and immediately found https://nalgebra.org 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 "Python fails hard at scientific computing" because the default list type isn't an efficient basis for representing matrices, while entirely ignoring NumPy.

Also, those are memory slices, not arrays: they aren'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's much easier to bash something than try to understand it.

>I went and Google'd "rust linear algebra library" and immediately found https://nalgebra.org 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 "Python fails hard at scientific computing" because the default list type isn't an efficient basis for representing matrices, while entirely ignoring NumPy.

The author didn't want to use/leverage/whatever some ready made package. He wanted to write his own.

Python does suck for scientific computing at that level as well -- Numpy and Scipy are huge wrappers for C/Fortran etc code.

If the author wanted to write his own, he could very easily write an nd-array-alike wrapping a really long double[] in Rust, right?

From the author: You can work around it by using a Vec (arbitrary sized sequence/list) but then your matrix is allocated on the heap not the stack, meaning slower operations. Plus that means you cannot use Rust wonderful type system to check that you multiply matrices with compatible dimensions, say a 2×2 matrix with a 2×1 matrix, without jumping through hoops.

So he thought of that, then decided not to go that way, even though that's how it's done in C/Fortran underneath every single linear algebra library in the world, and his conclusion is that rust sucks?

I'm finding it a little hard to believe that there are real-world linear algebra problems where allocation is the bottleneck and doing it all on the stack is the answer.

If you have to do X in the new language in the same way as in Fortran, the new language is not better for doing X than Fortran, is it ?

Sure it is. Both in larger program design and in affording several different ways to accomplish the subscripting into the giant nd-array Vec<f64>. Maybe Rust should also provide language support for the ndarray type, but lack of such isn't a barrier to being as-good/better than existing langauges.

If you're doing linear algebra on big matrices, putting them on the stack is most likely madness. It sounds like the author is interested in Rust for the 'expressive' type system enforcing logical invariants about his matrices, which isn't why Rust built their expressive type system.

The authors of nalgebra seem to have succeeded where the author failed, then. Perhaps because they took the time to understand what slices are.

The author didn't say it was impossible altogether -- just that he would want actual malleable first-class multi-dimensional array types.

So... nested slices? Unless you have some special meaning attached to "malleable".

Good point.

I guess this also holds for graph-problems, where graphs are possibly cyclic structures (difficult memory management), and/or stored as adjacency matrices.

PS: Is there a set of benchmark problems that can be used to validate a language design?

I believe the author is lamenting the absence of RFC 2000 (const generics.) That is, users cannot define their own types which are generic over constant values.

Just because language X can wrap a LAPACK/BLAS library doesn't automatically make it fit for the purpose of implementing one.

Look at how the nalgebra represents an n-dimensional array of known dimensionality (through both the type system and in memory) and you will understand.

Once there is, say, a uBLAS equivalent in rust that is easy to use and understand the implementation of, I will consider it worthy.

The generic-array and typenum crates solve this at the type level. nalgebra uses typenum to encode dimensions at the type level, not in memory/at runtime (unless you opt-in with the `Dynamic` marker type). RFC 2000 will ease this, but it's not impossible to do at present.

It's a fair criticism though, don't you think that in order to use a fundamental aspect of a language (Arrays), one needs to download some external package? Why isn't this built into the core language?

See the second paragraph of my comment with regard to representing matrices efficiently with just slices. I would argue that Rust is actually better here than most languages, as its native multidimensional "arrays" (slices) are equivalent in memory usage and performance to single-dimensional ones.

More generally, the 1-32 issue should be solved when RFC 2000 is implemented [0]. In the meantime there's generic-array [1], built on top of typenum [2], which you could think of as a sort of polyfill.

[0] https://github.com/rust-lang/rfcs/blob/master/text/2000-cons...

[1] https://github.com/fizyk20/generic-array

[2] https://github.com/paholg/typenum

Thank you for clarifying.

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.

  fn main() {
      let my_str: Rc<RefCell<Box<MyStruct1>>> = 
  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();
  }

I come from a Python/Java world and I remember when I first delved into embedded MCU programming in C/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/Python) and C/C++ having the burden to allow for low-level programming; readability aspects of code often gets the lowest attention.

If we, humans, spend so much time writing/parsing code through our vision system, programming languages need to take this aspect seriously and optimize the syntax over readability than expressivity.

I recall Kernighan's "The Elements of Programming Style" where he talks about making the code more understandable than "clever". The syntax of a programming language directly facilitates (or impedes) this idea.

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?

In my opinion that's a contrived example. Why specify the type signature explicitly in the `let` line, instead of allowing the compiler to infer it? Why put a struct inside a `Box` (a heap-allocated pointer) and then the `Box` inside an `Rc` (a reference counted heap-allocated pointer)? Why go through the trouble of extracting the contents of this nesting doll of heap-allocated types, only to rewrap it back up in the same type structure before passing it to `my_trait_fn`? Why does `my_trait_fn` need to take ownership of an `Rc`? And if it really, really needs to, why not just use `clone`? Then you'd actually be taking advantage of the, uh, reference counting.

This code is just... wrong. On multiple levels. It's probably not doing what its author thinks it does. It also contains significant duplication where its entirely unnecessary.

Suffice it to say that you should probably not judge languages based on examples written by people who don't understand the language.

If you have to grok the language to write concise code, you kind of prove the parent’s point isn’t it? That is, it’s easy for newcomers to write code that seems to be unreadable.

This sounds like more of a learning curve thing than a code readability thing, IMO. Someone who doesn't know what they're doing can write unreadable code in virtually any language; the difference here is that Rust just takes more time to learn than something like Python or Ruby. While this is certainly something that can be improved (and lots of work is being done on this front!), I think the syntax itself is a bit of a strawman here.

Much Python, especially written by newcomers, has very poor readability. I can't read most C++ at all, personally. It's easy to write unreadable code in most languages - especially when you're unfamiliar with the concepts and abstractions that language utilises.

I am not sure as I haven't seen the entire codebase, but it is hard to understand why anyone would write rust like that.

Heavy use of a construction like Rc<RefCell<Box<_>>> is often a sign that someone is trying to replicate something like c++'s std::shared_ptr<_> in rust rather than write code in a manner idiomatic to rust. Also, given that the article's second point results from a confusion between a memory slice and an array, it is difficult to see this as an informed discussion of rust.

IME it's the typical code after a few hours of "fighting the borrow checker" if you didn't plan your data layout very carefully with the borrow checker restrictions in mind.

That is, it's a lack of experience and understanding. The same way, you can see a lot of casts and `instanceof` use in code of those who don't understand types / classes yet, or a lot of global variables in code of those who don't understand functions / procedures yet.

If something in a language feels badly wrong, it's often a good idea to ask experienced people, or even the language's authors.

It's more complex than it needs to be; there's no reason to put a Box there, for example. (Even though the blog post is from April, it links to a SO question from 2015, where that Box was necessary, but as of Rust 1.4, a few months later, it is not. This info is in the comments of that answer.)

It's also very unclear why they created an entire second Rc rather than just cloning the first one, as that's the point of Rc.

Compare:

  fn my_trait_fn(t: &MyTrait) {
      t.trait_func();
  }
   
  fn main() {
      let my_str = Rc::new(RefCell::new(MyStruct1));
      my_trait_fn(&*my_str.borrow());
      my_str.borrow().my_fn();
  }

  let my_str = Rc::new(RefCell::new(Box::new(MyStruct1)));

Yep, even Rust has better syntax ;). The call is a little more gnarly. Keeping in mind that I don't really know rust, my understanding is that this is roughly the equivalent of trying to cast, in C++, shared_ptr<scoped_ptr<MyStruct1>> to shared_ptr<scoped_ptr<MyTrait>>. It's doable, but why the heck would you do it? The C++ equivalent might be:

  auto my_str = shared_ptr<unique_ptr<MyStruct1>>(new unique_ptr<MyStruct1>(new MyStruct1));
  my_trait_fn(shared_ptr<unique_ptr<MyTrait>>(new unique_ptr<MyTrait>(new MyStruct1(**my_str))));

Which isn't much prettier. Why not instead:

  fn my_trait_fn_2(t: Rc<RefCell<MyTrait>>) {
      t.borrow_mut().trait_func();
  }
  fn main() {
      let my_str2 = Rc::new(RefCell::new(MyStruct1));
      my_trait_fn_2(my_str2.clone());
      my_str2.borrow().my_fn();
  }

EDIT: Added a C++ example which actually compiles. EDIT x2: Fixed a double free.

I admit, I don't know much about Rust. However, I know C/C++ a bit and this drives me nuts:

  int* foo; // This is a pointer. Understood.
  int *foo; // How is this allowed!???? Confusing!
  *foo = bar; // Now you're deferencing. WTF!

In the second line, int foo confuses the hell out of me when I am scanning through pages of code. All of this mess could be solved by doing the pointer symbol after the variable name:
int foo*; // This is a pointer

Because the * belongs to the variable, not the type.
It's more clear with this example, which declares two variables at the same time:
int *foo, bar;
This declares foo as a pointer to int, and bar as an int. The following, written in the style you suggest, do the same thing but can be confusing, since a casual reader might think that this declares both foo and bar to be pointers to int:
int* foo, bar;
Someone else commented that C's declarations are designed to look the same as how they are used. This is true, and explains why arrays are declared the way they are, where the brackets come after the variable name: int foo[10]

The philosophy in C/C++ is "you declare it how you use it". You declare it with `foo`, you use (assign to) it as `foo`.
Likewise for arrays. You declare it `int foo[]` and you use it like `foo[i]`.

While its subjective, I really think ruby get this part right. When I look at ruby code I don't feel like my eyes hurt, I feel like the code is easy to skim, easy to find what I'm looking for, and there's the right balance between harsh symbols and softer alphanumerics. White space and indenting is also typically good on (good) ruby code. That's part of what I'm trying to keep alive in crystal.

I agree on the Ruby syntax part but every single Ruby method can be monkey-patched to oblivion, and many gems do just that. What you see is very often NOT what you get with Ruby.
I have looked quickly at Crystal and I liked it, really did. But it's too late for me now, I am in love with Elixir and already using it professionally, quite successfully too. Now that's a language with 90% WTF-free syntax (admittedly some of the pattern matching idioms and a few constructs can be confusing at times; very interested to see the builtin code formatter coming in version 1.6 though).

I am sure there is a way to come up with a better syntax without sacrificing the type safety aspects
Well, this is the generic curly-braces-and-semicolons style. If you want to see nice clean yet type-safe syntax, just take a look at OCaml or Haskell.

What is meant by "type-safe syntax"? A syntax that permits type annotations? I will say I find Haskell and especially OCaml hard to read; I'm writing a pretty minimal language with a Haskell-esque syntax, but that's because it's easy to build a parser, not because I find it more readable. And the syntax will likely change when readability becomes more important than prototyping.

I think the intent was “a language with nice clean syntax that is nonetheless type-safe”.
A large portion of readability comes from familiarity. I find most Haskell code fairly easy to read—or at least, approximately as simple or complex syntactically as it is semantically. Other mainstream languages tend to be either much more complex syntactically than what they do semantically (“verbose”) or much simpler (“magic”).

That makes sense, and I agree with your assessment of readability.

Wow, I just learned about Haskell syntax. I don't know the language but reading this makes me want to learn it: https://prajitr.github.io/quick-haskell-syntax/
Beautiful. Absolutely beautiful.

The syntactic differences between this Rust example and Java are pretty minimal. Types come after identifiers in Rust instead of before them, as in Java, and the namespace delimiter is `::` instead of `.`. The bits that are likely to hurt understanding pertain to memory management (borrowing, cloning, dereferencing, boxing, ref-counting, etc).
Besides conflating memory-management with syntax, this could also be made more readable by writing idiomatic Rust: use type inference in your `let` statement, fix your indentation on the last line, etc.

While certainly not the most readable example I'd like to know how much you've used rust? If you don't know the syntax of a language it often looks dreadful.

Yea, I admit, I haven't used Rust much except for following the MCU programming guide: https://japaric.github.io/copper/
Don't you think regardless of familiarity, Rust doesn't quite have a beautiful syntax? I am following this guide and it's like the visual equivalent of nails on a chalkboard. Perhaps it's subjective, what do you think?

That code is probably overly complicated for what it does.
I do agree though that Rust, like C++ tends to hide the logic in implementation detail (pointer ownership, memory management code etc sometimes outweighs the actual business logic)
Obviously these things aren't in Ruby or C# because it's implicit.
But this is what systems programming is: you tell a computer both what to do, and exactly how to do it.
I'd love for a systems programming language to look like Ruby or Haskell but I can't say I think it's possible.
I once imagined a language should have two tiers where you can write the bulk (slow) of your code in a simpler gc'd language and the core parts in a lower level subset of the language. Today I do that with C# calling C for example, but the boundary too wide. Just having the same build system and package manager for example would be fantastic.

There are a lot of operations per line in that code. I would expect anyone interested in maintainability in any language to not write code like this. I don't think this is representative of Rust.

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.
The post can be summarized as a critique of a programming language that did not meet the author'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't exist in any of the popular scientific computing languages. It's fine to talk about not liking a tool, but it doesn't merit "fails hard".

3) very much exists in julia

(3) Exists in Fortran, C# and F# [1]
Looking outside popular scientific computing languages, many Algol derived languages support it.
[1] .NET languages are used in scientific computing with packages like Alea GPU and IMSL.

Why do you say (3) does not exist? C++ has it (and it's one of the main reason why, at the moment, I wouldn't use Rust to do the things I do).

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: http://www.arewelearningyet.com/scientific-computing/
Hell, Rust doesn't even have stable bindings around BLAS/LAPACK/LINPACK and friends which are the lifeblood of every language capable of scientific computing.
Give it time. Scientific computing was never the primary thrust for Rust, and other more pertinent domains have yet to reach complete maturity.[0]
[0]: http://www.arewewebyet.org/

It's also totally fine for rust to be not as good for scientific computing. If you try to be everything for everyone you'll fail to be good at any one thing. It's hard to imagine rust will ever be competitive at scientific programming, say, with Julia. You might get say a 20% boost in number crunching performance at the expense of developer time.
Conversely, you'd be a damn fool to try and write Firefox in Julia.

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/template that does a multiply on the subscript. The reply in one of the Rust forums is that multidimensional arrays are only found in "domain-specific languages", like FORTRAN.
When someone brings this up the usual excuses are trotted out:
- "It can be done with templates".
- "You can have an array of arrays".
Then there'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't followed that discussion for Rust.
The big advantage of doing this in the language is that there'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.
At least have arrays as good as FORTRAN. This is why some heavy number-crunching work is still done in FORTRAN.

Lack of multidimensional arrays as a language primitive is a problem. [...] "It can be done with templates"
I am wondering what your point is. There are excellent and performant C++ template-based libraries for tensors (Eigen, Armadillo, etc.). In Rust I have used ndarray a bit for linear algebra and it is quite good [1].
If you have parametric polymorphism and operator overloading, whet is the problem of doing it in a library?
The big advantage of doing this in the language is that there's a lot of hardware support for doing number-crunching fast on dense arrays, and you want the compiler to be using it effectively.
Last time I checked Intel MKL (and wrappers like Armadillo) was still the fastest for doing number crunching of dense arrays on CPUs.
[1] The primary problem I ran into was that some common expressions were not backed by BLAS yet.

> At least have arrays as good as FORTRAN
Yes. This is one reason why I simply didn't care to convert research code I was using for my research from the decade(s) old Fortran into C or C++, when I was in academia.
I've been writing some machine learning products with Rust for a while now and I have to say I quickly abandoned using Rust for the computational components. The best way to use Rust is as it was meant to be: at the systems level, in this specific case for data and infrastructure code. Computation should be done using a language more suitable (e.g. Fortran) as one part of the pipeline. Rust is fantastic for writing pipelines that leverage other libraries for computation in this regard: the relatively strong static type system and easy error handling make it quite nice to work with.

Are there any more efficient ways to represent a dense multi-dimensional array than a one-dimensional array + index multiplication? Is there any difference between said multiplication done by some internal function inside the compiler, or by a regular (and trivial) function generated by a macro / template system?

Yes. And yes.
One dimensional array + index multiplication doesn't make it clear to the compiler that the rows are disjoint. So the compiler can't assume there's no aliasing. It also probably can't strength-reduce the multiply to an add when advancing through an array in the "wrong" direction. FORTRAN compilers have been doing subscripting optimizations like that since 1956.
After those optimizations, it may be possible to use some of the SSE instructions on x86.

The whole idea of aliasing comes with C and arbitrary pointer arithmetics. It's not a necessity. In languages without it (beyond Fortran, Rust comes to mind), the compiler may assume the lack of aliasing and optimize accordingly. I wonder what JVM's JIT would come up with (likely not with SSE, though).
I can agree that however you choose to represent a multi-dimensional array in RAM, giving the compiler some idea about them, or 2D matrices at least, could lead to some special optimizations.

I wonder how are FORTRAN arrays implemented. I was also assuming was a bing single arrays + indexes...
If I wanna add this to a language, what I need to consider to be as FORTRAN?

Look at the generated code for a matrix multiply in different languages. How tight is the inner loop?

I think an array of arrays in Rust would be allocated sequentially and packed, so you can efficiently index any particular item, right?

> Endless arguments between these groups resulted in nothing being done in Go
Do you have some links to these discussions?

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 'too much symbols'/unreadable code and just the general complexity of the language very off putting.
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.
Edit: If I sounded like I am giving up on Rust above, that's not yet the case. I am currently enjoying challenging myself to learn something complex and to that effect, Rust is holding my interest.

Did you try the book? Just curious.

I started there, 1st edition IIRC - went up to refs and borrowing and then thought maybe the by example approach is something I would like better - and I do find the example approach keeps my interest better.
Although I suppose I should go look at the 2nd ed draft when I need to look into more theory - reading the refs and borrowing section from 2nd ed right now :)

Ah yeah, the second edition is just straight-up better, and does contain examples. For example, ownership, references, and borrowing are theory-based in 1st edition, but are with String/&str in the second. That said, both are great resources. For some people, the book doesn't work for them but RBE does, and for others, RBE doesn't but the book does.

I went through the books, yet it was a big challenge porting an old Gtkmm toy application to Gtk-rs, because of lifetimes on callbacks.
Initially I was referring to the fields on the struct, but ended up passing them around as parameters.
You have a referrence to this kind of problem on the NLL proposal.
But unless I missed it, the books don't talk much about this.

The book does, but it basically says "Don't do that", whereas since you're binding to a library that does that, you don't have a ton of choices.
I haven't really used Gtk-rs enough to say more than that, really.

Basically the idea of having structs implementing widgets, which need to respond to UI events and handle their state, stored as struct fields.
On modern C++ you can easily use this approach with std::enable_shared_from_this.

> then your matrix is allocated on the heap not the stack, meaning slower operations
This doesn't seem right at all... Does anyone know more? Maybe they meant slow to allocate / deallocate? The author'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't have to wait for heap allocates (assuming that's their problem).

I imagine the following problems affecting performance outside of the alloc/dealloc themselves:
- Heap memory may not be reused as cleanly as stack memory, which means lower cache efficiency. Your suggestion of a pool allocator should take care of this.
- Runtime code for bounds checking needs to take the array size from the object even if it's constant. I recall there were XXX_unsafe() versions of accessors, which should not do any bounds checking, but the code is going to look ugly.
- Having to go through an indirection from the object to the memory buffer. Here you are at the optimizer's mercy.
So to avoid overly complex / ugly / brittle code where you need high performance, you are pretty much forced to write your own matrix types from the ground up, which is one of the concerns of the OP. I don't believe this is a terribly bad thing, and if the existing crates for this are not great yet, it would seem to me that it's just not been a focus for the Rust community, not an insurmountable problem.

Yeah, the only downside of heap storage is the alloc/dealloc cost -- once you have the memory, it's all just bytes in RAM, whether heap or stack.
It's not even a clear tradeoff for large arrays, because using value types on the stack implies lots of copies -- when you have a large block of data you want to refer to it by reference.
Also, stack size is finite and relatively small -- 2MB-ish default per thread on Linux, or is it 8MB? -- so placing large matrices there will work until it doesn't. Heap allocation has all of virtual memory at its disposal.

Extensive discussion on /r/rust: https://www.reddit.com/r/rust/comments/76olo3/why_rust_fails...

Re: (2), this RFC was merged: https://github.com/rust-lang/rfcs/pull/2133

Re: (3), this one: https://github.com/rust-lang/rfcs/pull/2000

To add a little context here:
> 2. Arrays in Rust are a second-class citizens, actually I think they don’t even have their visas. I hear them laughing at me when I try to use them. You can’t even clone them:
RFC 2133[1] adds Clone to Arrays (and Tuples), it has been merged and implemented[2].
> 3. Rust is still “discussing” integer as generic type parameter (since 2015), meaning a matrix type Matrix[M, N, float] will not exist before a long long time. The following github discussions are quite the read:
It links to a bunch of stuff, but fails to recognize that this also has a merged RFC [3] and implementation is actively worked on[2].
[1] https://github.com/rust-lang/rfcs/pull/2133
[2] https://github.com/rust-lang/rust/pull/43690
[3] https://github.com/rust-lang/rfcs/pull/2000
[4] https://github.com/rust-lang/rust/issues/44580

> fails to recognize
The article is dated April 1st, your links on const generics are from later.

Ah, sorry, I missed that.

And implemented: https://github.com/rust-lang/rust/pull/43690

I don't know if Nim would be my first choice for a future scientific computing language. I think I'd be more focused on Julia or, recently, Crystal.
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 disagree (but then again I am biased). I think Nim has a chance of attracting the Python-like crowd of people (plus Python has some very good scientific libraries like pandas) and I would be willing to bet that Nim's ability to perform magic surpasses that of Julia (or at least is equivalent).
Edit: Shameless plug. My book, Nim in Action, is 50% off today with code HalloweenPB50 (From Manning). Perfect opportunity to grab a copy and learn Nim :) https://book.picheta.me/

Does Nim have first class distributed computing primitives? For embarrassingly parallel operations, I can deploy on a slurm provisioned cluster on a supercomputer in about 5 lines of native Julia.
There's a lot of really nice "magic" in Julia. I implemented an experimental numerical system (a binary representation of real numbers) and after generating the +-x/ operations, I had complex numbers, Fourier transforms, and lu decomposition for free.
With the macro system I then wrote a library that let's me generate verilog code and built a hardware implementation of the number system and deployed comprehensive tests cross correlating the results of all operations across native Julia, hardware simulation in Julia,and verilog version transpiled through verilator.
I wanted to play around with Mary Wootters' discoveries about Reed Solomon encoding, so getting working Reed Solomon code over arbitrary galois fields was as simple as building the type rules and basic +-x/ and then again using matrix solving to solve erasures (in this case you can tell the type system there is no order to the type so it doesn't do partial pivoting). Then I needed to do some brute force searching of a large parameter space. The core program for this search is about 25 lines of code in the main loop, which reads like simple math statements out of a well written text, and the backing galois field and Reed Solomon libraries are about 100 and 50 lines, respectively.

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

Rust uses closures quite heavily.
The biggest problem with UIs is that they tend to be based on inheritance, which Rust doesn't have. It's not insurmountable; there are people who have written macros to make this kind of code more concise, or alternative UI libraries that don't rely on inheritance.

> Rust uses closures quite heavily.
I suppose they only support read-only free variables then?

Not exactly, no. There's a bit more ceremony since there isn't a GC, but that's a systems language for you.
Closures are basically syntax sugar for a struct that represents the environment, and a function pointer which takes that struct as one of its parameters. So you can do anything that you can do with that setup, aka, anything :)
https://doc.rust-lang.org/book/second-edition/ch13-01-closur...

Rust's borrow checker makes writing to captured variables okay and safe, e.g. this is a bit unconventional, but it works:
let mut sum = 0; (0..10).for_each(|i| sum += i); println!("{}", sum); // 45
Having cyclic values and/or mutation of shared values requires things like reference counting and cells, but this is what designed-for-UI languages like Swift are doing, just with more syntactic sugar (and, of course, the lack of it in Rust is still annoying for this sort of thing, but it isn't a fundamental blocker, and is less problematic than lack of inheritance, as steveklabnik says).

> 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'm implementing those 30 lines x 6 times, this is not fun
I'm curious if the author has tried using macros, which would require him writing the code only once.

Scientific Computing doesn't really happen in low level language spaces today. FORTRAN, C and C++ are what powers the Higher Level languages.
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't need to pack memory intensive arrays on the stack all at once.

> I’m not even talking about Rc, RefCell and Box which seems like security through obscurity.
What do you mean?

Reply on news.ycombinator.com