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>.
I mean, rust does have the equivalent of #ifdef. There are platform-specific things.
It's just that, with the benefit of hindsight, we designed support in three major layers:
* core, which only relies on there being like, a symbol for memcpy
* alloc, which gives you a heap
* std, which gives you operating system-dependent features
Based on this hierarchy, a lot of libraries that are OS dependent may use only core, or core + alloc. And way more crates do this than you might think, and it's pretty easy to move a crate to them if they truly don't need all that libstd has to offer.
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.
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).
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.
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>.