On Tue, Nov 19, 2019 at 6:51 AM John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
Hi!
On 11/19/19 12:58 AM, William Brown wrote:
Rust as a language has a very aggressive release cycle compared to what we expect on a platform like SUSE - 6 weeks (https://github.com/rust-lang/rust/blob/master/RELEASES.md). In each cycle Rust releases new features, and despite the core language being "stable" and safe (which is great!) new features tend to be used very rapidly by library authors. For example the release from Version 1.34.0 (2019-04-11) contains convert::TryFrom, which is now in use by a large number of libraries.
Is that really that common? I have had a lot of interaction with Rust upstream through Debian and I was always told it's normally only the Rust compiler itself which uses new features in its own code which is why it always needs to be built with either its own version or the previous version, older or newer versions usually break.
Unfortunately, the cake is a lie. The Rust community does not have a culture of conservatism. To be fair, they have not yet been burned by using the newest features as soon as they become available. But this is why Fedora is on the Rust compiler update treadmill.
It sometimes happens that 3rd party Rust software projects are affected by it like you say, but I have observed that only occasionally unless the Rust compiler is really old. But maybe the situation is worse when using SLE due its long-term character.
The situation is definitely aggravated in RHEL and SLE, since it's fairly difficult to update the compiler in those distributions (because of the difficulty of the update submission and approval process, not because of a technical problem).
However, generally I think that Rust should slow down with frequent incompatible changes to the language itself as this prevents independent compiler implementations to keep up. mrustc is currently compatible with Rust 1.29.0 and from GCC upstream I have heard that the frequent changes are the main blocker for adopting a Rust frontend in GCC.
The Rust community needs to get burned a few times first. But I think we're a long ways away from that happening. The Rust compiler developers are smart guys, but they don't understand that bootstrapping Rust is not supposed to be so hard. It doesn't help that Rust upstream doesn't care much about concerns from distributions and downstream developers. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org