> [...] it's not even 1.0 yet. Thus, it isn't stable enough for production use.
API stability (i.e. how the API will change in future) is largely unrelated to the question of whether you can trust it to work in production.
Maybe for some people API stability is a "must have" for production use, for the sake of minimizing churn when upgrading dependencies, but that's far from a universal principal.
I think people often get confused about different meanings of "stable". I've worked with plenty of libraries with stable APIs that are buggy piles of hacks. And I've worked with plenty of libraries with unstable APIs that are rock-solid in production. They're different concerns, but people seem to conflate them a lot.
So, to clarify, any statement like "not even 1.0 [...] isn't stable enough for production use", made without qualification, is a non sequitur.
Well I guess I have to expand the symbols for you, here we go:
No api stability heuristically imply no production readiness does not imply that api stability imply production readiness.
As you snarkily imply, the contrapositive should be common sense and not need to be stated. Yet your brain failed to see that your comment on gets() is exactly such a needless truism.
"not even 1.0 [...] isn't stable enough for production use"
This reasoning is as many others a probabilistic one but it make sense.
Being production ready (technically everything can be with enough churn, and duplicate work production) here means that it is at least decently competitive with others offering regarding productivity, performance and feature completeness, translation: you won't get fired/risk your product by choosing this lib for production use on a medium scale project.
If we agree on the definition, then it generally follow that being productive (e.g ergonomic API), optimised (polishing work), not having rough edges, and having implemented the many required features (a server framework actually require a LOT) all those steps are done AFTER the foundational work of pre 1.0
Those after work will probably sometimes break API stability as we are not omniscient and forward compatibility is non trivial hence the needs for production ready frameworks to have had many breaking change releases so more like 3.x than 1.x
Hence, it follows that the temporary but general API stability guarantees from a 1.0 are insufficient and general means that is can begin to be used, not that it should be used.
Rocket and any other rust server framework are not production ready as soon as you go beyond trivial use cases.they have dangerous foundational bugs and show stopper missing features.
I have built a startup product with actix web (but studied rocket too) and those are dangerous economic bombs.
The Rust ecosystem typically has much more conservative version numbers than other ecosystems though, and higher quality standards. There are several very high quality crates with 0.x version numbers.
A fairer statement might be that the rust ecosystem has inconsistent version numbers. I've seen both flawless v.14s and awful v.7s. There are a few ways to figure out the difference like sorting by downloads on crates.io to find packages that are commonly used.
There is a curious parallel to the rise of Go which had no versions in their ecosystem as the language was adopted.
One could argue that if you are relying on magic number schemas to decide if a library is stable enough for your usecase, it is you that is doing it wrong.
It's no longer magic number once you follow semver
https://semver.org
Of course it only offer limited information but this information can tell you whether you should be not confident in it. Pre 1.0 is such a signal.
> [...] it's not even 1.0 yet. Thus, it isn't stable enough for production use.
API stability (i.e. how the API will change in future) is largely unrelated to the question of whether you can trust it to work in production.
Maybe for some people API stability is a "must have" for production use, for the sake of minimizing churn when upgrading dependencies, but that's far from a universal principal.
I think people often get confused about different meanings of "stable". I've worked with plenty of libraries with stable APIs that are buggy piles of hacks. And I've worked with plenty of libraries with unstable APIs that are rock-solid in production. They're different concerns, but people seem to conflate them a lot.
So, to clarify, any statement like "not even 1.0 [...] isn't stable enough for production use", made without qualification, is a non sequitur.