6 ms·

There are several comments on the value of having this project be "pure rust". Based on my experience, the main value is that it makes this code easily portabl

There are several comments on the value of having this project be "pure rust". Based on my experience, the main value is that it makes this code easily portable. Meaning, if you can compile rust on your device, you can just run this code without worrying about also installing and appropriately linking the correct version of some C library. It's a huge convenience. Of course, this only works if all dependencies are also pure Rust. I haven't verified that this is the case here. Here's hoping!

amelius 6y ago
I think that ANSI-C is a lot more portable than Rust, to be honest.
- steveklabnik 6y ago
  It depends on what exactly you mean by "portable." This is an extremely complicated space with a ton of interlocking dependencies, but here are two axes on which you could make opposite claims, and be correct: * C is more portable than Rust because there are C compilers available for more platforms than there are Rust compilers for Rust platforms. * Rust is more portable than C because Rust programs tend to be written in a more platform agnostic way, and are therefore more likely to be able to work on platforms that they weren't originally intended for. (To make the second point more concrete, as a Windows user, pure Rust programs almost always Just Work for me, but as soon as we get into C dependencies, it becomes way, way way worse.)
  - kazinator 6y ago
    No, no, ... Turbo Pascal is what is more portable than C. Proof: just look at graphics. You just write your graphics code in a platform-independent way and use the correct .BGI file for your graphics hardware. And it's safe: no pointer arithmetic or void; real array passing. Module system for dependencies. No makefiles needed. No problem of linking a stale object file that didn't get rebuilt due to a missing dependency rule. Turbo Pascal is the golden future, my friends.
- bluejekyll 6y ago
  I find in Rust I have far fewer platform specific switches with #[cfg(Unix)] and the like vs. the number of #ifdef macros in C. If you’re talking about code portability of pure C, no dependencies, then I agree. Once you start depending on platform features, in my experience, the portability of Rust is superior.
  - kazinator 6y ago
    The problem is that this requires the Rust run-time to be a ball of mud that provides everything for everyone. Where is the Rust compiler for a Motorola 68K? How about PIC24? And if there is ever a Rust compiler for PIC24, what will happen to all that run-time support? How much of it will work? How will you detect what of it works and what doesn't, in order to work around for it in your program?
    - steveklabnik 6y ago
      Rust has barely more of a runtime than C. And if you're not using the standard library, it has the same amount. Someone was working on a 68k port. I am not sure what its status is today. PIC24 should be totally possible; we have AVR support in nightly now, which is also a 16 bit platform.
      - kazinator 6y ago
        Yet, it was claimed in the grandparent, that "Once you start depending on platform features, in my experience, the portability of Rust is superior" (because of no #ifdef crud and library versions and whatnot). Maybe what it really means is that "once you start depending on platform features, the portability of Rust to a handful of mainstream platforms which have all those features in slightly varying flavors is cleaner due to some layering". You don't have annoyances like, oh, foo_t requires <sys/types.h> on this platform, but on that other one it was already exposed in <stdlib.h>.
        bluejekyll 6y ago
        I thought that was implied by the statement I made about C without dependencies being more portable. In any case. You’re not wrong. We can caveat everything about Rust as “for the platforms it supports”, and in this context it is more enjoyable to work with across those platforms. And for all of my development needs, it targets everything I work with. C is more portable as a language, but that's never been up for debate.
- dhbradshaw 6y ago
  This is beside the point I was trying to make. The point is that Pure Rust > Rust + Non-Rust dependencies in the sense that it's easier to compile, cross compile, install, or deploy. If it's pure rust, then I don't have to worry about dynamic or even static linking. I just compile the code for the target and I'm done. Cross compiling becomes simple. Installing becomes simple. I'm repeating myself a bit here but just to clarify: there's no question that pure C is awesome for portability. And like with Rust it becomes less fun once dynamic linking gets involved.
- garmaine 6y ago
  Only if you have no dependencies and interact in no way with any platform-specified services. Now certainly there are platform-specific things with Rust as well, but the defaults are structured in such a way that exposed APIs are more likely than not to be platform independent--you have to go out of your way to break compatibility, rather than it being the default. And once you get your binary to compile, the static linking means there isn't runtime dependencies that might break either. The net result is that given a piece of rust code, it is far more likely than its C equivalent to compile on a new platform. And once it does compile, it can be run in any context without concern for differences in the runtime environment. The Rust compiler may target fewer platforms, and therefore be "less portable" in that sense, but if it is a supported backend then it is going to be easier to get the code working.
  - kazinator 6y ago
    Static linking means that if a security flaw is found in a dependent component, you're responsible for shipping a whole new application binary to the end users; they can't just pick up some new shared libs from upstream of you.
    - pdimitar 6y ago
      This goes both ways: if an embarrassing security vulnerability is found in a system library, your users will be safe due to static linking. Both sides are fair points and it depends on a plethora of other factors which should be chosen for any given project.
ddevault 6y ago
The idea that Rust is more portable than C is laughable. C is the most portable language of all time, and Rust has a long way to go to compete. Git already runs on more platforms than Rust can target.
- mwcampbell 6y ago
  It's true that the C language is available on more platforms, including more exotic platforms, than Rust, and that will probably remain true for quite a while. But in another sense, Rust tends to be more portable in practice. Take a random, non-trivial C program or library and try to compile it for something that's not a Unix (edit: or cross-compile it). How hard is it to do? Now, do the same with a random Rust crate. It's probably a lot easier. I think there are two key differences. First, Rust has a standard build system (Cargo) that is dominant, while there are many competing build systems for C. Second, the Rust standard library was designed much more recently, and covers far more of the functionality in today's platforms than the C standard library does. (For example, contrast Rust's OsStr and Path types with the pain of supporting Unicode filenames on both Unix and Windows in C.)
  - camgunz 6y ago
    I think this is a good point, but I think you're mostly talking about building rather than porting. It's way more likely you'll be able to port something from a popular architecture to an obscure one in C because the lingua franca is C, and shipping an architecture generally means shipping C compiler support for it. I would guess this will slowly change as LLVM gets more backends, but that's pretty hand-wavy. The other option is we move more towards platform monoculture, which is probably more likely? Not sure.
    - steveklabnik 6y ago
      (Another option is a gcc frontend for Rust, which the gcc folks have said that they're not opposed to)
      - 6y ago

amelius 6y ago

I think that ANSI-C is a lot more portable than Rust, to be honest.

steveklabnik 6y ago
It depends on what exactly you mean by "portable." This is an extremely complicated space with a ton of interlocking dependencies, but here are two axes on which you could make opposite claims, and be correct: * C is more portable than Rust because there are C compilers available for more platforms than there are Rust compilers for Rust platforms. * Rust is more portable than C because Rust programs tend to be written in a more platform agnostic way, and are therefore more likely to be able to work on platforms that they weren't originally intended for. (To make the second point more concrete, as a Windows user, pure Rust programs almost always Just Work for me, but as soon as we get into C dependencies, it becomes way, way way worse.)
- kazinator 6y ago
  No, no, ... Turbo Pascal is what is more portable than C. Proof: just look at graphics. You just write your graphics code in a platform-independent way and use the correct .BGI file for your graphics hardware. And it's safe: no pointer arithmetic or void; real array passing. Module system for dependencies. No makefiles needed. No problem of linking a stale object file that didn't get rebuilt due to a missing dependency rule. Turbo Pascal is the golden future, my friends.
bluejekyll 6y ago
I find in Rust I have far fewer platform specific switches with #[cfg(Unix)] and the like vs. the number of #ifdef macros in C. If you’re talking about code portability of pure C, no dependencies, then I agree. Once you start depending on platform features, in my experience, the portability of Rust is superior.
- kazinator 6y ago
  The problem is that this requires the Rust run-time to be a ball of mud that provides everything for everyone. Where is the Rust compiler for a Motorola 68K? How about PIC24? And if there is ever a Rust compiler for PIC24, what will happen to all that run-time support? How much of it will work? How will you detect what of it works and what doesn't, in order to work around for it in your program?
  - steveklabnik 6y ago
    Rust has barely more of a runtime than C. And if you're not using the standard library, it has the same amount. Someone was working on a 68k port. I am not sure what its status is today. PIC24 should be totally possible; we have AVR support in nightly now, which is also a 16 bit platform.
    - kazinator 6y ago
      Yet, it was claimed in the grandparent, that "Once you start depending on platform features, in my experience, the portability of Rust is superior" (because of no #ifdef crud and library versions and whatnot). Maybe what it really means is that "once you start depending on platform features, the portability of Rust to a handful of mainstream platforms which have all those features in slightly varying flavors is cleaner due to some layering". You don't have annoyances like, oh, foo_t requires <sys/types.h> on this platform, but on that other one it was already exposed in <stdlib.h>.
      - bluejekyll 6y ago
        I thought that was implied by the statement I made about C without dependencies being more portable. In any case. You’re not wrong. We can caveat everything about Rust as “for the platforms it supports”, and in this context it is more enjoyable to work with across those platforms. And for all of my development needs, it targets everything I work with. C is more portable as a language, but that's never been up for debate.
dhbradshaw 6y ago
This is beside the point I was trying to make. The point is that Pure Rust > Rust + Non-Rust dependencies in the sense that it's easier to compile, cross compile, install, or deploy. If it's pure rust, then I don't have to worry about dynamic or even static linking. I just compile the code for the target and I'm done. Cross compiling becomes simple. Installing becomes simple. I'm repeating myself a bit here but just to clarify: there's no question that pure C is awesome for portability. And like with Rust it becomes less fun once dynamic linking gets involved.
garmaine 6y ago
Only if you have no dependencies and interact in no way with any platform-specified services. Now certainly there are platform-specific things with Rust as well, but the defaults are structured in such a way that exposed APIs are more likely than not to be platform independent--you have to go out of your way to break compatibility, rather than it being the default. And once you get your binary to compile, the static linking means there isn't runtime dependencies that might break either. The net result is that given a piece of rust code, it is far more likely than its C equivalent to compile on a new platform. And once it does compile, it can be run in any context without concern for differences in the runtime environment. The Rust compiler may target fewer platforms, and therefore be "less portable" in that sense, but if it is a supported backend then it is going to be easier to get the code working.
- kazinator 6y ago
  Static linking means that if a security flaw is found in a dependent component, you're responsible for shipping a whole new application binary to the end users; they can't just pick up some new shared libs from upstream of you.
  - pdimitar 6y ago
    This goes both ways: if an embarrassing security vulnerability is found in a system library, your users will be safe due to static linking. Both sides are fair points and it depends on a plethora of other factors which should be chosen for any given project.

ddevault 6y ago

The idea that Rust is more portable than C is laughable. C is the most portable language of all time, and Rust has a long way to go to compete. Git already runs on more platforms than Rust can target.

mwcampbell 6y ago
It's true that the C language is available on more platforms, including more exotic platforms, than Rust, and that will probably remain true for quite a while. But in another sense, Rust tends to be more portable in practice. Take a random, non-trivial C program or library and try to compile it for something that's not a Unix (edit: or cross-compile it). How hard is it to do? Now, do the same with a random Rust crate. It's probably a lot easier. I think there are two key differences. First, Rust has a standard build system (Cargo) that is dominant, while there are many competing build systems for C. Second, the Rust standard library was designed much more recently, and covers far more of the functionality in today's platforms than the C standard library does. (For example, contrast Rust's OsStr and Path types with the pain of supporting Unicode filenames on both Unix and Windows in C.)
- camgunz 6y ago
  I think this is a good point, but I think you're mostly talking about building rather than porting. It's way more likely you'll be able to port something from a popular architecture to an obscure one in C because the lingua franca is C, and shipping an architecture generally means shipping C compiler support for it. I would guess this will slowly change as LLVM gets more backends, but that's pretty hand-wavy. The other option is we move more towards platform monoculture, which is probably more likely? Not sure.
  - steveklabnik 6y ago
    (Another option is a gcc frontend for Rust, which the gcc folks have said that they're not opposed to)
    - 6y ago