Comment by jph | Hacker News Reader

Comment by jph | Hacker News Reader

Parent Full thread

I'm building with Rust, Rocket, Diesel, and agree with much of the original article. I can also add more: in my direct personal experience, the lead people creating Rocket and Diesel are superb about responsiveness, ongoing communication, and enabling people (e.g. me) to help diagnose issues and fix the them. I'm continually thankful for the quality of participation among the people in the ecosystem.

On the technical side, there are definitely some learning curves among Rocket, Diesel, and other tools. A typical example is that different crates have their own implementations of concepts such as a UUID, and the developer must handle conversions, and also ensure that various dependency versions all align, and also can't (yet) easily use the current UUID crate, and also can't (yet) build using stable Rust. All of these aspects will be fixed soon, likely within a month or so as the crates stabilize.

If you try Rust, I highly recommend trying rust-analyzer, which provides near-real-time code advice as a plugin to most major editors.

Does having to develop against rust nightly over stable not worry you when attempting to productionize a service? I understand new features get shipped behind feature flags/language pragmas, but it seems like a massive looming risk.

Not that as of Rust 1.45, coming out this Thursday, Rocket will be able to target stable Rust: https://github.com/SergioBenitez/Rocket/issues/19#issuecomme...

I believe Diesel has been on stable for a long time now, so for this use case I don't think anyone will need to worry about using the nightly releases.

That's good news! Wasn't aware of the pin change for rocket.

One more thing: I build my final binaries with stable (when possible), but develop with recent a nightly. There are some features that require nightly (custom testing frameworks come to mind) but don't affect the final binary (only tests) and I get the new goodies (better diagnostics, speed bumps, fixes) up to 12 weeks ahead of schedule.

Rustup makes having nightly and stable in the same machine painless, and I got in the habit of running cargo +stable build and cargo +nightly test. BTW, you don't have to do this, it just makes my experience a bit nicer.

Not OP, but: It does not for me, fwiw. However we release often, so i'm not releasing a binary into a distributed ecosystem where i expect it to live for years and years. In that scenario i would be wary of non-stable, since a looming issue in nightly could persist for an uncontrolled amount of time.

However thus far we have never had to push a release due to a bug found in nightly. We also have never had a build break because of nightly, or even upgrading.

The only breakage i'm aware of was, oddly, a semi-recent Rustup change. Our CI was not pinning the Rustup version, and the argument defaults changed so the downloaded Rustup did not have the components needed for our CI setup.

We will however migrate to stable once Rocket becomes stable. Thus far however, we've not had any trouble on nightly. I can only assume this is a result of the Rust teams excellent QA/tests/care/etc, combined with the language itself being very easy to write error-free code.

Developing based on Rust nightly has caused some learning curve gotchas, such as discovering a POSIX bug in the Rust install script, or needing to write a custom Docker Alpine Rust nightly container, or needing to write small system scripts to ensure that nightly is the same version on our various build machines.

So far we've seen about 2/3 of nights fail for our code. The failure is totally obvious. So we revert to the previous night that we know works.

Depending on the level of maturity of the nightly features you rely on, for CI there is an env variable that makes the stable compiler think it is nightly. We use this flag at day job to use latest stable but be able to enable a handful of quasi stable nightly features (custom testing frameworks mainly and getting rocket to play nice). This is a double edged sword: it is the same as a pinned nightly in the sense that it is a static target, but differs in that bugs affecting stable and beta have been backported where any arbitrary nightly has no assurances one way or another, but bugs affecting nightly features aren't backported to the stable release and only fixed on nightly.

Also, for the love all that is holy do not publish a crate relying on that flag to enable the nightly features, it breaks the languages stability assurances and by extension the ecosystem.

Related: https://news.ycombinator.com/item?id=23351145

Reply on news.ycombinator.com