[jeffparsons]

I think you're missing the point of contention.

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

[kazinator]

> plenty of libraries with stable APIs that are buggy piles of hacks.

E.g. the API:

   char *gets(char *s);

has not changed in probably forty years. Rock stable!

[The_rationalist]

Not A imply not B, does not imply that A imply B.

[kazinator]

Nobody on the internet but you knows about the contrapositive; but you can fix that!

[The_rationalist]

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.

[The_rationalist]

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