Rust 1.49.0 released
Tier 1 platforms can be thought of as 'guaranteed to work'". Also, arm64 macOS and Windows have risen to Tier 2 status, which means they are guaranteed to build and are likely to work just fine, but the automated tests are not run. Beyond that, the test framework now captures output from multiple threads and some library changes were made. See the detailed release notes for more information. "
Rust 1.49.0 promotes the aarch64-unknown-linux-gnu target to Tier 1 support, bringing our highest guarantees to users of 64-bit ARM systems running Linux! We expect this change to benefit workloads spanning from embedded to desktops and servers. This is an important milestone for the project, since it's the first time a non-x86 target has reached Tier 1 support: we hope this will pave the way for more targets to reach our highest tier in the future. Note that Android is not affected by this change as it uses a different Tier 2 target."
Posted Jan 2, 2021 5:08 UTC (Sat)
by wtarreau (subscriber, #51152)
[Link] (27 responses)
In addition, a second problem is that by conflating the two, it implies that writing programs at a certain point in time possibly means your program will not compile anymore later once you're forced to upgrade your compiler due to lack of maintenance. Thinking that I'd develop for a specific compiler version doesn't attract me at all!
Posted Jan 2, 2021 7:20 UTC (Sat)
by jem (subscriber, #24231)
[Link]
Yes, it is unfortunate that there is no language specification. "We intend to produce such a book someday". The situation is not as bad as you make it sound, since Rust defines editions that include a set of introduced features. So far, two editions have been defined: Rust 2015 and Rust 2018. Rust code intended for wider consumption should target an edition, not some random compiler version. Cargo supports this with the "edition" setting in Cargo.toml.
Posted Jan 2, 2021 8:52 UTC (Sat)
by josh (subscriber, #17465)
[Link] (18 responses)
> The language should be defined by a spec and rarely evolve
I consider "rarely evolve" a characteristic of dead projects, not living ones. I don't expect Rust to change unnecessarily or gratuitously. I do expect it to continue evolving for as long as people care about it and want to use it to solve new problems as well as old ones. And as long as it continues to evolve, I see no reason why its evolution should occur only on a multi-year cadence. I don't believe that buys us anything. Any individual feature should absolutely take an appropriate amount of time and experimentation before becoming stable, of course.
(This is not an argument against a spec; this is an argument against "rarely evolve".)
There are proposals on the table for things like "sealed Rust", for people with special-purpose applications that need a completely unchanging toolchain for a multi-year period, but that's not the normal case.
> How do you want anyone to implement their own compiler
There is a publicly available compiler under a permissive license. I sincerely hope that nobody reinvents the wheel by writing another, without an incredibly good reason that could not be accomplished in a better way. (Such good reasons potentially exist, but many of them would also apply to making the existing compiler better.)
There are people looking to write precise specs. I think such specs are a good idea. They'll help people working on formal methods and soundness analyses, and they'll help people looking to use Rust in places that expect a specification.
> it implies that writing programs at a certain point in time possibly means your program will not compile anymore later once you're forced to upgrade your compiler due to lack of maintenance
This is orthogonal to the existence of a separate language spec. If you write your programs in C, it is possible that at some future time there will no longer be a maintained C compiler for your platform, due to lack of maintenance. The only way around that, in either case, is to ensure that a maintained compiler continues to exist for your platform, or to change platforms.
Posted Jan 2, 2021 11:31 UTC (Sat)
by roc (subscriber, #30627)
[Link] (4 responses)
Certainly, the investment required to create and maintain one or more additional compilers would be large, and it's not clear when, if ever, the benefit will outweigh the cost. Maybe if there's a technology shift that makes reimplementing the compiler for scratch attractive...
Posted Jan 2, 2021 12:44 UTC (Sat)
by amacater (subscriber, #790)
[Link] (3 responses)
Posted Jan 3, 2021 14:54 UTC (Sun)
by rsidd (subscriber, #2582)
[Link] (2 responses)
Posted Jan 5, 2021 7:19 UTC (Tue)
by dvdeug (guest, #10998)
[Link] (1 responses)
There's one Rust reimplementation on GitHub right now. Nobody may produce a professional reimplementation of Rust anytime soon, but experimental reimplementations will happen.
Posted Jan 5, 2021 13:19 UTC (Tue)
by kleptog (subscriber, #1183)
[Link]
Posted Jan 2, 2021 15:17 UTC (Sat)
by joib (subscriber, #8541)
[Link] (12 responses)
This is a critical difference. The situation was wildly different, say, back when ANSI C was written down. Then there were multiple independent proprietary compilers, and users as well as compiler developers needed a document specifying what exactly the language was (and arguably, looking e.g. at the decades long strict aliasing saga, they didn't do a particularly good job of it).
As for a hypothetical Rust spec, I'm unsure whether a prose spec similar to C, C++, Fortran would be worth the trouble. A machine readable formally provable one might, though.
Posted Jan 2, 2021 17:49 UTC (Sat)
by JoeBuck (subscriber, #2330)
[Link] (4 responses)
So I think it would help the Rust project to start working on standardization. This doesn't mean the project is dead; C++ has been doing a new standard every three years since 2011.
Posted Jan 2, 2021 19:21 UTC (Sat)
by bluss (guest, #47454)
[Link] (2 responses)
Posted Jan 4, 2021 13:33 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
Then we have compiler implementors who take advantage of those ill-defined behaviours to try and squeeze every ounce of performance they can. at the expense of predictable behaviour ... "hey the spec tells us we can do whatever we like ...".
Cheers,
Posted Jan 6, 2021 18:26 UTC (Wed)
by khim (subscriber, #9252)
[Link]
Forget about “some details”. If you want to use some features introduced in C99, then you need Visual Studio 2019 version 16.8. Means: for twenty years what compiler did and what spec said were two entirely different things!
Or think Pascal. There are two specs… yet most popular implementations don't support either of them!
And let's not even start talking about virtues of programming SQL databases using just specs.
Frankly, virtues of the spec is way, way, WAY overrated.
The only reason to have useful spec is when there are two independent implementations… and their makers want to be compatible.
And that rarely happens — more often then not even if there are specs real programs are not written for the spec for the particular compiler, instead.
Posted Jan 2, 2021 20:31 UTC (Sat)
by josh (subscriber, #17465)
[Link]
With every single release, as well as any time we make a change that has even the potential of compatibility issues, we put it through a "crater" run, which means that we build every single published crate and every public Rust repository we can find, and make sure that we don't see any regressions. We take compatibility *very* seriously.
Even if we had a full spec, that wouldn't change. We wouldn't just say "eh, your code isn't quite following the spec, so it's OK for us to break it because the behavior you were counting on wasn't actually part of the spec". We always consider the impact of changes.
Posted Jan 2, 2021 19:37 UTC (Sat)
by Hattifnattar (subscriber, #93737)
[Link] (6 responses)
Posted Jan 3, 2021 23:07 UTC (Sun)
by roc (subscriber, #30627)
[Link] (5 responses)
Posted Jan 4, 2021 8:05 UTC (Mon)
by epa (subscriber, #39769)
[Link] (4 responses)
Posted Jan 5, 2021 9:04 UTC (Tue)
by flussence (guest, #85566)
[Link] (1 responses)
Posted Jan 5, 2021 15:45 UTC (Tue)
by epa (subscriber, #39769)
[Link]
Posted Jan 5, 2021 10:46 UTC (Tue)
by niner (subscriber, #26151)
[Link] (1 responses)
Of course, having an executable specification gives rise to an exiting new field: bugs in the specification. As with any code, these happen as well. Mostly they are in the form of overly specific tests, like tests that - for lack of better infrastructure when they were written - expect specific wording of error messages, or specific types for return values, like an Array, when we actually want to allow any List (Array's base class) or even any Iterable. As with any bugs, those get fixed over time (and hopefully faster than we add new bugs).
Posted Jan 8, 2021 12:41 UTC (Fri)
by epa (subscriber, #39769)
[Link]
I don't disagree with your judgement that the test suite is being too strict in these cases, but to arrive at that judgement you have applied some unwritten rules. One is "the exact text of an error message is not considered part of the API guarantee". You will have rules of thumb you apply for type changes too, allowing more general types in some cases. But these rules ought to be codified somewhere, in a written "meta-specification".
I admit I am arguing against a straw man, in that no project strictly follows "the test suite is the spec". To do so would mean being unable to change any observable behaviour, even error strings, as you point out. It is a good slogan but the reality is a bit different.
Posted Jan 4, 2021 15:31 UTC (Mon)
by scientes (guest, #83068)
[Link] (5 responses)
1. rust has a mandatory runtime, and that runtime depends on libc
2. rustc produces very dirty LLVM-IR (way more verbose than say, the stage1 zig compiler)
3. rust isn't really pegged to LLVM's feature set---they try to support multiple versions of LLVM, and dropped 128-bit float support after it was present, and also lack portable SIMD which LLVM (and GCC) have very good support for, but no languages, including C, export in a usable form
Posted Jan 4, 2021 15:59 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
You can read here: https://rust-embedded.github.io/book/intro/no-std.html or maybe https://os.phil-opp.com/allocating-frames/
The "runtime" (i.e. stdlib) that Rust has is very thin regardless. It basically consists of some static setup, pre-main initialization and integration with the system allocator.
You can reimplement Rust's stdlib it in a way that doesn't depend on libc. There were projects to do just that, but they ran out of steam because ultimately it just doesn't provide you much. There's no functional difference between being completely static and depending on unversioned libc.
Oh, and you can build Rust with musl libc, which does support fully static builds.
Posted Jan 4, 2021 18:23 UTC (Mon)
by josh (subscriber, #17465)
[Link] (2 responses)
You can do static builds with glibc these days, too: https://github.com/rust-lang/rust/pull/77386
Posted Jan 4, 2021 18:28 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Jan 4, 2021 19:50 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Posted Jan 4, 2021 18:54 UTC (Mon)
by Jonno (subscriber, #49613)
[Link]
Not at all. Rust has a mandatory core library (libcore) which does not depend on anything at all; and an optional standard library (libstd), which requires some kind of runtime. The default implementation of libstd uses libc (on Unix-like platforms) or Win32 (on Windows platforms) to provide said runtime, but could be ported to some other runtime if required.
[Though it would be possible to write a suitable runtime in rust, depending on nothing but libcore and Linux syscalls, and port libstd to it, no one seems to have done so yet. Doing so would be a lot of work for very little benefit, and would make it impossible do to FFI with C-based libraries, unless one also ported or reimplemented a libc on top of said runtime.]
Posted Jan 7, 2021 0:24 UTC (Thu)
by moltonel (guest, #45207)
[Link]
The rust RFCs (https://rust-lang.github.io/rfcs/) and their associated PRs can be seen as a rust spec, and are in some ways much more useful than an ISO-style spec. The C and C++ specs in particular are almost useless for developers due to the amount of explicitly undefined and implementation-defined areas (not to mention buggy and incomplete implementations). If you need your code to behave exactly the same for you today as for another developer across the globe in ten years on a different platform, Rust is a pretty good choice.
Mrustc is another rust compiler, written in C++, aimed at bootstrapping. Rust-analyzer is increasingly seen as another Rust implementation, aimed at IDE integration. There are other projects, like one to enable GCC as a Rust backend. Rustc may be the only one "state of the art rust compiler", but it's not being developed in autocratic isolation.
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
The problem with just saying that the only implementation is also the de facto spec is that you don't know if the behavior of a corner case (where the manual isn't clear) is intentional and something that can be counted on, or accidental and will break in the next release. That kind of thing also tends to hamper the implementers; Microsoft has struggled over the years in part because important programs turned out to depend on accidental quirks, meaning that Microsoft felt stuck with them.
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Wol
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Raku (former Perl 6) adopted the model, "Test suite is the spec".
Leaving aside other merits of Raku, I think it's a very clever approach.
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
That's not true. Rust runs just fine on bare hardware, there's even Cargo support for it.
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released
Rust 1.49.0 released