7 ms·

I truly appreciate that this team uses nightly rust and only runs only Linux currently (due to relying on io_uring). Truly in the spirit of systems programming

I truly appreciate that this team uses nightly rust and only runs only Linux currently (due to relying on io_uring). Truly in the spirit of systems programming - focusing on a single, tight, efficient implementation first and leaving other considerations such as cross-platform compatibility for later. Lets those of us who love to live on the bleeding edge have our nice things too! :)

MuffinFlavored 5y ago
> for later or for never :P why not prove like... "this is the best. all other platforms/circumstances/situations are subpar" if the performance differences are enough, i can picture people making excuses to avoid all of those other platforms (or just never using this... more likely)
- staticassertion 5y ago
  Agreed. I wouldn't care if Rust dropped Windows/ OSX support entirely. Totally niche platforms.
  - aneutron 5y ago
    I think you're being sarcastic, but I'm not totally sure.
    - staticassertion 5y ago
      I'm honestly not. Desktop platforms like Windows are incredibly niche. How much rust software actually runs on those? Some, of course. But probably an incredible minority. Supporting them is smart because people expect it, and not supporting it would be bad optics, but if a language legitimately only targeted Linux, and was better for it, I'd be fine with that - they target the most popular OS by far.
      - jsty 5y ago
        > How much rust software actually runs on those? Some of rust's most well-known and widely distributed success stories for a start - Firefox & Dropbox
        staticassertion 5y ago
        Yeah, obviously. It would be stupid to not support Windows in order for rust to be a healthy language. But I wouldn't care at all, and the vast majority of code - not just the code written, but in terms of it being deployed to N systems - will be Linux.
      - steveklabnik 5y ago
        I am a Windows user, so all of the Rust software I use runs on it. And that’s virtually all Rust software. Sometimes you need a small patch or two because someone did something weird with path handling, but 99.99% of it Just Works. Apparently we haven't published platform statistics since 2019, but according to that years' survey: https://blog.rust-lang.org/images/2020-03-RustSurvey/32-what-platform-developing-on.svg https://blog.rust-lang.org/images/2020-03-RustSurvey/32-what... * 55% of Rust users develop on Linux * 24% develop on Windows * 23% develop on macOS So yeah Linux was the most popular, but dropping effectively half of your users isn't always a great idea. Of course, some people will build OS-specific software in Rust, and that's great! But it is a tradeoff you're making.
        seg_lol 5y ago
        Neat! Thanks for admitting you use Windows. Perhaps MS could pay for crater runs on Windows? Are crater runs done on Windows now? Looks like yes, https://github.com/rust-lang/crater/blob/master/docs/agent-machine-setup-windows.md https://github.com/rust-lang/crater/blob/master/docs/agent-m...
        steveklabnik 5y ago
        Not just that, but like, https://github.com/microsoft/windows-rs https://github.com/microsoft/windows-rs. Microsoft is a member of the Rust Foundation. etc etc.
  - tele_ski 5y ago
    As much as I like deving only on Linux, this I'm pretty sure would be awful for rust's continued adoption.
threeseed 5y ago
io_uring is coming to Windows: https://twitter.com/axboe/status/1396837335141134336 https://twitter.com/axboe/status/1396837335141134336
- Arnavion 5y ago
  Following that through to the blog post ([1]), it's interesting how much new API they had to add. The Windows IO API is already completion-style (as opposed to epoll, etc's readiness-style) - userspace submits an async operation to the kernel, blocks on a channel to receive its result, and the kernel enqueues the result to said channel when it's done. So I naively assumed that they'd "just" have to refit io_uring's API on top of the existing Win32 API. [1]: https://windows-internals.com/i-o-rings-when-one-i-o-operation-is-not-enough/ https://windows-internals.com/i-o-rings-when-one-i-o-operati...
  - formerly_proven 5y ago
    uring is used for disk-IO as well, and Windows disk I/O completion has similar limitations as Linux aio does for disks, i.e. anything that actually goes into filesystem code, like allocating new blocks, creating files, anything involving metadata, still blocks. Readiness-oriented I/O of course doesn't work for disk I/O at all, because disks are always ready. And IOCPs still mean that for queuing new I/O you're going to call into the kernel at least once for each operation.

MuffinFlavored 5y ago

> for later or for never :P why not prove like... "this is the best. all other platforms/circumstances/situations are subpar" if the performance differences are enough, i can picture people making excuses to avoid all of those other platforms (or just never using this... more likely)

staticassertion 5y ago
Agreed. I wouldn't care if Rust dropped Windows/ OSX support entirely. Totally niche platforms.
- aneutron 5y ago
  I think you're being sarcastic, but I'm not totally sure.
  - staticassertion 5y ago
    I'm honestly not. Desktop platforms like Windows are incredibly niche. How much rust software actually runs on those? Some, of course. But probably an incredible minority. Supporting them is smart because people expect it, and not supporting it would be bad optics, but if a language legitimately only targeted Linux, and was better for it, I'd be fine with that - they target the most popular OS by far.
    - jsty 5y ago
      > How much rust software actually runs on those? Some of rust's most well-known and widely distributed success stories for a start - Firefox & Dropbox
      - staticassertion 5y ago
        Yeah, obviously. It would be stupid to not support Windows in order for rust to be a healthy language. But I wouldn't care at all, and the vast majority of code - not just the code written, but in terms of it being deployed to N systems - will be Linux.
    - steveklabnik 5y ago
      I am a Windows user, so all of the Rust software I use runs on it. And that’s virtually all Rust software. Sometimes you need a small patch or two because someone did something weird with path handling, but 99.99% of it Just Works. Apparently we haven't published platform statistics since 2019, but according to that years' survey: https://blog.rust-lang.org/images/2020-03-RustSurvey/32-what-platform-developing-on.svg https://blog.rust-lang.org/images/2020-03-RustSurvey/32-what... * 55% of Rust users develop on Linux * 24% develop on Windows * 23% develop on macOS So yeah Linux was the most popular, but dropping effectively half of your users isn't always a great idea. Of course, some people will build OS-specific software in Rust, and that's great! But it is a tradeoff you're making.
      - seg_lol 5y ago
        Neat! Thanks for admitting you use Windows. Perhaps MS could pay for crater runs on Windows? Are crater runs done on Windows now? Looks like yes, https://github.com/rust-lang/crater/blob/master/docs/agent-machine-setup-windows.md https://github.com/rust-lang/crater/blob/master/docs/agent-m...
        steveklabnik 5y ago
        Not just that, but like, https://github.com/microsoft/windows-rs https://github.com/microsoft/windows-rs. Microsoft is a member of the Rust Foundation. etc etc.
- tele_ski 5y ago
  As much as I like deving only on Linux, this I'm pretty sure would be awful for rust's continued adoption.

threeseed 5y ago

io_uring is coming to Windows: https://twitter.com/axboe/status/1396837335141134336 https://twitter.com/axboe/status/1396837335141134336

Arnavion 5y ago
Following that through to the blog post ([1]), it's interesting how much new API they had to add. The Windows IO API is already completion-style (as opposed to epoll, etc's readiness-style) - userspace submits an async operation to the kernel, blocks on a channel to receive its result, and the kernel enqueues the result to said channel when it's done. So I naively assumed that they'd "just" have to refit io_uring's API on top of the existing Win32 API. [1]: https://windows-internals.com/i-o-rings-when-one-i-o-operation-is-not-enough/ https://windows-internals.com/i-o-rings-when-one-i-o-operati...
- formerly_proven 5y ago
  uring is used for disk-IO as well, and Windows disk I/O completion has similar limitations as Linux aio does for disks, i.e. anything that actually goes into filesystem code, like allocating new blocks, creating files, anything involving metadata, still blocks. Readiness-oriented I/O of course doesn't work for disk I/O at all, because disks are always ready. And IOCPs still mean that for queuing new I/O you're going to call into the kernel at least once for each operation.