Rust 1.34.2 | Hacker News Reader

Rust 1.34.2

blog.rust-lang.org

117 pointspietroalbini16 comments

> The Error::type_id method was recently stabilized as part of Rust 1.34.0. This point release destabilizes it

So in summary a feature that was stable for 3 days is taken back for further bugfixing. A bit unfortunate but given the very short timeframe where it was stable the impact should be minimal.

The best bugs are short-lived bugs.

In this case I think it's a short-lived feature.

The worst kind of stability is short-lived stability.

Still better than hidden instability

A month and 3 days, but yeah.

> So in summary a feature that was stable for 3 days is taken back for further bugfixing.

It seems like such a terribly subtle bug. I wonder, how was it discovered (so quickly)?

Rust releases spend six weeks in beta, and each individual feature can spend an unlimited amount of time baking in nightly, which is usually enough time to catch potential soundness issues before they find their way into stable (this is the second point release that I can recall having such a purpose). The particular feature under which this API falls has been in nightly for quite a while, so it may be that someone had a half-formed idea of how to trigger memory unsafety and was only reminded of it when they read the release notes where its stabilization was mentioned.

> so it may be that someone had a half-formed idea of how to trigger memory unsafety

So someone just had the idea to test the new feature for soundness? It's not as if someone ran some kind of fuzzing or updated a formal methods model? If so, I think it's great that there's vigilant folks out there who try to break new features like this.

Could be it just came across the right pair of eyes. It's quite reminiscent of the old EvilIx problem in Haskell, where you can break memory safety without doing anything explicitly marked unsafe: https://mail.haskell.org/pipermail/haskell-cafe/2006-Decembe...

There are a few places in Rust and its stdlib that people seek to validate with formal methods, but usually these efforts are first focused on proving fundamental pieces (such as std::pin https://doc.rust-lang.org/std/pin/index.html , which I believe has been integrated into Ralf Jung's formal model), and only later on outlying APIs such as this (the rationale being that fundamental APIs would be enormously more disruptive to fix if unsoundness should be discovered).

As to your conclusion though, obligatory shout-out to Huon Wilson, who discovered the one other instance of unsoundness in a newly-stabilized API (this one due to a typo, therefore much simpler to resolve), mere hours after the stable release of Rust 1.15: https://www.reddit.com/r/rust/comments/5roiq7/announcing_rus... :)

It was well known from older versions of GHC Haskell. Given how much Haskell knowledge was imported into Rust, it's surprising that this made it into stable at all.

By the way, does anyone know any success stories of using Rust for writing business logic/software?

https://www.figma.com/blog/rust-in-production-at-figma/

We use (and we love!) Rust at https://snips.ai, you can take a look at a recent optimized neural network library we have open-sourced which uses Rust!

https://medium.com/snips-ai/snips-open-sources-tract-cdc50f4...

We use it for Turtl (https://github.com/turtl/core-rs). I converted a huge portion of the business logic from js -> rust to make it embeddable in a lot of different platforms (by exposing a C api). Very successful, much more stable and fast than its JS ancestor.

Reply on news.ycombinator.com