Software-update: Rust 1.71.0

Rust 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 beoogt moderne computersystemen efficiënter te benutten. Het wordt ingezet door onder andere Cloudflare, OVH, Mozilla, Deliveroo, Coursera, AppSignal en Threema. Versie 1.71.0 is begin deze maand uitgebracht met de volgende aankondiging:

C-unwind ABI

1.71.0 stabilizes C-unwind (and other -unwind suffixed ABI variants). The behavior for unforced unwinding (the typical case) is specified in this table from the RFC which proposed this feature. To summarize:

Each ABI is mostly equivalent to the same ABI without -unwind, except that with -unwind the behavior is defined to be safe when an unwinding operation (panic or C++ style exception) crosses the ABI boundary. For panic=unwind, this is a valid way to let exceptions from one language unwind the stack in another language without terminating the process (as long as the exception is caught in the same language from which it originated); for panic=abort, this will typically abort the process immediately.

For this initial stabilization, no change is made to the existing ABIs (e.g. "C"), and unwinding across them remains undefined behavior. A future Rust release will amend these ABIs to match the behavior specified in the RFC as the final part in stabilizing this feature (usually aborting at the boundary). Users are encouraged to start using the new unwind ABI variants in their code to remain future proof if they need to unwind across the ABI boundary.

Debugger visualization attributes

1.71.0 stabilizes support for a new attribute, #[debug_visualizer(natvis_file = "...")] and #[debug_visualizer(gdb_script_file = "...")], which allows embedding Natvis descriptions and GDB scripts into Rust libraries to improve debugger output when inspecting data structures created by those libraries. Rust itself has packaged similar scripts for some time for the standard library, but this feature makes it possible for library authors to provide a similar experience to end users. See the reference for details on usage.

raw-dylib linking

On Windows platforms, Rust now supports using functions from dynamic libraries without requiring those libraries to be available at build time, using the new kind="raw-dylib” option for #[link]. This avoids requiring users to install those libraries (particularly difficult for cross-compilation), and avoids having to ship stub versions of libraries in crates to link against. This simplifies crates providing bindings to Windows libraries. Rust also supports binding to symbols provided by DLLs by ordinal rather than named symbol, using the new #[link_ordinal] attribute.

Upgrade to musl 1.2

As previously announced, Rust 1.71 updates the musl version to 1.2.3. Most users should not be affected by this change.

Const-initialized thread locals

Rust 1.59.0 stabilized const initialized thread local support in the standard library, which allows for more optimal code generation. However, until now this feature was missed in release notes and documentation. Note that this stabilization does not make const { ... } a valid expression or syntax in other contexts; that is a separate and currently unstable feature.

use std::cell::Cell;

thread_local! {
    pub static FOO: Cell<u32> = const { Cell::new(1) };
}

Stabilized APIs

• CStr::is_empty
• BuildHasher::hash_one
• NonZeroI*::is_positive
• NonZeroI*::is_negative
• NonZeroI*::checked_neg
• NonZeroI*::overflowing_neg
• NonZeroI*::saturating_neg
• NonZeroI*::wrapping_neg
• Neg for NonZeroI*
• Neg for &NonZeroI*
• From<[T; N]> for (T...) (array to N-tuple for N in 1..=12)
• From<(T...)> for [T; N] (N-tuple to array for N in 1..=12)
• windows::io::AsHandle for Box<T>
• windows::io::AsHandle for Rc<T>
• windows::io::AsHandle for Arc<T>
• windows::io::AsSocket for Box<T>
• windows::io::AsSocket for Rc<T>
• windows::io::AsSocket for Arc<T>

These APIs are now stable in const contexts:

• <*const T>::read
• <*const T>::read_unaligned
• <*mut T>::read
• <*mut T>::read_unaligned
• ptr::read
• ptr::read_unaligned
• <[T]>::split_at

Other changes

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

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

Reacties (20)

[Complexity]

Rust is leuk voor high performant, low-level zaken. Ik denk dan aan Audio, maar ook bijvoorbeeld aan het decoden van fonts. Voor andere taken waarin iets snel moet werken gaat mijn voorkeur uit naar go. Fantasctische toeling, en makkelijk te begrijpen.

[berchtold]

Rust is erg snel. Sneller dan Go. Waarschijnlijk doel je op “speed of development”. Als je wil dat iets snel en correct werkt dan is Rust de betere keuze.
Rust is ook best high level in veel opzichten. Je kan het overal voor gebruiken en veel libraries hebben high level interfaces. Ook monads maakt het functioneel en high level.

[Reactie gewijzigd door berchtold op 25 juli 2024 11:39]

[likewise]

Mee eens. Monads ken ik niet, ga ik eens naar kijken.

Een van de grote verschillen tussen Rust en Go, is dat Go een garbage-collector gebruikt (denk aan Java) en Rust niet.

Dit kan, zeker op embedded single core systemen, nogal een impact hebben omdat je latency spikes krijgt.

Choose Go when:

You care about simplicity and readability
You want an easy syntax to quickly write code
You want to use a more flexible language that supports web development

Choose Rust when:

You care about performance
You want fine-grained control over threads
You value memory safety over simplicity

bron: https://blog.logrocket.co...-rust-when-to-use-golang/

[Complexity]

Ik begrijp de statements hier, en begrijp me niet verkeerd, Rust is een prima taal voor wanneer je zaken wilt ontwikkeling van zeer groot belang is. Echter ben ik van mening dat voor veel zaken deze performantie niet nodig is. Als je niet op embedded systemem werkt, of geen emulators of dergelijke ontwikkeld dan lijkt me de snelheid van Rust niet echt relevant, aangezien de grootste bottleneck waarschijnlijk database(s), filesystems, ... en dergelijke zijn.

[Ablaze]

Dat klopt. In principe moet je Rust zien als een alternatief voor C en C++.
Dat betekent voornamelijk: embedded software, drivers, OS code, SDKs, codecs, grafische bewerkingen, algoritmes in webassembly, enzovoorts.

Maar het grootste speerpunt van Rust is dat het een memory safe taal is. Hierdoor zou het ook een veiligere taal kunnen zijn voor webservers, browsers, enzovoorts. Immers worden buffer overruns en dergelijke voorkomen en daardoor valt een groep exploits weg.

[armageddon_2k1]

Wat maakt monads dat iets functioneel is?

[ChillinR]

Functional programming maakt veel gebruik van monads. https://en.m.wikipedia.or..._(functional_programming)

Dus niet de "functioneel" zoals je die in het woordenboek vindt, maar als in "functioneel programmeren". Waarschijnlijk zit daar de verwarring?

[Reactie gewijzigd door ChillinR op 25 juli 2024 11:39]

[armageddon_2k1]

Nee, m’n vraag is: waarom maakt het toevoegen van monads dat een taal functioneel wordt?

[airell]

Als je wil dat iets snel en correct werkt dan is Rust de betere keuze.

Mooi dat je ook geen semantische fouten meer kunt maken

[berchtold]

Rust is zeker een taal van de toekomst. Gebruik het zelf ook met plezier

[joepP]

Ik heb er even mee gespeeld, maar de borrow checker icm absurd traag compilen hebben me snel weer weggejaagd. Ik wacht wel op JAI.

[berchtold]

Weet je wel zeker dat je het goed getest hebt? Als een crate eenmaal gecompileerd is hoeft dat niet nog een keer. Daarna gaat het best snel. Het is logisch dat het iets langer duurt dan bij andere talen.

[joepP]

Uiteraard. Ik bedoel de compiletijd van een normaal programma, zeg 1000 regels. Duurt onwaarschijnlijk lang, wat voor mijn workflow een absolute killer is. Als je projecten groter worden mag je voor een recompile een minuut wachten.

[Ablaze]

Rust compiler is niet snel, maar dat is de C++ compiler ook niet.
Voor je workflow maakt dat niet altijd iets uit, want vaak hoeft maar een gedeelte opnieuw gecompileerd te worden na een wijziging.

Compilers die intermediate languages als uitvoer hebben (bijv. .NET of Java) zijn vaak veel sneller in vergelijking.

[joepP]

Ik weet niet wat jij doet qua programmeren, maar ik compile echt nonstop, en elke keer wachten pas ik voor. Schrijf vooral hele technische code, low level, dus eigenlijk zou Rust een goede fit kunnen zijn, maar ik kon er niets mee. Die borrow checker is ook rete irritant als je snel iets wilt testen trouwens.

[SH4D3H]

Voor jou klinkt Rust juist als een uitkomst. Blijkbaar zijn die "snelle tests" niet sound en we weten allemaal dat de kans dat "snelle tests" (ofwel tijdelijke oplossingen), heel vaak in het uiteindelijke product terecht komen. Naast dat het dan voor jezelf en collega's lastig te onderhouden is en je na een tijdje zelf ook niet meer weet welke shortcuts je genomen hebt, is de kans ook nog eens aanwezig dat jouw bedrijf/klant/gebruiker last krijgt van een of andere exploit in je snelle test waardoor je daar weer een hoop tijd aan kwijt bent.

Nee, tenzij je direct een reminder in je agenda zet voor de volgende dag/week om dat bestand te verwijderen, is het gewoon verstandig om direct goede code te schrijven. En Rust (en die rete irritante borrow checker) helpt daarbij.

[joepP]

Totaal mee oneens, ik drop nooit testjes in release, maar wil wel vaak snel dingen prototypen en testen.

Hoe gebruik jij Rust? Alleen voor wat kleine prive hobby speeltjes, of voor een serieuze codebase? Want het lijkt mij echt hell voor dat laatste…

[SH4D3H]

Voor serieuze code bases maak ik gebruik van Workspaces. Je hoeft op die manier vrijwel nooit lang te wachten op een compile. En als je ook nog je IDE zo instelt dat 'ie de feedback van Clippy gebruikt, zul je ook zelden gedoe hebben met compile errors omdat veel dan al afgevangen is. Werkt heerlijk

[Webber]

Wellicht handig om er ook even bij te vermelden waarom dat logisch is.

[mvkdev]

Alle crates die je in je cargo.toml toevoegd worden als source binnen gehengeld uit crates.io, vervolgens bij compileren moeten die dus de eerste keer ook worden gecompileerd.

Daarnaast is met schrijven van Rust de rust-analyzer vaak best wel intensief bezig (LSP), waardoor dingen soms ook wat traag lijken/zijn. Je hebt wel een beetje een snelle bak nodig, wil je leuk kunnen programmeren hiermee (misschien dat vscode met remote host, op langzamere laptops een uitkomst is. ben ik bezig mee te testen).