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

You know the old saying...

[__aaclcg7560]

No one ever got fired for using C.

Re:You know the old saying...

[cruff]

No one ever got fired for using C.

Someone at Volkswagen might.

Re:You know the old saying...

[hawguy]

No one ever got fired for using C.

That phrase has also been used for heyday IBM and Microsoft. But both sucked.

Sometimes you have to choose between money and sanity.

It used to be true of IBM -- as long as you were willing to pay, you could get near perfect uptime and nearly unlimited scalability. But you definitely had to pay for it -- we had a dedicated IBM service rep with an office in our data center, that sort of service doesn't come cheap. But we had no significant downtime in my 4 years there. Sure we had some jobs fail here or there due to DASD failures, but the core mainframe never had a hiccup and we completed several online hardware upgrades with no downtime.

Of course, I can get even better scalability and uptime with a distributed system (geographically distributed) on commodity hardware today, but that wasn't always a viable option.

Re:You know the old saying...

[shaitand]

C has it's ups and downs but sucking isn't one of its properties.

Re:You know the old saying...

[DutchUncle]

No one ever got fired for using C.

That phrase has also been used for heyday IBM and Microsoft. But both sucked.

Heydey IBM didn't suck. You whippersnappers just don't appreciate what we had to do on mainframes to lay the groundwork for distributed computing. A lot of the ultra-modern pipelining in processors can be traced directly to Cray and Amdahl and other designers from the golden age, and if they could have had as much spare hardware and memory as a modern system-on-chip without blowing up both a bank and the power grid, who knows how much further we'd already be.

Re:You know the old saying...

[luis_a_espinal]

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.

Cant we just talk directly instead?

[Anonymous Coward]

Im just 2 cubicles away from you, sad i read about it here

Is it practical to keep developing in C?

[Anonymous Coward]

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.

pointers & C

[Skewray]

The whole point of C is to be close to the hardware. The hardware has pointers. Why obfuscate?

Re:pointers & C

[serviscope_minor]

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.

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.)

kids these days...

[Anonymous Coward]

They don't like C because they haven't been taught it properly and instead go for things that are just trying to re-invent the wheel. Tell this guy to STFU, read a copy of the K&R book, and then get back to work using the native language of *nix.

Re:kids these days...

[fahrbot-bot]

They don't like C because they haven't been taught it properly and instead go for things that are just trying to re-invent the wheel.

... and C is hard and makes you have to think and stuff.

Community Support

[freak0fnature]

Where I am they chose SpineJS a few years ago, looked like a great language, easy, etc. After a few years, one thing we noticed was the lack of online help when you run into issues. It's just not that widely used. Rust is ranked 49th on Tiobe. Maybe it will be the next best thing, but if it isn't, you'll be stuck with something that has little community support.

Re:Community Support

[dmoen]

The SpineJS repository has 4 contributors. The Rust/Lang repository has 1,188 contributors. (on github)

It's not the language itself...

[DrTJ]

... that determines its success or not in a non-nieche segment.

It's the mass of developers that already know it, it's the accumulated code base (both locally and globally) and most importantly: the eco system of tools surrounding it: the compilers, the IDEs, the debuggers, the static/dynamic code analysis, build systems, code generators, mock tools, coverage tools etc.

The new kids on the block have a lot of catching up to do in areas which are not directly language related.

Re:It's not already rusted?

[gstoddart]

One might say 'crusty'.

Consider more than just the implementation

[quietwalker]

How many other engineers are going to be expected to know and maintain this? Ones you have on staff? Are you making sure to hire for folks who know Rust? If you have one, is your ops team up to supporting applications written in Rust, familiar with the errors and can handle it? What's the life expectancy of the app? Ever going to need to port it in the future?

Don't forget to factor in the bus factor, when you lose a whole engineer.

Lots of folks end up missing these and you end up with mysterious legacy code the business completely depends on for day to day ops that no one knows or understands. Heck, the other day, I was asked to unlock a windows NT laptop because it was the only known repository of source code for an app that was written over a decade ago - hopefully.

Concentrate on the Employee

[TechyImmigrant]

The engineer pushing for rust is emphatic, should I bulldoze him or take the plunge?

Take yourself out of the loop. Give it to the engineer. He/she wants to push it. Let him/her. Make the engineer responsible for pushing it, training people, documenting the procedures. Provide room to enable it to happen.

This is how the engineer grows and an engineer and how you grow as a manager, learning to trust the technical opinion of those doing to technical work.

Re:wouldn't hold my breath

[dmoen]

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.

Re:Portability

[garethjrowlands]

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.