5 ms·

Rust has had https://github.com/carllerche/mio https://github.com/carllerche/mio for two years now, longer than Rust itself has been stable. tokio is just a hig

Rust has had https://github.com/carllerche/mio https://github.com/carllerche/mio for two years now, longer than Rust itself has been stable. tokio is just a higher-level, nicer, API. ESR knows this. It was there in the comments of his previous issue. Yet he chooses to link to a two-year old issue with one comment that says that Rust doesn't have epoll as a source of truth. Mio can't compare to the baked-in goroutine goodies (neither can epoll in C!), but this blog post is outright dishonest.

bjourne 10y ago
mio is currently at version 0.6.2. A version number with a leading zero usually indicates that the authors of the software deem it to be of alpha or beta quality. It's api has also significantly evolved in a backwards incompatible manner recently: https://www.reddit.com/r/rust/comments/50srx0/mio_api_has_changed_substantially/ https://www.reddit.com/r/rust/comments/50srx0/mio_api_has_ch... Again, not taking a dump on mio because its authors are doing the right thing. 0.x means bugs and api breaks are to be expected. Use the software at your own risk. Basing an ntp server on it might not be appropriate (atm).
- Manishearth 10y ago
  Right, mio isn't marked stable yet, and is changing the API (mostly for tokio), but the project is mature in the sense that you wouldn't expect many bugs in it, and you can pin to a version and just use that for a while if you are worried about API stability. But yes, the async I/O space in Rust isn't amazing. But it's not as bad a picture as he paints.
  - Sanddancer 10y ago
    Yes, you could, but then you run into the potential problem where dependency A uses version 0.6.x, but dependency B starts using 0.7.x, because there's no stability. It becomes an increasing maintenance nightmare, where every dependency adds new potential headaches because no one's willing to create a version that's supported for more than a few months. Async I/O is as bad as he paints it because every component that you can use isn't stable and has no plans toward stability.
    - Manishearth 10y ago
      Yeah, I'm aware that's a problem, but it's not a dealbreaking one usually IMO. Especially for libraries like mio and tokio with buy-in from the whole I/O side of the ecosystem.
  - bjourne 10y ago
    Why wouldn't I expect many bugs in it? The 0.x version number implies exactly that! In this matter, I'd rather trust the mio developers themselves than you. By holding the version number at 0.x they are saying "stay away unless you like to tinker". I.e "Don't base your ntpd software on this library" Pinning a version number is a hack. Not something you should rely on for long-term stability.
    - Manishearth 10y ago
      So the Rust community in general is pretty reluctant to move crates to 1.0, even when stable/bugfree. This is a problem, and is slowly improving, but that's currently the case. 0.x can mean "Not stable" and it can also mean "buggy", it need not mean both. Regardless of how bug-free the authors consider it to be, they won't mark it 1.0 until they think that they're happy with the API. IIRC they're waiting for tokio to be finished and for it to sit for a while to ensure the API is the right one, so it should be relatively free from bugs. > Pinning a version number is a hack. Not something you should rely on for long-term stability. Agreed. I'm saying that this shouldn't be a dealbreaker. It's usually very little work to upgrade to the latest version of a library. Basically, mio's stability is a problem. Totally agree with that. But it's not as bad a picture as the article paints.
      - bjourne 10y ago
        > So the Rust community in general is pretty reluctant to move crates to 1.0, even when stable/bugfree. This is a problem, and is slowly improving, but that's currently the case. Keeping a package at 0.x means (to paraphrase) "I don't take responsibility. The code may or may not work and if it doesn't, then don't complain." (a) Putting it at 1.x means (to paraphrase) "I (the author) will at least respond to bug reports. I might even try to fix them if I have the time." (b) Free software authors have this choice. > so it should be relatively free from bugs. And if it isn't? For example, I looked at the tracker and found a number of open bugs which looked troublesome for the Windows backend. I think you are doing the mio project a disservice by promising more than the developers themselves have said that they are willing to deliver.

bjourne 10y ago

mio is currently at version 0.6.2. A version number with a leading zero usually indicates that the authors of the software deem it to be of alpha or beta quality. It's api has also significantly evolved in a backwards incompatible manner recently: https://www.reddit.com/r/rust/comments/50srx0/mio_api_has_changed_substantially/ https://www.reddit.com/r/rust/comments/50srx0/mio_api_has_ch... Again, not taking a dump on mio because its authors are doing the right thing. 0.x means bugs and api breaks are to be expected. Use the software at your own risk. Basing an ntp server on it might not be appropriate (atm).

Manishearth 10y ago
Right, mio isn't marked stable yet, and is changing the API (mostly for tokio), but the project is mature in the sense that you wouldn't expect many bugs in it, and you can pin to a version and just use that for a while if you are worried about API stability. But yes, the async I/O space in Rust isn't amazing. But it's not as bad a picture as he paints.
- Sanddancer 10y ago
  Yes, you could, but then you run into the potential problem where dependency A uses version 0.6.x, but dependency B starts using 0.7.x, because there's no stability. It becomes an increasing maintenance nightmare, where every dependency adds new potential headaches because no one's willing to create a version that's supported for more than a few months. Async I/O is as bad as he paints it because every component that you can use isn't stable and has no plans toward stability.
  - Manishearth 10y ago
    Yeah, I'm aware that's a problem, but it's not a dealbreaking one usually IMO. Especially for libraries like mio and tokio with buy-in from the whole I/O side of the ecosystem.
- bjourne 10y ago
  Why wouldn't I expect many bugs in it? The 0.x version number implies exactly that! In this matter, I'd rather trust the mio developers themselves than you. By holding the version number at 0.x they are saying "stay away unless you like to tinker". I.e "Don't base your ntpd software on this library" Pinning a version number is a hack. Not something you should rely on for long-term stability.
  - Manishearth 10y ago
    So the Rust community in general is pretty reluctant to move crates to 1.0, even when stable/bugfree. This is a problem, and is slowly improving, but that's currently the case. 0.x can mean "Not stable" and it can also mean "buggy", it need not mean both. Regardless of how bug-free the authors consider it to be, they won't mark it 1.0 until they think that they're happy with the API. IIRC they're waiting for tokio to be finished and for it to sit for a while to ensure the API is the right one, so it should be relatively free from bugs. > Pinning a version number is a hack. Not something you should rely on for long-term stability. Agreed. I'm saying that this shouldn't be a dealbreaker. It's usually very little work to upgrade to the latest version of a library. Basically, mio's stability is a problem. Totally agree with that. But it's not as bad a picture as the article paints.
    - bjourne 10y ago
      > So the Rust community in general is pretty reluctant to move crates to 1.0, even when stable/bugfree. This is a problem, and is slowly improving, but that's currently the case. Keeping a package at 0.x means (to paraphrase) "I don't take responsibility. The code may or may not work and if it doesn't, then don't complain." (a) Putting it at 1.x means (to paraphrase) "I (the author) will at least respond to bug reports. I might even try to fix them if I have the time." (b) Free software authors have this choice. > so it should be relatively free from bugs. And if it isn't? For example, I looked at the tracker and found a number of open bugs which looked troublesome for the Windows backend. I think you are doing the mio project a disservice by promising more than the developers themselves have said that they are willing to deliver.