Slashdot Mirror
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?
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?
You should definitely investigate rust. It's very well designed. It has great support to call into C code and C libraries. It compiles fast. The standard library is much more convenient than C/C++. You have complete memory safety by default, without garbage collection. It has great support for safe multithreading. Over time, your speed will increase because you won't be spending weeks tracking a heisenbug due to memory corruption. There is some learning overhead, but it's worth it.
The biggest issue is that you won't have as big of an ecosystem around rust. You won't find good support for all of the libraries that you might want to use. But those problems aren't insurmountable.
No.
Sigh.
Rust does have pointers and it is close to the hardware. It has a very similar machine model to C and of course C++. It also has an advanced, modern type system that disappears during compilation which makes large classes of error which are easy in C flat out impossible.
It's not obfuscation. You're telling the compiler what your intent is and the compiler checks that you're doing what you say.
To the OP: it might not be a bad idea. Though if you're considering C and Rust, you really ought to have C++ on the table. It's got the same resource footprint as the other two. You can be much less foot-shooty in C++ than C if you use modern style (no loss of efficiency either), and the tooling is much more mature than Rust.
There's really no reason ever to use C over C++ if you have a C++ compiler available.
SJW n. One who posts facts.
Obviously C has abstraction to some degree from the hardware, or you'd just use assembly. So you're basically arguing "C has what C has, so why wouldn't you use C?"
The answer is because there are problems with C, including pointers. If you pass a pointer to a child thread in C, what happens when you write through that pointer in the main thread? You're not required to use locks, and you're not required to remember that you don't own the pointer any more, so it's very easy to make a mistake and use a pointer when you're not supposed to. That's not so in Rust.
Just like static typing eliminates an entire class of error that you find in dynamic typing, Rust's borrow checker eliminates an entire class of error that you find in other languages. To pretend that there's no reason to look for an alternative to C is pretty ridiculous.
The SpineJS repository has 4 contributors. The Rust/Lang repository has 1,188 contributors. (on github)
I have written a truly remarkable program which this sig is too small to contain.
1st paragraph is false, due to the rather extraordinary design process that Rust went through.
designers also go off on an ego-trip, introducing numerous gratuitous syntactic changes, overlooking important features in their predecessor language they didn't understand
The Rust community is quite large, including many skilled language designers. The Rust github repository has ~1200 contributers. With that pool of talent,
there are no features of C/C++ that the designers don't understand. With this kind of community, and a formal change review/feature addition process, there's not much danger of a single ego-tripping designer messing up the language.
adding features few people actually need
The project transitioned from a hobby project to an official Mozilla project in 2009. During the 6 years from 2009 to 2015 (when the Rust 1.0 design was stabilized and released), a lot of Rust code was written. Features that seemed like a good idea at the time, but which had little practical use, were removed before 1.0.
3rd paragraph is also incorrect. The main feature of Rust is guaranteed memory safety, without a garbage collector, enforced by compile time type checking rather than by introducing run-time overhead. This memory safety includes a guarantee that shared global data can't be corrupted by simultaneous writes from different threads, something that no other language offers. C++ doesn't offer this today, no other language does.
I agree that Rust will influence future languages, but I don't think it will have much effect on C. The C++ community is already looking at Rust and trying to figure out how to compete with what it offers.
I have written a truly remarkable program which this sig is too small to contain.
The only benefit C++ arguably has over C in terms of avoiding common pitfalls is the STL and automatic destructors.
That's like saying the only thing we have better than the 1500s is electricity and internal combustion engines.
And if you follow a strict RAII pattern in C code, the lack of automatic destructors is much less of a burden.
But why bother? Do it in C++ and you get the same resource usage but with 1/10 of the typing and 1/10 of the bugs.
Every line of code you write is a potential bug. In C++ you can program the compiler to write them automatically for you bug free every single time.
Actually, the #1 reason not to use C++ is because if using C seems too tedious, then you should really consider using a higher level language altogether.
The lack of resource management makes C very tedious. C++ does it better than many other languages.
SJW n. One who posts facts.
What you say was true of early releases of Rust. But they removed all traces of any kind of runtime for exactly this reason. It was a breaking change but it happened quite a long time before the 1.0 release. Here's the documentation for the change: https://github.com/rust-lang/r...
Here's a blog entry on using Rust for embedded. It dates from February and uses 1.0-alpha but of course 1.0 is out now:
http://spin.atomicobject.com/2...
In these days of LLVM, the portability story is good, even relative to C. No C portability gotchas.
Since C++11 the destructor invocation in case of an exception is guaranteed. http://www.stroustrup.com/bs_f...
It takes work to write safe code in C.
Same with Java and even Ruby - Null refs, running out of mem, not closing database connections, etc - things that also characteristics of unsafe code. I've done the lot of it, C, C++, Assembly, Java, Python, what have you. For e-commerce as well as low level stuff.
And I've seen unsafe code written in all of them. Treating pointers as ohhh-chupacabara! is just ridiculous. People who program with discipline avoid those problems, whether they program in C or Python or what have you.
Your worst developers will use uninitialized variables, pointers to previously freed memory, and overflow buffers. But not in Rust.
Don't worry. Your worst developers will find ways to create unsafe code in Rust in one way or another.