Newbie with a few questions about the Rust ecosystem


#1

Good day, peeps!

I’ve just stumbled upon Rust and I have some questions about its ecosystem and potential long term viability. I’m not interested in starting a contentious debate. That said i need to make some decisions that will effect the path of the project we are working on.

First, we (my company) are developing a cryptographically secured decentralized computational mesh. This overlaps somewhat with blockchain technology but has other interesting capabilities that blockchain cannot support. It’s irrelevant to go into more detail at this time other than we need to decide what platform to build the core technology on. Rust is intriguing because it appears to be from conception cross platform. Our tech will ultimately need to be installed “everywhere”, including embedded in IoT sensor arrays, iOS, Windows, Linux etc etc.

What we really need is a fast, stable and secure platform that abstracts the core operations into something that is as nearly perfectly cross platform as possible. Any interactions with databases, people, etc would be a layer further up in the system. Rust seems to be a good candidate other than it is so new. My concern is that Rust isn’t “enterprise ready”, not so much as a programming language but as something that plays nice with all the other systems in a large enterprise.

The current thinking is to go with C++. But I find the compile time memory safety of Rust a potential game changer in managing complex systems and large arrays of M2M sensors, IoT devices, etc.

One concern is that our tech road map includes integration and interactions with blockchains. The language of choice in that universe appears to be C++.

Another concern is finding Rust developers. C and C++ developers are numerous. Rust, not so much.

Anyway, that’s my story and I’m sticking to it. Looking forward to your input.


#2

There are several blockchain companies that are using Rust; MaidSafe, Parity, and others.


#3

MaidSafe is in alpha and sits in the long tail of crypto projects, Parity is in beta with no visible business model. Hardly enterprise ready. Something as big as Hyperledger Fabric uses Go.


#4

Not only that, but here is a list of major companies that think Rust is enterprise ready: https://github.com/jonathandturner/rust-big-name-big-list


#5

Nice! That will give me a lot to look at.


#6

Rust is relatively new, but its compiler/toolchain is rock solid and stable (there are some new language improvements not implemented yet, but everything that’s been released is reliable and dependable).

3rd party Rust crates are a mixed bag. The top ones are great. In the long tail of small crates you may need to make a pull request to fix/add something (however, the it’s not much different from using any other random C or JS library from GitHub).

For C++, there’s bindgen. You can generally take a C/C++ codebase and use it in Rust. People usually write safe wrappers around such code. It’s a bit of extra effort to make the wrapper, but then it pays off because you’re getting most of Rust’s safe semantics for the C code as well.

With hiring developers that’s a bit of a chicken-egg problem. Some people hold off with learning Rust until they see job offers. On the other hand Rust enjoys being a “cool” language right now, so a Rust job offer may be more attractive than an average C++ job.


#7

This is what makes it attractive to me. It’s aesthetic isn’t about bells and whistles.

This is interesting. This would help integrating with the plethora of blockchain projects that use C and C++. We could encapsulate C++ in these wrappers and at some future point perhaps circle back and rewrite the C++ into Rust.

Where I can see us using Rust is to write what is essentially a kernel. Memory and concurrency safe code would be invaluable at this level. And we would avoid all of the extra weight of something like C#.


#8

Are compile times important for you? It’s a rather interesting dimension for consideration when talking about Rust. Currently, I’ve heard that compile times (fresh build) are comparable with that of C++ (that is, pretty darn slow). I think incremental compilation times now are much worse then for C++ (at least, not over templated and judiciously pimpled C++), but they are to get a major improvement soon, and in theory it should be possible to beat C++ eventually due to a saner compilation model.

Another concern is finding Rust developers. C and C++ developers are numerous. Rust, not so much.

I think that a lot of C/C++ knowledge is easily transferable to Rust, and I find training material excellent (kudos to @steveklabnik and others!), though not as numerous as for C++.


#9

I’d say that Rust is much nicer solution than C++ because making a decent quality cross-platform application becomes pretty much trivial. At work I develop on a Windows machine, yet my laptop runs Arch Linux. I’ve found that everything in Rust Just Works, the thing which makes it difficult is that we use 3rd party dependencies (mostly written in C/C++) which are Windows-only.

I’m actually working on a couple Rust modules for work, where the modules themselves are being integrated into our wider application as a bunch of DLLs and I’ve found that to be quite painless. bindgen and cbindgen are great tools for generating (and keeping in sync!) the various FFI bindings so you can interoperate between languages.

The ecosystem itself is quite robust given its age. I’ve found that Rust libraries tend to be of a higher quality than most other languages, mostly due to the fact that documentation and unit testing is built in and because you usually have to acknowledge when you are deliberately ignoring errors (usually in the form of unwrap()).

Apart from the non-ideal compile times, the tooling is very good. rustup and cargo are great for managing your project and keeping your compiler up to data. A single line cargo build --release is sooo much nicer than wasting hours on cmake trying to get your project to build. clippy (for lints and static analysis) and rustfmt (formatting) are also great for keeping your project healthy.


#10

Compile times may or may not be an issue. We want a tight, clean kernel without a lot of dependencies so it should never be a massive executable. Beyond that kernel it might become an issue but other layers such as the UI might be done in a different language.