10 ms·

C is a very small and very portable language. Rust is not. I wondering why people bother comparing them at all.

gpderetta 10y ago
I doubt that a significant amount of C programmers will switch to Rust. On the other hand, rust is very attractive for us C++ programmers.
- Scuds 10y ago
  Do you think we'll see major games having significant engine components being written in Rust?
  - gpderetta 10y ago
    I don't work in that field, but I doubt game programmers will be early adopters of rust, as I think they mostly don't care about memory safety.
    - Crespyl 10y ago
      There's been some interest, but I think the likes of jblows Jai language that emphasize rapid development and programmer convenience over correctness will likely catch on faster.
  - mmstick 10y ago
    DICE and others have been investigating and using it to create tools for developing games. There is interest in using it within game engines, but there's just the issue of Rust support for major consoles. There is great interest in the PC gaming world though that's not constrained by console support.
- lacampbell 10y ago
  I appreciate rust making a break from C++ and cleaning up some of the warts, immutability by default, having real modules etc. But I am not really impressed with its memory management thing. It's a bit tiresome to check stuff with valgrind, sure, but I don't have to worry about making cyclic data structures satisfy the borrow checker. I don't see the trade off as worth it.
- zerofan 10y ago
  To me it's almost the opposite. I like C a lot, but I ended up compromising on C++11 because in some programs I need more features to keep the implementation clean. I pay the cost of a messy language (C++) when implementing my libraries in order to have simpler applications that use those libraries. I've written C-like programs in Rust, and that goes very well. But I really like function overloading, generic operators that I can overload from the left and the right, integer parameters for my templates/generics, copy semantics as the default (opt-in for moves), placement new, explicit destructors, and maybe a few other niceties. Rust does none of these things the way I want, and so I'm stuck with C++. There are a few other things where I think Rust just made the wrong choices and didn't improve over C++. I've always hated the dichotomy in C++ strings between const char* pointers and an actual string class. Rust had the chance to make strings feel as comfortable as integers, but instead they introduced their own dichotomy with String and &str. Speaking of integers, Rust's choice of 32 bit integers as the default for literals is painful given that every machine most of us will ever care about is now 64 bit. I routinely deal with arrays and files that are too large for a 32 bit integer. This means I have to remember to suffix all of my integers in for loops etc... C++ has this wrong too (backwards compatibility), but Rust had a chance to make a clean start and did not.
  - gpderetta 10y ago
    > But I really like function overloading, generic operators that I can overload from the left and the right, integer parameters for my templates/generics, copy semantics as the default [etc.] I do too, and I'd like to think that rust needs all those things to be a replacement, but realistically I think that the only killer feature that rust is still missing is reasonable interoperability with C++ (which admittedly might require implementing a few of those features). Disclaimer: I have been following rust since Graydon initial announcement, but I have yet to write a single line of code in it.
    - akiselev 10y ago
      What do you mean by "reasonable?" There are several crates that provide inline C++ macros on both nightly (rustcxx) and stable (rust-cpp). I haven't used the latter but the former works really well (albeit using a gcc specific feature). I usually break out the C++ code into a wrapper (unless its a few lines) to make it more idiomatic Rust but at the end of the day, there aren't that many hoops to jump through.
zzzcpan 10y ago
Maybe Rust folks should make their own C backend for better integration with C compilers and have that portability, since LLVM folks decided to abandon theirs.
groovy2shoes 10y ago
C has also been relatively stable for the last 25 years or so. Rust changes every 6 weeks. Yes, the language is supposedly not undergoing breaking changes without strict deprecation and feature-gating. However, as new features are added to the language, libraries are usually updated to leverage them, and suddenly you are also forced to keep up with that rapid release cadence to ensure your project still builds. Meanwhile, C code from the mid-80s still compiles with modern compilers, often without any changes whatsoever, and without any feature gates. Don't get me wrong. I like Rust and what the project is trying to do. But I see two major problems that are preventing me from using it for anything major at the moment: 1) the extremely rapid rate of change, and 2) difficulty of implementation (both of which, taken together, lead me to expect no serious alternative implementations any time soon). Before I will be willing to adopt Rust as a C replacement in full, there needs to be a solid, stable language definition that compiler writers can target and programmers can rely on for a good chunk of time. I have a feeling we'll get there eventually once the number of new, useful features that are missing from the language starts to dwindle and it begins to stabilize naturally. In the meantime, I'd settle for an "LTS" release or something. That could work.
- steveklabnik 10y ago
  There's at least two alternate compilers I know of in the works. We'll see when they're in a workable state, or at least, enough to compile rustc. > In the meantime, I'd settle for an "LTS" release or something. That could work. This is something we've discussed. I imagine it will happen. At first, I would expect six month LTSes, then longer ones as time goes on.
  - groovy2shoes 10y ago
    I could definitely live with such a solution, but even six months might be too quick. So, as long as the plan is to lengthen the LTS window, I think that could work. The company that employs me just upgraded to a C++11-capable version of GCC three months ago. Even C++'s three year cadence seems like it might be too fast! Thing is, the company wants to vet our entire platform, which itself only changes yearly. They want to know they can get bug fixes, and vetting/upgrading the compiler is a lot of work regardless, so they tend to do one and stick with it for a while. OpenBSD does the same thing for security reasons. If Rust wants to replace C and/or C++, these are things that will need consideration eventually. I don't see my company allowing Rust any time soon, unfortunately. As a compiler-writer, I'm more concerned that Rust is a quickly-moving target at the moment. I think that as Rust becomes more mature, it will naturally begin to stabilize feature-wise, in which case something akin to the Haskell model would work well, with innovation happening in the flagship compiler and "snapshots" of the language being taken as standards periodically. That's just a matter of time, though.
pornel 10y ago
Because Rust is IMHO the first viable replacement for C. Well-written C programs translate almost 1:1 to Rust. It can do (roughly) everything C can, i.e. it's natively compiled, gives control of memory layout, and doesn't depend on a GC runtime. Previous C killers were either dependent on a fat runtime (which isn't a big problem in general, but is a problem for some of niches dominated by C), or didn't offer meaningful improvement in safety/concurrency/expressiveness.
- cderwin 10y ago
  On my system (2015 MBP running Ubuntu 16.04) Rust's hello world compiles to a nearly 3.5 MB executable. Compiling the equivalent C program with clang results in an executable under 9 KB. Rust may not have a GC, but its executables are certainly fat. Note: Rust executables can be trimmed down by stripping them (not done by default, even for release builds) and using libc malloc instead of jemalloc. But even then, C wins by a lot. Relevant blog post: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html#takeaway https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...
  - Manishearth 10y ago
    > But even then, C wins by a lot. C links dynamically to its libraries. Rust does not (by default). This overhead is a constant overhead so it rarely matters. When it does, you can strip it down further and get it to the same level as C. This is not evidence of a fat runtime, just a different default compilation strategy that prodces larger binary executables. jemalloc is (an optional) part of the runtime, but the rest isn't.
    - cderwin 10y ago
      Sure. It's not a fair comparison. But dynamically linking rust's std isn't an option. If you are optimizing for executable size, c wins because dynamically linking libc is possible. This is even true controlling for glibc, since most rust code also dynamically links glibc too (including hello world). In fact, rust's hello world has quite a few more shared dependencies than the equivalent c anyway: it uses libdl, librt, libpthread, and libgcc_s as well.
Manishearth 10y ago
Not everyone uses C only for the cases when they need a "small and portable language". C is used quite a bit in places where Rust or C++ would do fine too, for various reasons. That's where you want to compare them.
Ericson2314 10y ago
libc is very hard to use portably

I doubt that a significant amount of C programmers will switch to Rust. On the other hand, rust is very attractive for us C++ programmers.

Scuds 10y ago
Do you think we'll see major games having significant engine components being written in Rust?
- gpderetta 10y ago
  I don't work in that field, but I doubt game programmers will be early adopters of rust, as I think they mostly don't care about memory safety.
  - Crespyl 10y ago
    There's been some interest, but I think the likes of jblows Jai language that emphasize rapid development and programmer convenience over correctness will likely catch on faster.
- mmstick 10y ago
  DICE and others have been investigating and using it to create tools for developing games. There is interest in using it within game engines, but there's just the issue of Rust support for major consoles. There is great interest in the PC gaming world though that's not constrained by console support.
lacampbell 10y ago
I appreciate rust making a break from C++ and cleaning up some of the warts, immutability by default, having real modules etc. But I am not really impressed with its memory management thing. It's a bit tiresome to check stuff with valgrind, sure, but I don't have to worry about making cyclic data structures satisfy the borrow checker. I don't see the trade off as worth it.
zerofan 10y ago
To me it's almost the opposite. I like C a lot, but I ended up compromising on C++11 because in some programs I need more features to keep the implementation clean. I pay the cost of a messy language (C++) when implementing my libraries in order to have simpler applications that use those libraries. I've written C-like programs in Rust, and that goes very well. But I really like function overloading, generic operators that I can overload from the left and the right, integer parameters for my templates/generics, copy semantics as the default (opt-in for moves), placement new, explicit destructors, and maybe a few other niceties. Rust does none of these things the way I want, and so I'm stuck with C++. There are a few other things where I think Rust just made the wrong choices and didn't improve over C++. I've always hated the dichotomy in C++ strings between const char* pointers and an actual string class. Rust had the chance to make strings feel as comfortable as integers, but instead they introduced their own dichotomy with String and &str. Speaking of integers, Rust's choice of 32 bit integers as the default for literals is painful given that every machine most of us will ever care about is now 64 bit. I routinely deal with arrays and files that are too large for a 32 bit integer. This means I have to remember to suffix all of my integers in for loops etc... C++ has this wrong too (backwards compatibility), but Rust had a chance to make a clean start and did not.
- gpderetta 10y ago
  > But I really like function overloading, generic operators that I can overload from the left and the right, integer parameters for my templates/generics, copy semantics as the default [etc.] I do too, and I'd like to think that rust needs all those things to be a replacement, but realistically I think that the only killer feature that rust is still missing is reasonable interoperability with C++ (which admittedly might require implementing a few of those features). Disclaimer: I have been following rust since Graydon initial announcement, but I have yet to write a single line of code in it.
  - akiselev 10y ago
    What do you mean by "reasonable?" There are several crates that provide inline C++ macros on both nightly (rustcxx) and stable (rust-cpp). I haven't used the latter but the former works really well (albeit using a gcc specific feature). I usually break out the C++ code into a wrapper (unless its a few lines) to make it more idiomatic Rust but at the end of the day, there aren't that many hoops to jump through.

zzzcpan 10y ago

Maybe Rust folks should make their own C backend for better integration with C compilers and have that portability, since LLVM folks decided to abandon theirs.

groovy2shoes 10y ago

C has also been relatively stable for the last 25 years or so. Rust changes every 6 weeks. Yes, the language is supposedly not undergoing breaking changes without strict deprecation and feature-gating. However, as new features are added to the language, libraries are usually updated to leverage them, and suddenly you are also forced to keep up with that rapid release cadence to ensure your project still builds. Meanwhile, C code from the mid-80s still compiles with modern compilers, often without any changes whatsoever, and without any feature gates. Don't get me wrong. I like Rust and what the project is trying to do. But I see two major problems that are preventing me from using it for anything major at the moment: 1) the extremely rapid rate of change, and 2) difficulty of implementation (both of which, taken together, lead me to expect no serious alternative implementations any time soon). Before I will be willing to adopt Rust as a C replacement in full, there needs to be a solid, stable language definition that compiler writers can target and programmers can rely on for a good chunk of time. I have a feeling we'll get there eventually once the number of new, useful features that are missing from the language starts to dwindle and it begins to stabilize naturally. In the meantime, I'd settle for an "LTS" release or something. That could work.

steveklabnik 10y ago
There's at least two alternate compilers I know of in the works. We'll see when they're in a workable state, or at least, enough to compile rustc. > In the meantime, I'd settle for an "LTS" release or something. That could work. This is something we've discussed. I imagine it will happen. At first, I would expect six month LTSes, then longer ones as time goes on.
- groovy2shoes 10y ago
  I could definitely live with such a solution, but even six months might be too quick. So, as long as the plan is to lengthen the LTS window, I think that could work. The company that employs me just upgraded to a C++11-capable version of GCC three months ago. Even C++'s three year cadence seems like it might be too fast! Thing is, the company wants to vet our entire platform, which itself only changes yearly. They want to know they can get bug fixes, and vetting/upgrading the compiler is a lot of work regardless, so they tend to do one and stick with it for a while. OpenBSD does the same thing for security reasons. If Rust wants to replace C and/or C++, these are things that will need consideration eventually. I don't see my company allowing Rust any time soon, unfortunately. As a compiler-writer, I'm more concerned that Rust is a quickly-moving target at the moment. I think that as Rust becomes more mature, it will naturally begin to stabilize feature-wise, in which case something akin to the Haskell model would work well, with innovation happening in the flagship compiler and "snapshots" of the language being taken as standards periodically. That's just a matter of time, though.

pornel 10y ago

Because Rust is IMHO the first viable replacement for C. Well-written C programs translate almost 1:1 to Rust. It can do (roughly) everything C can, i.e. it's natively compiled, gives control of memory layout, and doesn't depend on a GC runtime. Previous C killers were either dependent on a fat runtime (which isn't a big problem in general, but is a problem for some of niches dominated by C), or didn't offer meaningful improvement in safety/concurrency/expressiveness.

cderwin 10y ago
On my system (2015 MBP running Ubuntu 16.04) Rust's hello world compiles to a nearly 3.5 MB executable. Compiling the equivalent C program with clang results in an executable under 9 KB. Rust may not have a GC, but its executables are certainly fat. Note: Rust executables can be trimmed down by stripping them (not done by default, even for release builds) and using libc malloc instead of jemalloc. But even then, C wins by a lot. Relevant blog post: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html#takeaway https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...
- Manishearth 10y ago
  > But even then, C wins by a lot. C links dynamically to its libraries. Rust does not (by default). This overhead is a constant overhead so it rarely matters. When it does, you can strip it down further and get it to the same level as C. This is not evidence of a fat runtime, just a different default compilation strategy that prodces larger binary executables. jemalloc is (an optional) part of the runtime, but the rest isn't.
  - cderwin 10y ago
    Sure. It's not a fair comparison. But dynamically linking rust's std isn't an option. If you are optimizing for executable size, c wins because dynamically linking libc is possible. This is even true controlling for glibc, since most rust code also dynamically links glibc too (including hello world). In fact, rust's hello world has quite a few more shared dependencies than the equivalent c anyway: it uses libdl, librt, libpthread, and libgcc_s as well.

Manishearth 10y ago

Not everyone uses C only for the cases when they need a "small and portable language". C is used quite a bit in places where Rust or C++ would do fine too, for various reasons. That's where you want to compare them.

Ericson2314 10y ago

libc is very hard to use portably