Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by timothy on from the a-b-rust-d-yep-works-fine dept.

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?

11 of 437 comments (clear)

  1. You know the old saying... by __aaclcg7560 · · Score: 5, Insightful

    No one ever got fired for using C.

    1. Re:You know the old saying... by hawguy · · Score: 4, Insightful

      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.

    2. Re:You know the old saying... by shaitand · · Score: 5, Insightful

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

    3. Re:You know the old saying... by DutchUncle · · Score: 5, Insightful

      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.

  2. pointers & C by Skewray · · Score: 4, Insightful

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

  3. kids these days... by Anonymous Coward · · Score: 4, Insightful

    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.

    1. Re:kids these days... by fahrbot-bot · · Score: 4, Insightful

      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.

      --
      It must have been something you assimilated. . . .
  4. Community Support by freak0fnature · · Score: 5, Insightful

    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.

  5. It's not the language itself... by DrTJ · · Score: 5, Insightful

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

  6. Consider more than just the implementation by quietwalker · · Score: 4, Insightful

    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.

  7. Concentrate on the Employee by TechyImmigrant · · Score: 4, Insightful

    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.

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.