7 ms·

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 ab

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

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.