Rust 1.34.2(blog.rust-lang.org)
blog.rust-lang.org
Rust 1.34.2
https://blog.rust-lang.org/2019/05/14/Rust-1.34.2.html
2 comments
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)?
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.
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.
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... :)
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... :)
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...
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?
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...
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.
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.