Hacker News Reader

Comment by trait | Hacker News Reader

https://github.com/SergioBenitez/Rocket on stable rust finally!

https://github.com/SergioBenitez/Rocket/milestone/8 is what's on the milestone for the next release, I don't know how closely that actually tracks. I'm super excited though!

IMHO, it's a shame So Much time has been spent (~3 years ?) on async at the cost of basic features like multipart and CORS.

But I understand it could be more fun for the devs :-)

I think it makes sense to get your foundation and ergonomics correct before piling on features. Otherwise you end up building features that may need to be completely restructured/redone later.

I recently switched from old sync versions of hyper and postgres to the new async versions. [1]

It wasn't hard, but yeah it was not fun either.

I can only imagine it's worse if you're actually writing the libraries and not just a CRUD app like I am

[1] Apparently the postgres crate was a wrapper around tokio_postgres all along and I didn't notice. So to remove a dependency I switched to using tokio_postgres directly

They've really only spent about a year or so on async support in Rocket. They were waiting for async/await to stabilize and the async runtime story to centralize a bit (though they picked Tokio as the default).

Features like CORS are available via third party fairings, but I could see them being incorporated in the future in the `rocket_contrib` portion. I think the goal is to keep the overall framework pretty light and put more things into the `rocket_contrib` portion.

When I started learning Rust over a year ago now, Rocket was extremely appealing to me. I never subscribe to any GitHub threads that I'm not involved in, except for Rocket on stable.

In general, stable proc macros is an awesome step for Rust.

Interesting. Haven’t used rocket, but I am intrigued by warp since it has a websocket server as well.

Great news, but it's not even 1.0 yet. Thus, it isn't stable enough for production use.

At the moment, I'd rather use something like actix-web instead.

That's not how versions work

>= 1.0 in semantic versioning universally means that it should be "stable enough"

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.

They are doing it wrong then.

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.

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.

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.

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

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

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

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.

Reply on news.ycombinator.com