Hacker News Reader

Comment by sanxiyn | Hacker News Reader

Rust has no reasonable specification yet although it is being worked on.

Which is the main reason why no usable alternative implementations exist yet and why Rust hasn't found its way to more low-level software projects like the Linux plumberland yet.

Rust dearly needs a stable specification, it is the main blocker why the language hasn't been more widely adopted.

Rust has LTS like releases based on years, but the last one didnt have async await so everyone just kept tracking. I think the nexts LTS type release may snag some people and slow stuff down. Cargo should handle that fine, but not sure about maintainers. I cant get cargo in my day job, just the rustc 1.3x shipped with rhel, so I'm already standing still. Rhel's version migh make a good defacto lts in the absence of cargo, but the thin std lib makes that hard, and random old rustc versions sometimes don't play nice with every crate.

Rust doesn't have LTS releases. Editions are both a way to market the new features introduced in the past years as a "bundle" to outside users, and a way for us to introduce some breaking changes for the users opting into the new edition. The release an edition is stabilized in (1.31 for Rust 2018) does not get any special treatment from the Rust team though, and that includes no LTS support (for example we won't backport bug fixes, even security ones).

Yikes! I had no idea. It takes my company years sometimes to approve a new point release of software. Rhel subscription was my backdoor to get rust at work. I knew I'd never get a cargo access or a mirror approved, but i thought some day I'd push for an lts release. I don't see my company ever doing sw approval and transfer to our development network faster than once a year.

Well with RHEL 8 you can get a pretty up to date rustc, as they update the version in their stable repos every three months (so every two releases): https://developers.redhat.com/blog/2019/11/07/support-lifecy...

As I pointed out in another comment, the definition of the 2015 edition is still changing (i.e., features from 2018 are getting backported to 2015), severely limiting the usefulness of the "edition" concept.

E.g., if someone thinks "I'm going to target 2015 because I want my code to run on the rustc shipped with various slow-moving Linux distros", it doesn't help, because you might still not be able to target their code, unless they specifically target an older version of rustc, which nobody does.

Editions solve an entirely separate problem, they were never meant to be LTS language snapshots. For example, C++ is considering adopting them in addition to their current versioning scheme: http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1881r0....

There has been discussion of a Rust LTS channel alongside stable/beta/nightly, which would try to solve that problem, but it has not been prioritized yet: https://github.com/rust-lang/rfcs/pull/2483

An actual frozen language is also a possibility, but probably won't happen until more work happens on an independent specification. Which, in fact, people are also working on: https://ferrous-systems.com/blog/sealed-rust-the-pitch/

I wasn't aware of the Sealed Rust project. Very cool!

I agree. That, and no need to rush new features, stabilize old ones and fix their bugs. I am still waiting for RFC0066[1] to be fixed. It is from 2014-05-04! Here is its GitHub Issue: https://github.com/rust-lang/rust/issues/15023. Backstory: I started writing a relatively simple Rust program many years ago when I ran into this issue. It was my first attempt at writing Rust, and I did not like the workaround.

[1] https://github.com/rust-lang/rfcs/blob/master/text/0066-bett...

I would say that rust doesn’t have a formal specification, what it does have is close to or better than many languages “specs” with the “Rust Reference”: https://doc.rust-lang.org/stable/reference/

It really depends on how strictly you define the term specification. The Rust Reference is not required to be accurate. Though many other language compilers/implementations don’t fully implement their respective specs so, :shrug:.

The Rust Reference is very far from being complete, or even correct in what it does cover.

If I have a question whose answer isn't obvious, it's far more likely that I have to go trawling around in RFCs than that there's an answer in the reference.

I think most languages of a similar age (eg Go, Swift) are doing better.

Rust is younger than Go (released in 2015 vs 2012) and way more ambitious, especially Rust 1.0 was released as kind of an MVP and many things have changed since then, which made the maintenance of such a reference an issue. The pace of change is slowing nowadays (that's especially visible if you look new and accepted RFCs), so I hope the reference will catch up eventually.

There are some people studying Rust with formal verification. For example in this paper https://plv.mpi-sws.org/rustbelt/rbrlx/paper.pdf However I do not know if the whole language is covered or only a core.

The big gap with RustBelt is that it does not cover traits. This actually does matter: some bugs were missed because they interact with traits.

Reply on news.ycombinator.com