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.

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.

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.

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.

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.

> 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.

Yes, and while that's what 0.x usually means, in the Rust community (and in other communities) it's usually more complicated than that. For mio in particular it's been a crate that a lot of folks have been using and it's been working fine. I'm not saying that that's the message that the version number broadcasts. You're totally right that it broadcasts a message that the crate is immature. I'm saying that the actual situation is not as bad as it sounds.

Fair point about the bugs :) I wasn't aware of them, and I've only heard really good things about mio.

Being 0.x could also just mean "we're not 100% certain we don't want to change any API" yet. Semver is about stability guarantees (promises), bugs is somewhat independent for a widely used and well-maintained library.

I can't find support for that interpretation in the Semantic Versioning spec: "Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable."

That means 0.x software is in "initial development" implying no guarantee on how many bugs it can contain and no guarantees regarding maintainership. Other parts of the spec deals with backwards-incompatible api changes.

I know where your interpretation comes from. It comes from users of software who believe that a 0.x version can be relied upon. Because it works for them and they haven't found any bugs. Software publishers on the other hand, never makes that claim and users to whom stability is important should stay away from 0.x software.

Agreed that the publishers don't make that claim. However, I know that many publishers are hesitant to go 1.0. Not because they think there are too many bugs, but because they are afraid of committing to not changing the API.

Note that there is nothing at all in the semver spec about bugs.