Node Crunch: a crate for distributed computing

Hi Rustaceans,

this is the first release of Node Crunch a crate for distributed computing that I've been working on for some time.
You simply have to implement two traits and are ready to go.
It uses a client / server architecture with heartbeat messages to ensure that one malfunctioning node can't halt the whole computation.
The example contains a distributed version of the mandelbrot set calculation and should be easy to follow.
It's still being worked on but if you are adventurous you can give it a try :wink:
Any feedback is welcome.

Crate: https://crates.io/crates/node_crunch
Github: https://github.com/willi-kappler/node_crunch

3 Likes

Since Fortran is my mother tongue, I was eager to see your example. Unfortunately, there was nothing there.

Yes I'm sorry, I have to add a Fortran example. I've already opened an issue on Github. Hope to find time for this soon.

I am definitely not sure if any Erlang-like computation model is ever possible in Rust runtime. Modern RISC hardware has no process isolation support to let any object (actor) or green process be possible to be implemented.

Any error such as divide by zero of GPF on bad memory addressing will drop the process as a whole, at the same time it is impossible to devide 100500 threads/actors as isolated processes.

Node Crunch is more about distributed computing than super stable systems, where Erlang shines. Having better CPU support for these kind of things would be a win, sure.
You may have heard of
https://github.com/archseer/enigma
So I don't understand why an "Erlang-like computation model" should not be possible in Rust.
But that's a bit off topic.

Why not? The big idea behind Erlang is message passing – which simply means serializing and deserializing messages without passing explicit pointers. That's definitely not something that only BEAM can do.

Memory management errors can be gotten rid of trivially if one restricts the allowed processes to safe Rust (which is not really a restriction compared to BEAM, because even there you are not allowed to poke at arbitrary addresses). The rest of the panics can be caught at the top level; that's what for example every single web framework I have ever used in any language does, in order not to bring down the whole server just because a panic/exception occurs in a puny little request handler.

I'm not very familiar with Erlang, but I see no reason why a system built in Rust cannot achieve what I have heard Erlang can.

Isn't that also true of Intel x86 and other architectures? Generally processes isolation is heavy weight and used to isolate operating system processes, ie, programs. Where as threads, be they green or whatever, are not separated by process isolation's memory protections.

As noted above, memory isolation between threads in Rust is achieved at compile time by the type system and "borrow checker". Other causes of panics can be caught and handled within threads.

Perhaps there is something about Erlang I am missing here?

Looking at your API it seems like you've missed a huge opportunity by not allowing type-safe communication between the server and nodes. Is there any reason you're passing &[u8] around rather than using associated types to define the messages? That would seem to both remove a lot of boilerplate and to reduce the likelihood of bugs.

1 Like

Thanks for your feedback.
Yes that's true, for a first release I wanted to make things simple since the API is not 100% done yet.
There should be a comment in the code somewhere about improving the type safety. I'll add an issue for this.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.