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?

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

    4. Re:You know the old saying... by Tablizer · · Score: 3, Insightful

      It think it's safe to say that C as a language is optimized for speed, size, and hardware issues instead of software engineering issues.

      --
      Table-ized A.I.
    5. Re:You know the old saying... by TemporalBeing · · Score: 3, Insightful

      I know that's a joke, but it's of course nonsense. Plenty of people have gotten fired for using C, especially when their code had dangerous security vulnerabilities (which it ALWAYS does).

      Wrong.

      Yes, people have been fired for being bad programmers. I doubt many have been fired over security vulnerabilities, most likely because either (a) the vulnerability was discovered after the programmer already voluntarily left or (b) was rooted in standard operating procedures (e.g you just don't do that) - most due to people not realizing the consequences of network computers. (Prior to networking, security didn't really matter too much outside of specialized environments.)

      Further more, C-based software probably runs about 99+% of devices out there - most notably everyone's favorite OS kernel - Linux - is entirely written in C, as is the Windows NT Kernel, the BSD Kernels, etc. Most all operating systems use it at the core, and many applications use it - IOW, the world runs on C; aside from Assembly is it probably the most used programming language out there when you look at all aspects of software (even C++ doesn't compare). It only bites you if, like with any tool (including Java), you mis-use it. Best practices will save you from 99.99% of issues.

      Oh, and the OS's that don't use C in their kernel? They're all research or hobby stuff that more or less proves you could do it, but the performance is so abysmal (compared to the same thing in C) that no one would really use it, or they use C to bootstrap and load into their alternative language - typical of C++ OS Kernels. (Yes, there have been Java-based Operating Systems; they also relied on specialized hardware-based JVMs and no one uses them outside of small research projects.)

      --
      Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
  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.

    1. Re:Consider more than just the implementation by Austerity+Empowers · · Score: 3, Insightful

      Any decently educated programmer can pick up any language quickly and easily.

      Hire polyglots not language end-users.

      I'm torn on this one. On one hand, yes, anyone with a CS background who didn't cheat through school can learn a new language quickly.

      The issue is whether they can learn to write idiomatically correct code in that language, and whether they "think" in terms of how that language was designed. That usually requires a bit of time, not to mention some patience. Python is my usual example for this, it breaks a lot of (in my opinion) sensible conventions that people over 10 are used to: no need for semicolons (sneered at if you use them), mandatory white space, duck-typing, etc. Yes, you can learn python in a few hours, but to write "good" python that other python people can/want to support, and generally don't waste time fighting the language, you need to spend some time.

      Generally when I see a language like this I want to barf, but it's hard not to run in to something like this a few times in life, and if you're on the hiring side and you have a pile of (say) Python, you probably want to hire someone that can do it properly, versus someone from say, C, who is going to be very upset with almost everything.

  7. Use C by menkhaura · · Score: 3, Insightful

    Show him this story to indicate your attention to him and use C instead of this new-fangled and still-evolving language anyway.

    You'll get better debugging tools, more productivity (since you know C better) and a wider pool of replacement developers should the need arise.

    --
    Stupidity is an equal opportunity striker.
    Fellow slashdotter Bill Dog
  8. Newer is rarely better by Anonymous Coward · · Score: 1, Insightful

    C may be old, but it's a known entity, you can get plenty of help, it will around in 10 years whereas Rust may not be in use then. The level of C knowledge out there is very high, and should you need help with anything, you can get that help. Not so with Rust.

    I constantly fight the "newer is better" crowd at work, and I refuse to budge. If it works, it doesn't need fixing. I dislike change for the sake of change. I refuse, for example, to ever use Windows Server when my Linux machines work. I refuse to use IIS for anything. Compared to nginx, it sucks, and there is nothing to gain by my going there. DItto Python over Perl, when I have stuff that is working under Perl, there is little point in writing it in Python just because it's more modern.

    C has warts, but its track record is impressive. I refuse to use something that doesn't have years of a good track record. I need to be able to see the mistakes others have made, their fixes, their ideas, what worked for them. Talk with them if possible. Cannot do this with new stuff.

  9. Rust is cool by radish · · Score: 3, Insightful

    But it's still immature. I wouldn't personally use it for anything important.

    --

    ---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

  10. 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.
  11. Re:No. by phantomfive · · Score: 2, Insightful

    Rust has been developed by Mozilla for a specific problem they have, and their specific coding style. As far as I can tell it, works well for them and is a fine language.

    Unfortunately, it's still in the "growing" stage of languages, and may never make it out of Mozilla world, and Mozilla themselves might even drop support, which means you're in trouble.

    When you're choosing a language, you have to look at the entire ecosystem surrounding the language. It's not enough to look only at the language itself.

    --
    "First they came for the slanderers and i said nothing."
  12. Re:Failures with IBM Computers by stridebird · · Score: 3, Insightful

    So you spent 5 hours of your time, and 5 hours of tech support time, to avoid the data entry clerk spending 6 hours simply rekeying the data? Why? Doesn't sound like the right choice, unless the clerk had gone home already or something.