9 ms·

Why would anyone choose C when Rust becomes mature?

• Mr_lavos 10y ago
  Why would anyone use Rust when C++ is here and is already mature?
  • sgift 10y ago
    I haven't used C++ in a long time, but ... can I still use standard language features (Templates) and my code will compile with one compiler, but not the other? That would be a big reason in my opinion.
    • AlexeyBrin 10y ago
      GCC and Clang are 100% C++14 compatible, not sure about MSVC but I think it is close to 100% compatibility.
      • mfukar 10y ago
        https://msdn.microsoft.com/en-us/library/hh567368.aspx https://msdn.microsoft.com/en-us/library/hh567368.aspx
    • gpderetta 10y ago
      Why would that be a reason? There is still only one rust compiler.
      • sgift 10y ago
        I'd rather have one C++ compiler that works great on every platform than multiple ones that only work on one (or two) platforms.
        • gpderetta 10y ago
          GCC is a great C++ compiler that works on more platforms than the rust compiler. Clang, another great C++ compiler, works on at least as many platforms as the rust compiler. Again, why would this be a reason to prefer rust over c++?
          • carussell 10y ago
            On the off chance that you aren't being deliberately obtuse, here's what's going on: If, given two situations 1. The the set containing compilers for language L is size 1, and that compiler works on multiple platforms; or 2. The set of compilers is > 1, but there exists at least one compiler in the set which is a) popular for use with language L b) not fully interoperable with the other compilers from the set that satisfy (a); then situation 1 is the preferable one Or to put it another way, nobody complains about code not working with compilers that don't exist.
            • gpderetta 10y ago
              3. The set of compilers is > 1, and there exist at least a popular compiler that works on multiple platform. Rust is in 1 of course. C++ is both in 2 and 3. In particular for C++, the compiler in 3 works on a strict superset of all the platforms supported by rust. As you are free to support only this C++ compiler and ignore every other C++ compiler (you must not care about multiple implementations otherwise you wouldn't think that 1 is a good solution), it seems to me that 3 is strictly better than 1. edit: I do concede that the existence of a popular but non-interoperable compiler[1] does fragment the community and it has been an issue in C++. Things are getting better though, and if rust becomes popular enough it might become an issue there as well. [1] We all know which compiler I'm talking about.
• pavanky 10y ago
  The C compiler is often the first thing ported over to new architectures because it is fairly easy to do. Rust probably will not come close to being that universal. On the desktop side of things, it will probably continue to be the favored systems language until universities start incorporating rust into their curriculum. Very few people have the motivation and incentive to learn a new language to accomplish something they can accomplish in a language they already know.
  • sgift 10y ago
    > The C compiler is often the first thing ported over to new architectures because it is fairly easy to do. Rust probably will not come close to being that universal. Seems to be a good place to ask: Is there a comparison out there of the complexity of a "typical" C compiler versus the Rust compiler? To check if it would be actually possible to port Rust to new platforms easily?
    • pklausler 10y ago
      Data point: in 1998, I wrote a C compiler from scratch (preprocessor to assembler) for a new ISA (Cray X-1) to support s/w development in a simulation environment, and it took me about 3 months and 6KLOC to get something that could build IRIX (later Linux) correctly.
      • zzzcpan 10y ago
        Yeah, porting LLVM IR should be much easier these days. Not that it matters though, C legacy is not going anywhere.
  • _yosefk 10y ago
    I ported C compilers (badly) and manage people who do it (well.) Today you port LLVM, either yourself or using a commercial LLVM backend generator. This makes Rust nearly as accessible as C (in that the platform vendor will bundle clang with some platform-specific extensions but not a Rust frontend with similar extensions. But the heavy lifting is the backend.) This is not to say that Rust will spread like wildfire, just that porting C isn't easier.
• agentgt 10y ago
  Well because Rust's support for Arduino is still in its infancy [1]. [1]: http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-uno/ http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-u...
• Animats 10y ago
  Rust is much harder to learn than C. Rust is a good language, but, like C++, it has several levels of abstraction that C does not. With C++, the template fans took over the language and overcomplicated it. Now you can't do anything in C++ without some template library. Even C++ enthusiasts admit that template programming is hard. It may even be a specialist skill that most C++ programmers do not have. Rust picks up where C++ leaves off in that area. There's so much going on under the hood in templates that programmers are pushed into a ritual/taboo style of programming. (That's where you're taught to do something a certain way, but may not know why.) It's really hard to kill off C.
  • tspiteri 10y ago
    Rust is much harder to learn than C. Rust is a good language, but, like C++, it has several levels of abstraction that C does not. I don't agree with this; using this logic, I would arrive to the conclusion that C is much harder to learn than assembly, as it has several levels of abstraction that assembly does not.
  • echelon 10y ago
    > It's really hard to kill off C. While I totally agree with C's longevity, Rust has something special going on. You know that long bets website? I'd be happy to place a ten year bet with someone that Rust starts taking a big slice of C's pie. For kernel development, embedded systems, you name it. I'd be happy to qualify my bet with metrics based assertions, too.
    • s_ngularity 10y ago
      It seems highly unlikely to me that Rust would take over true embedded systems (i.e. EEPROM, no OS, etc.), simply because nobody is going to write a Rust compiler for their custom architecture. The resource constraints are what make C essentially the optimal solution for those applications
      • Manishearth 10y ago
        Note that you just need to write an LLVM backend for this, not a full fledged Rust compiler. LLVM IR is somewhere between C and assembly so it should be about as hard as writing a C compiler. Rust works fine without an OS. Some of the nice-to-have-stuff (inline assembly) aren't stable yet (I have been meaning to push for this with an rfc), but they'll get there.
• gravypod 10y ago
  Because the amount of code already written in C is astonishing and that's just counting stuff that is in the public sphere. Once there isn't a dependancy on C-programs or code then C will be obsolete. Now the task comes to rewriting hundreds of thousands of hours of code to make it so that the rust backends for systems are up to spec with what's already layed down. C is popular because a lot of stuff is written in it and it's the obvious choice due to the tooling for certian tasks.
• AnimalMuppet 10y ago
  Some of us have to choose something now, or at least before Rust becomes mature.
• muricula 10y ago
  Rust is off the table when integrating with large preexisting C/C++ code bases for reasons of maintenance and integration with the existing code. For instance, writing a Linux kernel module in rust is possible, but fraught. You don't get access to any of the existing useful macros. You need to write/generate bindings for all of the C code and in order to make it at all rust-like you really need to write wrappers for the C functions. With each new nightly release of Rust or new release of the kernel your module may break.
  • Manishearth 10y ago
    I've been working on integrating Rust with Firefox's C++ codebase and while it is challenging it's not prohibitively so, tooling like bindgen makes things easier. Nightly Rust shouldn't be breaking your code. Use stable features, use repr(C) for stuff that's crossing the boundary (we sloppily didn't in some places, this did cause a breakage on a rust up, but that was our fault), and you should be good. Avoid unsafe-code-UB.
• qwertyuiop924 10y ago
  Because most idiomatic rust operates at a higher level of abstraction than C. Sometimes that matters. The standard argument is that most of Rust's abstractions are, as much as possible, "zero cost". However, while Rust's abstractions are very cheap, there is no such thing as a zero-cost abstraction. Why? Because abstractions hide information, and usually provide nicer interfaces than the underlying one. That changes the way you think. If, for example, your stdlib has a standard growable/shrinkable list type that's implemented as an LL under the hood, you'll likely use that structure whenever you need a list, even if you think it's a bad idea to use an LL in that context: it might not even occur to you to check how it's implemented. Obviously, Rust doesn't do anything this braindead, but it still has abstractions, and those abstractions change the way you think, and may result in suboptimal programs as a result. This isn't necessarily bad: I don't want to program in raw machine code all the time,and I doubt any of you do, either. But it is something to be aware of.
  • steveklabnik 10y ago
    This is a misapplication of "zero cost abstractions." The slogan, taken from C++, means: > C++ implementations obey the zero-overhead principle: What you don’t use, you don’t pay for [Stroustrup, 1994]. And further: What you do use, you couldn’t hand code any better. - Stroustrup Everything has costs; that's engineering. But "I chose the wrong data-structure for my task" is not what the slogan is addressing.
    • qwertyuiop924 10y ago
      Indeed. But my point is that the idea that immidiately presents itself when you think "zero-cost abstraction" is wrong. >What you do use, you couldn’t hand code any better. And that will never be true: if you know exactly as much about your usecase as the abstraction, than that might be possible, but that is almost never the case (which was my second point).
      • steveklabnik 10y ago
        > And that will never be true It is often true. Higher-level Rust code can and often does compile into the same assembly (or sometimes better!) than a lower-level construct. That's the entire premise of optimizing compilers. They're not perfect, but they do achieve this goal more often than "never". See the Option comments above for one trivial example.