Rust (programming language): Difference between revisions

Revision as of 04:55, 7 August 2025

Latest revision as of 13:39, 25 August 2025

(17 intermediate revisions by 9 users not shown)

Line 68:

}}

'''Rust''' is a text-based [[General-purpose programming language|general-purpose]] [[programming language]] emphasizing [[Computer performance|performance]], [[type safety]], and [[Concurrency (computer science)|concurrency]]. It enforces [[memory safety]], meaning that all [[Reference (computer science)|references]] point to valid memory. It does so without a conventional [[Garbage collection (computer science)|garbage collector]]; instead, memory safety errors and [[data race]]s are prevented by the "borrow checker", which tracks the [[object lifetime]] of references [[Compiler|at compile time]].

Rust supports multiple [[programming paradigm]]s. It was influenced by ideas from [[functional programming]], including [[Immutable object|immutability]], [[higher-order function]]s, [[algebraic data type]]s, and [[pattern matching]]. It also supports [[object-oriented programming]] via structs, [[Union type|enums]], traits, and methods.

Line 137:

=== Variables ===

[[Variable (computer science)|Variables]] in Rust are defined through the {{rust|let}} keyword.{{sfn|Klabnik|Nichols|2023|p=32}} The example below assigns a value to the variable with name {{coderust|foo}} of type {{rust|i32}} and outputs its value.

<syntaxhighlight lang="rust">

Line 146:

</syntaxhighlight>

Variables are [[Immutable object|immutable]] by default, but adding the {{rust|mut}} keyword allows the variable to be mutated.{{sfn|Klabnik|Nichols|2023|pp=32-33}} The following example uses {{coderust|//}}, which denotes the start of a [[Comment (computer programming)|comment]].{{sfn|Klabnik|Nichols|2023|pp=49-50}}

<syntaxhighlight lang="rust">

Line 158:

</syntaxhighlight>

Multiple {{coderust|let}} expressions can define multiple variables with the same name, known as [[variable shadowing]]. Variable shadowing allows transforming variables without having to name the variables differently.{{sfn|Klabnik|Nichols|2023|pp=34-36}} The example below declares a new variable with the same name that is double the original value:

<syntaxhighlight lang="rust">

Line 202:

</syntaxhighlight>

==== {{coderust|if}} expressions ====

An {{rust|if}} [[conditional expression]] executes code based on whether the given value is {{coderust|true}}. {{rust|else}} can be used for when the value evaluates to {{coderust|false}}, and {{rust|else if}} can be used for combining multiple expressions.{{sfn|Klabnik|Nichols|2023|pp=50-53}}

<syntaxhighlight lang="rust">

Line 233:

</syntaxhighlight>

==== {{coderust|while}} loops ====

<code>[[While loop|while]]</code> can be used to repeat a block of code while a condition is met.{{sfn|Klabnik|Nichols|2023|p=56}}

Line 247:

</syntaxhighlight>

==== {{coderust|for}} loops and iterators ====

[[For loop]]s in Rust loop over elements of a collection.{{sfn|Klabnik|Nichols|2023|pp=57-58}}

Line 267:

<syntaxhighlight lang="rust">

(1..=100).filter(|&x: i8| -> bool { x % 3 == 0 }).sum()

</syntaxhighlight>

==== {{coderust|loop}} and {{coderust|break}} statements ====

More generally, the {{rust|loop}} keyword allows repeating a portion of code until a {{rust|break}} occurs. {{rust|break}} may optionally exit the loop with a value. In the case of nested loops, labels denoted by {{rust|'label_name}} can be used to break an outer loop rather than the innermost loop.{{sfn|Klabnik|Nichols|2023|pp=54-56}}

Line 333:

=== Types ===

Rust is [[strongly typed]] and [[statically typed]], meaning that the types of all variables must be known at compilation time. Assigning a value of a particular type to a differently typed variable causes a [[compilation error]]. [[Type inference]] is used to determine the type of variables if unspecified.{{sfn|Klabnik|Nichols|2019|pp=24}}

The type <code>()</code>, called the "unit type" in Rust, is a concrete type that has exactly one value. It occupies no memory (as it represents the absence of value). All functions that do not have an indicated return type implicitly return <code>()</code>. It is similar to {{cpp|void}} in other C-style languages, however {{cpp|void}} denotes the absence of a type and cannot have any value.

The default integer type is {{rust|i32}}, and the default [[floating point]] type is {{rust|f64}}. If the type of a [[Literal (computer programming)|literal]] number is not explicitly provided, it is either inferred from the context or the default type is used.{{sfn|Klabnik|Nichols|2019|pp=36–38}}

==== Primitive types ====

[[Integer type]]s in Rust are named based on the [[signedness]] and the number of bits the type takes. For example, {{rust|i32}} is a signed integer that takes 32 bits of storage, whereas {{coderust|u8}} is unsigned and only takes 8 bits of storage. {{rust|isize}} and {{rust|usize}} take storage depending on the architecture of the computer that runs the code, for example, on computers with [[32-bit architecture]]s, both types will take up 32 bits of space.{{cn|date=August 2025}}

By default, integer literals are in base-10, but different [[radix|radices]] are supported with prefixes, for example, {{rust|0b11}} for [[binary number]]s, {{rust|0o567}} for [[octal]]s, and {{rust|0xDB}} for [[hexadecimal]]s. By default, integer literals default to {{rust|i32}} as its type. Suffixes such as {{rust|4u32}} can be used to explicitly set the type of a literal.{{sfn|Klabnik|Nichols|2023|pp=36-38}} Byte literals such as {{rust|b'X'}} are available to represent the [[ASCII]] value (as a {{rust|u8}}) of a specific character.{{sfn|Klabnik|Nichols|2023|p=502}}

Line 379 ⟶ 381:

</syntaxhighlight>

The function {{coderust|print_string}} takes ownership over the {{rust|String}} value passed in; Alternatively, {{coderust|&}} can be used to indicate a [[Reference (computer science)|reference]] type (in {{coderust|&String}}) and to create a reference (in {{coderust|&s}}):{{sfn|Klabnik|Nichols|2023|pp=71–72}}

<syntaxhighlight lang="rust">

Line 396 ⟶ 398:

Because of these ownership rules, Rust types are known as ''[[linear types|linear]]'' or ''affine'' types, meaning each value can be used exactly once. This enforces a form of [[software fault isolation]] as the owner of a value is solely responsible for its correctness and deallocation.<ref name="BeyondSafety">{{Cite book |last1=Balasubramanian |first1=Abhiram |last2=Baranowski |first2=Marek S. |last3=Burtsev |first3=Anton |last4=Panda |first4=Aurojit |last5=Rakamarić |first5=Zvonimir |last6=Ryzhyk |first6=Leonid |title=Proceedings of the 16th Workshop on Hot Topics in Operating Systems |chapter=System Programming in Rust |date=2017-05-07 |chapter-url=https://doi.org/10.1145/3102980.3103006 |series=HotOS '17 |___location=New York, NY, US |publisher=Association for Computing Machinery |pages=156–161 |doi=10.1145/3102980.3103006 |isbn=978-1-4503-5068-6 |s2cid=24100599 |access-date=June 1, 2022 |archive-date=June 11, 2022 |archive-url=https://web.archive.org/web/20220611034046/https://dl.acm.org/doi/10.1145/3102980.3103006 |url-status=live}}</ref>

When a value goes out of scope, it is ''dropped'' by running its [[Destructor (computer programming)|destructor]]. The destructor may be programmatically defined through implementing the {{coderust|Drop}} [[#Traits|trait]]. This helps manage resources such as file handles, network sockets, and [[Lock (computer science)|locks]], since when objects are dropped, the resources associated with them are closed or released automatically.{{sfn|Klabnik|Nichols|2023|pp=327-30}}

==== Lifetimes ====

[[Object lifetime]] refers to the period of time during which a reference is valid; that is, the time between the object creation and destruction.<ref>{{Cite web |title=Lifetimes |url=https://doc.rust-lang.org/rust-by-example/scope/lifetime.html |access-date=2024-10-29 |website=Rust by Example |archive-date=2024-11-16 |archive-url=https://web.archive.org/web/20241116192422/https://doc.rust-lang.org/rust-by-example/scope/lifetime.html |url-status=live }}</ref> These ''lifetimes'' are implicitly associated with all Rust reference types. While often inferred, they can also be indicated explicitly with named lifetime parameters (often denoted {{coderust|'a}}, {{coderust|'b}}, and so on).<ref>{{Cite web |title=Explicit annotation |url=https://doc.rust-lang.org/rust-by-example/scope/lifetime/explicit.html |access-date=2024-10-29 |website=Rust by Example}}</ref>

Lifetimes in Rust can be thought of as [[Scope (computer science)|lexically scoped]], meaning that the duration of an object lifetime is inferred from the set of locations in the source code (i.e., function, line, and column numbers) for which a variable is valid.{{sfn|Klabnik|Nichols|2019|p=194}} For example, a reference to a local variable has a lifetime corresponding to the block it is defined in:{{sfn|Klabnik|Nichols|2019|p=194}}

Line 416 ⟶ 418:

</syntaxhighlight>

The borrow checker in the Rust compiler then enforces that references are only used in the locations of the source code where the associated lifetime is valid.{{sfn|Klabnik|Nichols|2019|pp=75,134}}<ref>{{Cite web |last=Shamrell-Harrington |first=Nell |date=2022-04-15 |title=The Rust Borrow Checker – a Deep Dive |url=https://www.infoq.com/presentations/rust-borrow-checker/ |access-date=2022-06-25 |website=InfoQ |language=en |archive-date=2022-06-25 |archive-url=https://web.archive.org/web/20220625140128/https://www.infoq.com/presentations/rust-borrow-checker/ |url-status=live }}</ref> In the example above, storing a reference to variable {{coderust|x}} in {{coderust|r}} is valid, as variable {{coderust|x}} has a longer lifetime ({{coderust|'a}}) than variable {{coderust|r}} ({{coderust|'b}}). However, when {{coderust|x}} has a shorter lifetime, the borrow checker would reject the program:

<syntaxhighlight lang="rust">

Line 431 ⟶ 433:

</syntaxhighlight>

Since the lifetime of the referenced variable ({{coderust|'b}}) is shorter than the lifetime of the variable holding the reference ({{coderust|'a}}), the borrow checker errors, preventing {{coderust|x}} from being used from outside its scope.{{sfn|Klabnik|Nichols|2019|pp=194-195}}

Lifetimes can be indicated using explicit ''lifetime parameters'' on function arguments. For example, the following code specifies that the reference returned by the function has the same lifetime as {{coderust|original}} (and ''not'' necessarily the same lifetime as {{coderust|prefix}}):{{sfn|Klabnik|Nichols|2023|pp=208–12}}

<syntaxhighlight lang="rust">

Line 452 ⟶ 454:

==== Standard library ====

[[File:Rust standard libraries.svg|thumb|A diagram of the dependencies between the standard library modules of Rust.]]

The Rust [[standard library]] defines and implements many widely used custom data types, including core data structures such as {{coderust|Vec}}, {{coderust|Option}}, and {{coderust|HashMap}}, as well as [[smart pointer]] types. Rust also provides a way to exclude most of the standard library using the attribute {{rust|#![no_std]}}, for applications such as embedded devices. Internally, the standard library is divided into three parts, {{coderust|core}}, {{coderust|alloc}}, and {{coderust|std}}, where {{coderust|std}} and {{Coderust|alloc}} are excluded by {{rust|#![no_std]}}.{{sfn|Gjengset|2021|pp=213-215}}

Rust uses [[Option type|<code>Option</code>]] to define optional values, which can be matched using <code>if let</code> or <code>match</code> to access the inner value:{{sfn|Klabnik|Nichols|2023|pp=108-110,113-114,116-117}}

Line 482 ⟶ 484:

=== Polymorphism ===

Rust supports [[bounded parametric polymorphism]] through [[Trait (computer programming)|traits]] and [[generic function]]s.{{sfn|Klabnik|Nichols|2023|p=378}} Common behavior between types may be declared using traits and {{coderust|impl}}s:{{sfn|Klabnik|Nichols|2023|pp=192-198}}

<syntaxhighlight lang="rust">

Line 504 ⟶ 506:

</syntaxhighlight>

The example above also includes a method {{coderust|is_zero}} which provides a default implementation that is not required when implementing the trait.{{sfn|Klabnik|Nichols|2023|pp=192-198}}

A function can then be made generic by adding type parameters inside angle brackets ({{coderust|<Num>}}), which only allow types that implement the trait:

<syntaxhighlight lang="rust">

Line 521 ⟶ 523:

</syntaxhighlight>

In the examples above, {{coderust|Num: Zero}} as well as {{coderust|where Self: PartialEq}} are trait bounds that constrain the type to only allow types that implement {{coderust|Zero}} or {{coderust|PartialEq}}.{{sfn|Klabnik|Nichols|2023|pp=192-198}} Within a trait or impl, {{coderust|Self}} refers to the type that the code is implementing.{{sfn|Klabnik|Nichols|2023|p=98}}

Generics can be used in functions to allow implementing a behavior for different types without repeating the same code. Generic functions can be written in relation to other generics, without knowing the actual type.{{sfn|Klabnik|Nichols|2019|pp=171–172,205}}

Line 528 ⟶ 530:

Generic functions use [[static dispatch]], meaning that the type of all parameters that end up being used for the function must be known at compile time. Generic functions generate separate copies of the code for each combination of generic parameters used in a process called [[monomorphization]].{{sfn|Klabnik|Nichols|2023|pp=191-192}} Because monomorphization duplicates the code for each type used, it is as performant as writing functions using concrete types,{{sfn|Klabnik|Nichols|2023|pp=191-192}} but compile time and size of the output binary could be increased.{{sfn|Gjengset|2021|p=25}}

howeverHowever, Rust also uses a feature known as ''trait objects'' to accomplish [[dynamic dispatch]], a type of polymorphism where the implementation of a polymorphic operation is chosen at [[Runtime (program lifecycle phase)|runtime]]. This allows for behavior similar to [[duck typing]], where all data types that implement a given trait can be treated as functionally equivalent.{{sfn|Klabnik|Nichols|2023|loc=[https://doc.rust-lang.org/book/ch18-02-trait-objects.html 18.2. Using Trait Objects That Allow for Values of Different Types]}} Trait objects are declared using the syntax <code>dyn Tr</code> where <code>Tr</code> is a trait. Trait objects are dynamically sized, therefore they must be put behind a pointer, such as <code>Box</code>.{{sfn|Klabnik|Nichols|2019|pp=441–442}} The following example creates a list of objects where each object can be printed out using the <code>Display</code> trait:

<syntaxhighlight lang="Rust">

Line 556 ⟶ 558:

=== Unsafe ===

Rust's memory safety checks may be circumvented through the use of {{coderust|unsafe}} blocks. This allows programmers to deference arbitrary raw pointers, call external code, or perform other low-level functionality not allowed by safe Rust.{{sfn|Klabnik|Nichols|2023|pp=420-429}} Some low-level functionality enabled in this way includes [[Volatile (computer programming)|volatile memory access]], architecture-specific intrinsics, [[type punning]], and inline assembly.{{sfn|McNamara|2021|p=139, 376–379, 395}}

Unsafe code is sometimes needed to implement complex data structures.<ref name="UnsafeRustUse">{{Cite journal |last1=Astrauskas |first1=Vytautas |last2=Matheja |first2=Christoph |last3=Poli |first3=Federico |last4=Müller |first4=Peter |last5=Summers |first5=Alexander J. |date=2020-11-13 |title=How do programmers use unsafe rust? |url=https://dl.acm.org/doi/10.1145/3428204 |journal=Proceedings of the ACM on Programming Languages |language=en |volume=4 |issue=OOPSLA |pages=1–27 |doi=10.1145/3428204 |issn=2475-1421|hdl=20.500.11850/465785 |hdl-access=free}}</ref> A frequently cited example is that it is difficult or impossible to implement [[doubly linked list]]s in safe Rust.<ref>{{Cite journal |last=Lattuada |first=Andrea |last2=Hance |first2=Travis |last3=Cho |first3=Chanhee |last4=Brun |first4=Matthias |last5=Subasinghe |first5=Isitha |last6=Zhou |first6=Yi |last7=Howell |first7=Jon |last8=Parno |first8=Bryan |last9=Hawblitzel |first9=Chris |date=2023-04-06 |title=Verus: Verifying Rust Programs using Linear Ghost Types |url=https://dl.acm.org/doi/10.1145/3586037 |journal=Software Artifact (virtual machine, pre-built distributions) for "Verus: Verifying Rust Programs using Linear Ghost Types" |volume=7 |issue=OOPSLA1 |pages=85:286–85:315 |doi=10.1145/3586037|hdl=20.500.11850/610518 |hdl-access=free }}</ref><ref>{{Cite journal |last=Milano |first=Mae |last2=Turcotti |first2=Julia |last3=Myers |first3=Andrew C. |date=2022-06-09 |title=A flexible type system for fearless concurrency |url=https://dl.acm.org/doi/10.1145/3519939.3523443 |journal=Proceedings of the 43rd ACM SIGPLAN International Conference on Programming Language Design and Implementation |series=PLDI 2022 |___location=New York, NY, USA |publisher=Association for Computing Machinery |pages=458–473 |doi=10.1145/3519939.3523443 |isbn=978-1-4503-9265-5|doi-access=free }}</ref><ref>{{Cite web |title=Introduction - Learning Rust With Entirely Too Many Linked Lists |url=https://rust-unofficial.github.io/too-many-lists/ |access-date=2025-08-06 |website=rust-unofficial.github.io}}</ref><ref>{{Cite journal |last=Noble |first=James |last2=Mackay |first2=Julian |last3=Wrigstad |first3=Tobias |date=2023-10-16 |title=Rusty Links in Local Chains✱ |url=https://doi.org/10.1145/3611096.3611097 |journal=Proceedings of the 24th ACM International Workshop on Formal Techniques for Java-like Programs |series=FTfJP '22 |___location=New York, NY, USA |publisher=Association for Computing Machinery |pages=1–3 |doi=10.1145/3611096.3611097 |isbn=979-8-4007-0784-1|url-access=subscription }}</ref>

Programmers using unsafe Rust are considered responsible for upholding Rust's memory and type safety requirements, for example, that no two mutable references exist pointing to the same ___location.<ref name=IsRustSafely>{{Cite journal |last=Evans |first=Ana Nora |last2=Campbell |first2=Bradford |last3=Soffa |first3=Mary Lou |date=2020-10-01 |title=Is rust used safely by software developers? |url=https://doi.org/10.1145/3377811.3380413 |journal=Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering |series=ICSE '20 |___location=New York, NY, USA |publisher=Association for Computing Machinery |pages=246–257 |doi=10.1145/3377811.3380413 |isbn=978-1-4503-7121-6|arxiv=2007.00752 }}</ref> If programmers write code which violates these requirements, this results in [[undefined behavior]].<ref name=IsRustSafely/> The Rust documentation includes a list of behavior considered undefined, including accessing dangling or misaligned pointers, or breaking the aliasing rules for references.<ref>{{Cite web |title=Behavior considered undefined - The Rust Reference |url=https://doc.rust-lang.org/reference/behavior-considered-undefined.html |access-date=2025-08-06 |website=doc.rust-lang.org}}</ref>

<!--

Line 607 ⟶ 609:

</syntaxhighlight>

The {{rust|#[repr(C)]}} attribute enables deterministic memory layouts for {{rust|struct}}s and {{rust|enum}}s for use across FFI boundaries.{{sfn|Gjengset|2021|pp=193-209}} External libraries such as {{coderust|bindgen}} and {{coderust|cxx}} can generate Rust bindings for C/C++.{{sfn|Gjengset|2021|pp=193-209}}<ref>{{Cite web|title=Safe Interoperability between Rust and C++ with CXX|url=https://www.infoq.com/news/2020/12/cpp-rust-interop-cxx/|date=2020-12-06|access-date=2021-01-03|website=InfoQ|language=en|archive-date=January 22, 2021|archive-url=https://web.archive.org/web/20210122142035/https://www.infoq.com/news/2020/12/cpp-rust-interop-cxx/|url-status=live}}</ref>

== Ecosystem ==

Line 637 ⟶ 639:

Following Rust 1.0, new features are developed in ''nightly'' versions which are released daily. During each six-week release cycle, changes to nightly versions are released to beta, while changes from the previous beta version are released to a new stable version.<ref name="Rust Book G">{{harvnb|Klabnik|Nichols|2019|loc=Appendix G – How Rust is Made and "Nightly Rust"}}</ref>

Every two or three years, a new "edition" is produced. Editions are released to allow making limited [[breaking changes]], such as promoting {{coderust|await}} to a keyword to support [[async/await]] features. Crates targeting different editions can interoperate with each other, so a crate can upgrade to a new edition even if its callers or its dependencies still target older editions. Migration to a new edition can be assisted with automated tooling.{{sfn|Blandy|Orendorff|Tindall|2021|pp=176–177}}

=== IDE support ===

Line 670 ⟶ 672:

[[Discord]], an [[instant messaging]] software company, rewrote parts of its system in Rust for increased performance in 2020. In the same year, Dropbox announced that its [[file synchronization]] had been rewritten in Rust. [[Facebook]] ([[Meta Platforms|Meta]]) used Rust to redesign its system that manages source code for internal projects.<ref name="MITTechReview" />

In the 20242025 [[Stack Overflow]] Developer Survey, 1214.68% of respondents had recently done extensive development in Rust.<ref name="SO-20242025-survey">{{Cite web |title=20242025 Stack Overflow Developer Survey – Technology |url=https://survey.stackoverflow.co/20242025/technology |access-date=20242025-1108-2809 |website=[[Stack Overflow]]}}</ref> The survey named Rust the "most admired programming language" annually from 2016 to 20242025 (inclusive), as measured by the number of existing developers interested in continuing to work in the language.<ref>{{Cite web |last=Claburn |first=Thomas |date=2022-06-23 |title=Linus Torvalds says Rust is coming to the Linux kernel |url=https://www.theregister.com/2022/06/23/linus_torvalds_rust_linux_kernel/ |access-date=2022-07-15 |website=[[The Register]] |language=en |archive-date=2022-07-28 |archive-url=https://web.archive.org/web/20220728221531/https://www.theregister.com/2022/06/23/linus_torvalds_rust_linux_kernel/ |url-status=live }}</ref>{{refn|group=note|That is, among respondents who have done "extensive development work [with Rust] in over the past year" (1214.68%), Rust had the largest percentage who also expressed interest to "work in [Rust] over the next year" (8272.24%).<ref name="SO-20242025-survey"/>}} In 20242025, 2829.72% of developers not currently working in Rust expressed an interest in doing so.<ref name="SO-20242025-survey" />

[[DARPA]] has a project TRACTOR (Translating All C to Rust) automatically translating C to Rust using techniques such as static analysis, dynamic analysis, and large language models.<ref>{{cite web |last1=Wallach |first1=Dan |title=TRACTOR: Translating All C to Rust |url=https://www.darpa.mil/research/programs/translating-all-c-to-rust |publisher=[[DARPA]] |access-date=3 August 2025}}</ref>