It’s something we are looking very seriously at.

First things first, Rust is not launched, but Beta from next Monday Launch version 1.0 in May. So huge projects would suffer as the API is changing a lot.

So caveat aside (but not ignored, it is a big issue), I see the advantages as

1: No crashes because of code misuse (as long as you do not use unsafe {} )

2: No memory leaks

3: No data races (so you can thread this thing like mad, but better is has async task handling (crs pattern to). So lighting up your machines cores is no prob.

4: Cross platform (really much better than most)

5: Inbuilt version management, build system and test harness (with benchmarking to).

6: Package management system (no more I Cannot build XX, it becomes automatic)

7: Inbuilt generics and traits (c++ concepts and more)

8: Very strongly typed (near zero runtime)

9: Very fast

10 compiles into a c lib basically (easy integration)

Sounds great, well it is, I took last week to investigate and caveats aside took a bit of a dive in there (just popping into the office to keep up with all the design discussions for routing_v2 -> looks great BTW).

So I figured what are our hardest libs to write (self encryption and routing). So I transposed self encryption from c++ -> rust. It took 3 days. It is not fully complete but close and that is a test suite, CI setup, packaged and published lib ( https://github.com/dirvine/self_encryption https://crates.io/crates/self_encryption So again not much on the sleep front ). I need to finalise the encrypt and close methods, but I am waiting till after Monday as I need a part of the API to settle in Rust.

So now I will transpose routing to see what it looks like from there.

I am doing this myself as a sideline just now as we are right in launch mode for testnet3 with routing_v2 and crux (which will be 100% c++11 code). I Cannot disturb the real devs here, or you folks would rightly lynch me

So next 10 days I will try and get routing and vaults up in rust to run alongside c++ and we will really have to consider this then, if it is all successful.

So saying that, we gain a lot from Rust, it’s a very modern safe and secure language, but with modules (think Ruby builder ++ ) so you can just type safe-farmer "1.0.0" into a cargo file (config thing) and you will have full access to the code. Or type ````safe_client “1.0.0”``` and you will have all that built and ready (in only a minute or so). So goodbye complex build systems as well. A real PITA we spend months working on.

Not only that but to build in this systems language you have simple access to not only our code like this but everyone’s. The apps so far in Rust are kernels, window managers, games (2d and 3d), GUI’s, crypto libs and much more. So think managed language done right with systems language performance. Build anything you want with it.

So the community using it range from php/python/ruby etc. as well as java/c#/f# and so on to functional programmers haskel etc. which is a surprise. What are these folks doing near pointers and the likes, these are dangerous tools, not for fast app dev, but the issue is. You cannot make segfault/race condition type mistakes in Rust, it wont compile (very strong type system). Savings on debug here are colossal. The target group for the language was c/c++ devs and they seem to really like it, the rest are a surprise and a really good one.

So all in all it has to be taken seriously, I think with all the advantages you are looking at productivity gains that will be very substantial (I think you are looking at 10X or more for c++ systems work) and apps that do not crash.

My take is that this will feature in SAFE, how much I am not 100% on yet, the testing continues, but I would not be personally surprised if we transpose over in testnet3 as it seems to good to miss. If somebody took our code and transposed it they would be in a much better position than us to take it forward and that to me says it all really. Also great for pods, we have found c++ at this level to off-putting for many to help out with and no surprises, it is extremely hard. We need strong safe and secure code to go along with our strong safe secure network and this may be an edge that just helps us along.

With routing_v2 for instance in vaults we have reduced the code by 98% in the last three weeks, so transposing over is not a showstopper for us as we have the resource as long as tenet3 is up and running as the app dev team will be working like maddies and the core team may have some space to do this.

So you can see my conundrum, but I think it’s a done deal really, unless testing shows us a big issue I think Rust will be a very welcome friend to us and remove almost 90% of our time we spend on build/data races/memory protection and more, all that 90% goes then into core algorithms and not silly code issues.

It also lowers the barrier for anyone getting into the core code (whilst increasing security - so it’s a bit mental) and to me that is also very compelling.