Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Programming

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

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?
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by creimer ( 824291 ) on Thursday October 15, 2015 @02:50PM (#50737731) Homepage
    No one ever got fired for using C.
    • by cruff ( 171569 ) on Thursday October 15, 2015 @02:55PM (#50737767) Homepage

      No one ever got fired for using C.

      Someone at Volkswagen might.

      • by creimer ( 824291 )
        I don't think you can blame the programming language for that one.
      • by Mirar ( 264502 )

        I thought Bosch wrote that code and told WV not to use it like that. Anyway, it's probably written in Simulink.

    • by TR NS ( 4242885 )
      There is always risk with embracing new tech, but I would be willing to bet you won't be disappointed with Rust.
    • 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).

      • by TemporalBeing ( 803363 ) <bm_witness.yahoo@com> on Friday October 16, 2015 @10:00AM (#50743257) Homepage Journal

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

  • by Anonymous Coward on Thursday October 15, 2015 @02:50PM (#50737733)

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

    • by creimer ( 824291 )
      Don't feel bad. On the day I was appointed as an assistant lead for a video game title, management decided to kill the title. I didn't find out until I saw a news item posted on an industry gossip website a month later. The QA manager didn't know. No wonder the new build was late.
  • by Anonymous Coward on Thursday October 15, 2015 @02:55PM (#50737769)

    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.

    • This strikes me as a complete answer. If it has good support for calling out to (native) C ( and you have the skills to do that when needed) and does not have the memory blowout of Java, you are losing nothing by basing the project on Rust instead of C.
  • pointers & C (Score:5, Insightful)

    by Skewray ( 896393 ) on Thursday October 15, 2015 @02:56PM (#50737779) Homepage
    The whole point of C is to be close to the hardware. The hardware has pointers. Why obfuscate?
    • Re:pointers & C (Score:4, Informative)

      by serviscope_minor ( 664417 ) on Thursday October 15, 2015 @03:01PM (#50737817) Journal

      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.

      • by lgw ( 121541 )

        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.

        So many bad books on C++ make this very hard for people to learn. I haven't yet found a good site for explaining why and how to have empty destructors for all but a few carefully-reviewed library classes (this is more than just RAII, or perhaps it's the golden version of it). Heck, it'd be nice to find a good guide to the latest standard, with a bunch of new anti-foot-shooting tools, plus "concepts" to allow much more sane templating for performance.

        Heck, even explaining how to use std::strings and vector

        • Your classes don't need empty constructors, especially if they have nothing to destroy.
          However in most cases a 'base class' should have a virtual destructor!
          If that one is empty depends on the class.

          • Re:pointers & C (Score:5, Interesting)

            by lgw ( 121541 ) on Thursday October 15, 2015 @04:34PM (#50738683) Journal

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

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

              Are you sure? If you aggregate (say) an int with a string in a simple struct, the struct will have an automatically generated non trivial destructor, since it needs it to clean up the string. But you don't, of course, have to write a single line of code to make it work properly.

            • Re:pointers & C (Score:4, Informative)

              by Ateocinico ( 32734 ) on Thursday October 15, 2015 @11:03PM (#50741003)

              Since C++11 the destructor invocation in case of an exception is guaranteed. http://www.stroustrup.com/bs_f... [stroustrup.com]

        • by HiThere ( 15173 )

          I'd settle for something good on how to use unicode with C OR C++. Saying "use ICU" doesn't help when there's no decent documentation on using ICU. After looking over the C++11 standard carefully, it looks as if it *is* possible to use unicode with C++, but it's still not clear how. Were I already an experienced C++ programmer, perhaps the discussion of facets would make sense. As it is...no. And there don't even seem to be any decent examples.

          Most of the libraries for using unicode aren't sufficient f

      • I wish I could have C++, but stuck with C. I don't want the ugly parts of C++, but the simple stuff like slightly better typing, simple non-virtual classes, etc. Most of the people who objected to it are gone now though, so...

        • by mwvdlee ( 775178 )

          Seems you just want to get rid of the C++ library, which is pretty easy; simply don't use it.

          • I just want the better-C-than-C. The problem is people are worried that once you make a switch to C++ that you're on the slippery slope to bloatware. Which is why C++ is much less common in the embedded systems world.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      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 poin

    • The whole point of assembly is to be close to the hardware. The hardware has registers. Why obfuscate?

      • Ah, but assembly uses labels as targets of jump and subroutine instructions. And data memory references.

        You should do it like the hardware does. Use numeric memory addresses as targets of instructions that address memory.
    • by ADRA ( 37398 )

      Hardware has registers / stacks and jumps. Pointers are just too high level...

  • by bluefoxlucid ( 723572 ) on Thursday October 15, 2015 @02:58PM (#50737793) Journal
    C is pretty rusty.
  • No. (Score:2, Informative)

    by Anonymous Coward

    No.

    • Re: (Score:3, Insightful)

      by phantomfive ( 622387 )
      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.
      • With that attitude, we'd all be using Fortran, Cobol, Lisp (okay, I like that idea) and Pascal instead of the newfangled stuff.

        If you have to sell some relatively obscure language to a big team, or to a corporation or whatever, then yes I agree with you - go with the tried and true (even if it's also painful and tedious) unless you have a hell of a specific killer feature as a reason for using the new tool instead of the old one.

        But for smaller side projects, personal projects, experimenting - why not
        • Re: (Score:3, Interesting)

          by ClickOnThis ( 137803 )

          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.

  • kids these days... (Score:4, Insightful)

    by Anonymous Coward on Thursday October 15, 2015 @03:01PM (#50737819)

    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.

    • by fahrbot-bot ( 874524 ) on Thursday October 15, 2015 @03:40PM (#50738147)

      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.

      • by Eythian ( 552130 )

        Rust is probably harder to get to grips with then C. The difference is that when you screw up in rust, it usually yells at you. When you screw up in C, it blithely goes on doing what it thinks you want.

    • K&R leaves a lot to imagination when it comes to describing C. Even if you are living back in the 90's, you won't be proficient in C until you've read "C: A Reference Manual" by Harrison & Steele.
      • Specifically, K&R doesn't really teach you how to deal with memory leaks. It's good for learning the language, and one of my favorite programming books, but it's also an introduction, not a complete tutorial.
  • Community Support (Score:5, Insightful)

    by freak0fnature ( 1838248 ) on Thursday October 15, 2015 @03:04PM (#50737827)
    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.
  • by DrTJ ( 4014489 ) on Thursday October 15, 2015 @03:06PM (#50737841)

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

  • According to wikipedia
    https://en.wikipedia.org/wiki/... [wikipedia.org]
    "Rust 1.0, the first stable release, was released on May 15, 2015."

    So it's five months old.

  • Portability (Score:4, Interesting)

    by Locke2005 ( 849178 ) on Thursday October 15, 2015 @03:09PM (#50737867)
    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.
    • by Trepidity ( 597 )

      Yeah, for now this is one of the bigger drawbacks. The officially supported platforms [rust-lang.org] are:

      Windows (7, 8, Server 2008 R2)

      Linux (2.6.18 or later, various distributions), x86 and x86-64

      OSX 10.7 (Lion) or greater, x86 and x86-64

      There is supposed to be ARM support in the works.

  • by quietwalker ( 969769 ) <pdughi@gmail.com> on Thursday October 15, 2015 @03:10PM (#50737871)

    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.

  • The problem with languages like Rust is that, in addition to addressing important issues in the languages they intend to replace, their designers also go off on an ego-trip, introducing numerous gratuitous syntactic changes, overlooking important features in their predecessor language they didn't understand, and adding features few people actually need. It's possible that a language like Rust will eventually replace C, but I wouldn't put my money on any particular one.

    More likely, ideas from Rust will simpl

    • by dmoen ( 88623 ) on Thursday October 15, 2015 @04:52PM (#50738835) Homepage

      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.

    • This. C can be fixed. It takes time, and compilers are usually ahead of the standard. How long did it take for C to get the restrict keyword? That allows us to control pointer aliasing in a portable way. The impetus for that was that FORTRAN could outperform C because, AFAIK, it assumes no aliasing.

      There are already a lot of static checkers [llvm.org] for C. I'm willing to wager they can catch just as many bugs at compile-time as Rust. Having such tools is almost as good as having checks integrated into a stand

    • Even if templates are already present in C++, they are a PITA to use. Rust is really really easy to use for those.

    • The interesting feature of new programming languages is often not what they make possible - you can write any program in the world in assembler, after all - it's what they make default.

      Rust doesn't allow null values or null pointers. The Rust compiler automatically frees memory when the last reference to it goes out of scope. Variables are immutable by default. You can't use pointer arithmetic by default. Only one mutable reference to any piece of memory is permitted to exist at any one time by the
  • Use C (Score:4, Insightful)

    by menkhaura ( 103150 ) <espinafre@gmail.com> on Thursday October 15, 2015 @03:12PM (#50737897) Homepage Journal

    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.

  • What if I need another engineer to work on the code?
    If we are talking about 'C-like' languages, Rust, D, Java, C# ...mI would guess such an engeneer is in the wrong profession, no? Implying he can not cope with Rust, as I understood you.

  • If Rust, the compiler and everything is written in Rust, then I would trust it.

    It looks like it's written in big parts in C and C++.

    Don't know if it's glue to the rest of the system or that Rust wasn't good enough.
    Maybe someone can elaborate?

    • I'm not aware of a 'compiler compiler' aka parser and scanner generator, that generates Rust code.
      So bootstrapping the language with itself requires a parser generator that emits Rust ...

  • A lot depends on where and how you want to talk to the hardware. Last time I checked, the kernel (or kernel driver) is the only thing directly writing to memory space mapped to actual hardware and the kernel is the only space where you are catching CPU interrupts. Depending on your platform, the kernel is very likely going to be written in C.

    If you are making calls to the kernel drivers from userspace via kernel file interface, ioctls, or some other user-to-kernel API, then you can do that in just about a

  • Now I'm heading a project that uses a RoR application...

    To quote an old Irishman I knew once, "Oh boy, now yez' inna helluva fix!" :)

    But seriously, as for what language to use, that would be one that you know and are familiar with that can do what you need it to do.

    In other words, I have no idea because there wasn't really enough specific info in your post for me to take a good guess. Sometimes it's best to work backwards and figure out what tools or languages won't work or aren't suited to the task. That can often help narrow down the list of possible choices,

  • said he could write the extensions needed easily in Rust.

    This is probably true but its also aggressively stupid. Ruby, Matz Ruby anyway, is a C program, Rubinius is a C++ program, JRuby is Java. The point of writing Ruby extensions obviously is so that you can leverage the expressive power of the high level interpreted language to get stuff done fast and safely while interfacing whatever it is you need to interface.

    Your extensions should not be complex. They really should allocate a little memory to store what needs to be stored, and do some type conversions f

  • Rust is cool (Score:4, Insightful)

    by radish ( 98371 ) on Thursday October 15, 2015 @03:47PM (#50738205) Homepage

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

  • I've heard Rust mentioned a few times so I decided to give the manual a once over to see what it is all about. First impression is that it is a very C like language, except that the memory model is highly regulated. This is good in some ways, it should be nearly impossible to screw up your memory handling with normal code making it safer by default. However, in my brief glance over I can't see any way to allocate a block of memory at runtime, which seems like a significant drawback. The language appears
  • If your code has to suspend itself for a specified period of time, then I would not recommend using Rust. Remember...

    Rust never sleeps.

  • Alternatively you could try using a modern language like Nim that'll give you the same sorts of benefits as Rust, but allows compilation into C so you have the same expectations and performance as you would with C.
  • by TechyImmigrant ( 175943 ) on Thursday October 15, 2015 @04:02PM (#50738343) Homepage Journal

    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.

  • A good software engineer should be able to learn a new language in a week or so. If there is something inherent in the language which makes this not possible, e.g. pointers, generics, functional v. procedural, etc., then the software engineer has a gaping hole in his/her knowledge and may need some additional training.

    That point aside, I think the discussion here makes the decision C, mostly because of unknown future support for Rust--it is too new to know.

    Unless C has an easily describable deficiency whic

  • If it is just for fun, go ahead and play with Rust. You can write C-compatible libraries with it no problem.

    If it is for work, however ... Stay with your C.

    Rust is nice and everything, but the ecosystem is incredibly small. There are few libraries for it, many are already unmaintained and/or not working. Also the tooling (IDEs, compiler, the cargo build tool, etc.) are fairly immature. I have been looking at it recently with the goal of writing some extension modules for Node.js & .NET, but I went back

  • I don't know about replacing C but my car certainly seems to think that replacing Fe with rust is a practical thing to do!

  • C has probably been around longer than you have. Rust probably isn't even a blip on the radar.

    Be very wary of embracing immature technology for anything that matters. There are good reasons to do it, but they have to be EXTREMELY good reasons.

    Otherwise, even if the tech succeeds, you will be stuck with a code base with immature and deprecated idioms. (Note the very old Java applets you sometimes see on the web that modern versions of Java make nearly impossible to run. So much for "write once run anywher

An algorithm must be seen to be believed. -- D.E. Knuth

Working...