Software-update: Rust 1.90.0

Rust logoRust is een programmeertaal bedacht door Graydon Hoare en oorspronkelijk ontwikkeld door Mozilla. Het is deels geïnspireerd op de programmeertaal C, maar kent syntactische en semantische verschillen. Het focust op veiligheid en moet moderne computersystemen efficiënter benutten. Het wordt onder meer ingezet door Cloudflare, OVH, Mozilla, Deliveroo, Coursera, AppSignal en Threema. Versie 1.90 is uitgebracht en de releasenotes voor die uitgave kunnen hieronder worden gevonden.

LLD is now the default linker on x86_64-unknown-linux-gnu

The x86_64-unknown-linux-gnu target will now use the LLD linker for linking Rust crates by default. This should result in improved linking performance vs the default Linux linker (BFD), particularly for large binaries, binaries with a lot of debug information, and for incremental rebuilds. In the vast majority of cases, LLD should be backwards compatible with BFD, and you should not see any difference other than reduced compilation time. However, if you do run into any new linker issues, you can always opt out using the -C linker-features=-lld compiler flag. Either by adding it to the usual RUSTFLAGS environment variable, or to a project's .cargo/config.toml configuration file, like so:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Clinker-features=-lld"]

If you encounter any issues with the LLD linker, please let us know. You can read more about the switch to LLD, some benchmark numbers and the opt out mechanism here.

Cargo adds native support for workspace publishing

cargo publish --workspace is now supported, automatically publishing all of the crates in a workspace in the right order (following any dependencies between them). This has long been possible with external tooling or manual ordering of individual publishes, but this brings the functionality into Cargo itself. Native integration allows Cargo's publish verification to run a build across the full set of to-be-published crates as if they were published, including during dry-runs. Note that publishes are still not atomic -- network errors or server-side failures can still lead to a partially published workspace.

Demoting x86_64-apple-darwin to Tier 2 with host tools

GitHub will soon discontinue providing free macOS x86_64 runners for public repositories. Apple has also announced their plans for discontinuing support for the x86_64 architecture. In accordance with these changes, as of Rust 1.90, we have demoted the x86_64-apple-darwin target from Tier 1 with host tools to Tier 2 with host tools. This means that the target, including tools like rustc and cargo, will be guaranteed to build but is not guaranteed to pass our automated test suite.

For users, this change will not immediately cause impact. Builds of both the standard library and the compiler will still be distributed by the Rust Project for use via rustup or alternative installation methods while the target remains at Tier 2. Over time, it's likely that reduced test coverage for this target will cause things to break or fall out of compatibility with no further announcements.

Stabilized APIs

These previously stable APIs are now stable in const contexts:

Platform Support
  • x86_64-apple-darwin is now a tier 2 target

Refer to Rust’s platform support page for more information on Rust’s tiered platform support.

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Rust

Versienummer 1.90.0
Releasestatus Final
Website The Rust Programming Language Blog
Download https://www.rust-lang.org/install.html
Licentietype Voorwaarden (GNU/BSD/etc.)

Door Bart van Klaveren

Downloads en Best Buy Guide

19-09-2025 • 10:30

9

Submitter: danmark_ori

Bron: The Rust Programming Language Blog

Update-historie

10:30 Rust 1.90.0 9
09-08 Rust 1.89.0 1
27-06 Rust 1.88.0 8
16-05 Rust 1.87.0 1
04-04 Rust 1.86.0 0
21-02 Rust 1.85.0 0
31-01 Rust 1.84.1 0
10-01 Rust 1.84.0 0
11-'24 Rust 1.83.0 5
09-'24 Rust 1.81.0 1
Meer historie

Reacties (9)

9
9
4
0
0
5
Wijzig sortering
Er wordt wel eens beweerd dat het goed zou zijn om de linux kernel helemaal in Rust te schrijven. Hoe ver zijn dergelijke projecten op dit moment? Is er al een werkbare kernel die in een bruikbare distributie is opgenomen?

Of gooi ik zaken door elkaar en ben ik in de war met een andere taal?

[Reactie gewijzigd door beerse op 19 september 2025 12:52]

Het is nu mogelijk een stukken van de kernel in rust te schrijven. De echte 'kern' zal altijd in C blijven. De kernel heeft zulke specifieke zaken nodig dicht op de hardware. Het is geen normaal C programma, aangezien de basis van ieder normaal C programma niet beschikbaar zijn (een C-library of malloc door een kernel e.d.). Ook vereist het dat soms de "veiligheidschecks" die rust biedt aan de kant kunnen.

[Reactie gewijzigd door YaPP op 19 september 2025 13:28]

Welk gedeelte kan volgen jou dan echt niet in Rust en waar je heb je echt C voor nodig? Er zijn al een aantal projecten bezig om echt een heel OS (lees kernel) in rust te schrijven.. Dus ik ben heel benieuwd.. geef eens even voorbeeld van 'die specifieke zaken' die niet in Rust kunnen?
Geen idee;

https://www.redox-os.org

En de rest van de firmware etc kan ook in Rust;

https://github.com/oxidecomputer/helios

[Reactie gewijzigd door MiesvanderLippe op 19 september 2025 14:58]

Bij de huidige linux kernel zal de kern altijd in c blijven. Daar kunnen we het over eens zijn. Daar zijn vast ook speciale stukken code die hardware specifiek zijn, netjes omgeven met pre-proces code om de juiste stukken op de juiste hardware te laten landen. Maar dat kan in andere talen ongetwijfeld ook.

De basis van de taal c is zo beperkt dat de formele specificatie op een a-4-tje past, afgedrukt op een matrix printer dus zou het in 66 regels van 80 karakters leesbaar moeten zijn.

De libraries die in C gebruikt worden (stdio van "include stdio.h" bijvoorbeeld) zijn in andere talen in de regel op taal specifieke manier beschikbaar of zitten er zelfs standaard in (zoals bij pascal en modula-2). Dus dat kan ook het probleem niet zijn.

Volgens mij zit de uitdaging in de optimalisatie en specifieke zaken als een geforceerde manier waarmee het op de processor komt. Maar toegegeven, hier heb ik in de vorige eeuw mee zitten stoeien (in modula-2) recente ervaring heb ik hier in niet.
De basis van de taal c is zo beperkt dat de formele specificatie op een a-4-tje past
Wat bedoel je met de formele specificatie?

Want als ik naar C23 kijk (ISO/IEC 9899:2023, laatste working draft voor standaardisatie hier), en dan zo vrij ben alleen hoofdstuk 5 en 6 te pakken (dus geen inhoud, definitie van woorden, etc, noch de standarad library), dan is dat alsnog 180 pagina's.

De grammatica alleen al (appendix A) is 15 pagina's.

[Reactie gewijzigd door .oisyn op 19 september 2025 16:16]

Wat ik op mijn netvlies heb staan is wat er in hoofdstuk 6 staat. Maar dan alleen de formele specificaties, bijvoorbeeld in uml . En toegegeven, de c-standaard zoals ze in 1988 in gebruik was.

Verder gekeken naar apendix a: Begin met de lucht uit de lay-out te halen en de verklarende tekst er uit. Een specificatie op 1 regel met eventueel een omloop. Als je terug gaat naar de c van 1988 of zo en ook alleen de taal specificatie pakt, dan is dat toch best wel te comprimeren op 1 of 2 pagina's.

En dan ook alleen de taal C, niet de preprocessor, niet de directives en dergelijke. #include wordt immers niet door de c-compiler verwerkt maar door de pre-processor. Die directives doen het ook heel goed in andere talen, als je de preprocessor maar aanroept voor de copileer slag.


Waar het mij vooral om gaat is dat de modules/libraries en dergelijke de functionaliteit van de taal C maken. Maar dat die dus geen vast onderdeel zijn van de taal. De taal C laat zich betrekkelijk eenvoudig beschrijven omdat er aan 2 kanten uitbreiding mogelijk is. De compile-directives (de #include en dergelijke) zijn voor de pre-processor. En de libraries/modules zijn voor de linker of dat nu build-time gebeurt of run-time. In veel andere talen zijn die zaken meer onderdeel van de taal.
Verder gekeken naar apendix a: Begin met de lucht uit de lay-out te halen en de verklarende tekst er uit. Een specificatie op 1 regel met eventueel een omloop. Als je terug gaat naar de c van 1988 of zo en ook alleen de taal specificatie pakt, dan is dat toch best wel te comprimeren op 1 of 2 pagina's.
En dan heb je de grammatica, dus de syntax, niet een formele specificatie van de taal. De grammatica zegt niet dat je een int* impliciet naar een float* kunt casten, of dat het lezen buiten een array undefined behavior is.
De taal C laat zich betrekkelijk eenvoudig beschrijven omdat er aan 2 kanten uitbreiding mogelijk is.
Tja, sorry, maar als je C een beetje kent dan weet je dat dat absoluut onzin is omdat er zo ontzettend veel haken en ogen zijn.

Ben het ook niet eens met je preprocessor verhaal (is gewoon onderdeel van de taal), maar het is niet eens van belang om er op in te gaan omdat dat slechts een ontzettend klein onderdeel is van het geheel.

[Reactie gewijzigd door .oisyn op 19 september 2025 17:13]

Je kunt niet eens de hele kernel in C schrijven. Tenminste een deel ervan is in assembly geschreven omdat C net zo min dicht genoeg op de hardware zit. Ik zie geen echte reden waarom het niet in (unsafe) Rust + assembly zou kunnen.

Zo te zien is daar ook onderzoek naar gedaan: https://sing.stanford.edu/site/assets/publications/levy17-rust.pdf


Om te kunnen reageren moet je ingelogd zijn