3 ms·

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 po

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.
      - kazinator 6y ago
        For suitable values of someone, Visual Basic embedded in Excel targets everything someone works with and they are happy. In C there are also portability libraries. So for instance, suppose you want to do asynchronous I/O with sockets on a few contemporary platforms. You could do all the hard work and make it work with kevent on BSD, epoll_wait there, or I/O completion ports on Windows, with some select and poll based fallback cases. Or you could just use, whatsitcalled, ... libuv and follow its API. Libuv has the grotty multiple implementations of the same thing in three or four ways, and ifdefs and whatever, so you don't have to. Then you're into problems like: do you build libuv yourself and ship that? Or do you rely on the upstream one available in some of your target platforms, and which version will that be, and will that cause issues. It's going to be dynamically linked, so users can run with a different version than what you tested with as they update their systems. But that's just due to having more choices. If libuv weren't widely adopted, then that would be easier: there is no platform version of libuv. You want it, you build it yourself. You choose the version, pin to that, and you control if/when you update. All that complexity is from more independent parties being at the table. It's not just you, Developer versus some Mother Ship (language that provides everything, including platform stuff).
        bluejekyll 6y ago
        What is your point here? We all know that C is portable and has many libraries that support that. The statement is that Rust is in the opinion of many of us that have experience with porting both languages to multiple platforms, that Rust is easier. mio is the portable library many use in Rust for IO across multiple platforms, it's used by Tokio and other async frameworks to support async-io. And, yes, if something doesn't exist you must build the support for it. This is true for anything? It feels like you're trying to change the goal posts on the discussion, to be one of library support now. But luckily in Rust, we have bindgen that makes it relatively painless to support C libraries when you want the "easy" path to getting libraries that are implemented there, but not yet in Rust.

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.
    - kazinator 6y ago
      For suitable values of someone, Visual Basic embedded in Excel targets everything someone works with and they are happy. In C there are also portability libraries. So for instance, suppose you want to do asynchronous I/O with sockets on a few contemporary platforms. You could do all the hard work and make it work with kevent on BSD, epoll_wait there, or I/O completion ports on Windows, with some select and poll based fallback cases. Or you could just use, whatsitcalled, ... libuv and follow its API. Libuv has the grotty multiple implementations of the same thing in three or four ways, and ifdefs and whatever, so you don't have to. Then you're into problems like: do you build libuv yourself and ship that? Or do you rely on the upstream one available in some of your target platforms, and which version will that be, and will that cause issues. It's going to be dynamically linked, so users can run with a different version than what you tested with as they update their systems. But that's just due to having more choices. If libuv weren't widely adopted, then that would be easier: there is no platform version of libuv. You want it, you build it yourself. You choose the version, pin to that, and you control if/when you update. All that complexity is from more independent parties being at the table. It's not just you, Developer versus some Mother Ship (language that provides everything, including platform stuff).
      - bluejekyll 6y ago
        What is your point here? We all know that C is portable and has many libraries that support that. The statement is that Rust is in the opinion of many of us that have experience with porting both languages to multiple platforms, that Rust is easier. mio is the portable library many use in Rust for IO across multiple platforms, it's used by Tokio and other async frameworks to support async-io. And, yes, if something doesn't exist you must build the support for it. This is true for anything? It feels like you're trying to change the goal posts on the discussion, to be one of library support now. But luckily in Rust, we have bindgen that makes it relatively painless to support C libraries when you want the "easy" path to getting libraries that are implemented there, but not yet in Rust.