Ask Slashdot: Is it Practical To Replace C With Rust?

interval1066 writes: I've heard of rust from various sources around the net for a few years and never paid it much mind, there are so many new languages out now since my early days doing C programming, which what I've stuck to and made me my career. Now I'm heading a project that uses a RoR application to control a large series of sensors and controls in a manufacturing process. Naturally I want to talk to the hardware using a GEM extension written in C, as I've done before.

But another engineer who is not a fan of C (seems few younger engineers are) said he could write the extensions needed easily in Rust. Seems like this is a thing. I took a closer look at rust and it looks to me like another attempt at "C" without pointers, except rust does have a kind of pointer, it appears. I like its ranking on a list of fastest languages, and it seems pretty simple with an initial tool footprint that is quite small.

But what are the trade offs? Another language, and one that few engineers know (much like Vala, which I like very much but has the same small user base). What if I need another engineer to work on the code? I pretty much know what I can expect from C/C++, rust is a huge unknown, what if I run onto a roadblock? The engineer pushing for rust is emphatic, should I bulldoze him or take the plunge?

Comments

Portability

[Locke2005]

If you're ever going to be porting it to another platform, then do it in C; there are C compilers available for almost every piece of hardware out there. If you're certain it only needs to run on a single, unchanging platform for the lifetime of the code, then using Rust might be a good idea.

Re:pointers & C

[lgw]

The reason for empty destructors is that destructors that actually clean up resources are usually a bad idea. (Debugging-related stuff in destructors is different.) The "allocate in the constructor, clean up in the destructor" pattern was a natural evolution from well-written C code. If you were used to "allocate at the top of the function, clean up at the bottom", it was the obvious better approach. But it's still just as error-prone (just fewer places for errors), and the fact that the destructor doesn't get called if the constructor throws isn't broadly internalized by coders (and is my least-favorite intermittent resource leak to run down).

Having very small resource-specific classes, similar in functionality to auto_ptr or unique_ptr (just managing a file handle or whatever instead of memory allocation) is the better answer. Only clean up a resource in a class whose only purpose is to clean up a resource. Using those primitives as members in other classes, or as local variables, is as idiot-proof as C++ gets.

The resource-leak headaches saved by difference in approach is amazing when junior coders are involved, it's really a difference in kind. And it's dead easy to police in code-reviews. The last time I did C++ we had a single, templated class in library code, and nowhere else in the code base was a non-trivial destructor allowed. (Odd cases like adding an object to a global list, and removing it on destruction could be managed within this system.)

Re:No.

[ClickOnThis]

No one expects an obscure new language to gain mind-share without a good reason.

There is one crucial element to a new language gaining support: expressive power. Does it let you to express the solution to a problem in a better way than others?

Actually, there are two elements: expressive power and viable cross-platform support. Compilers and/or interpreters must perform well and be available for all platforms that matter.

Well, really there are three elements ... uh ...

I'll come in again.

Re:You know the old saying...

[TheRaven64]

It's optimised for speed, as long as your target is basically a fast PDP-11. C does not allow the compiler to rearrange data layouts, which makes it hard to take advantage of SIMD or to avoid false sharing. C makes it very hard to statically reason about memory ownership, requiring a defensive programming style with redundant operations when writing multithreaded code. C only recently had a memory model for concurrent accesses at all and so most multithreaded C programs contain undefined behaviour.