skip to main content
US FlagAn official website of the United States government
dot gov icon
Official websites use .gov
A .gov website belongs to an official government organization in the United States.
https lock icon
Secure .gov websites use HTTPS
A lock ( lock ) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.
Attention:The NSF Public Access Repository (NSF-PAR) system and access will be unavailable from 7:00 AM ET to 7:30 AM ET on Friday, April 24 due to maintenance. We apologize for the inconvenience.


Title: Learning and Programming Challenges of Rust: A Mixed-Methods Study
Rust is a young systems programming language designed to provide both the safety guarantees of high-level languages and the execution performance of low-level languages. To achieve this design goal, Rust provides a suite of safety rules and checks against those rules at the compile time to eliminate many memory-safety and thread-safety issues. Due to its safety and performance, Rust’s popularity has increased significantly in recent years, and it has already been adopted to build many safety-critical software systems. It is critical to understand the learning and programming challenges imposed by Rust’s safety rules. For this purpose, we first conducted an empirical study through close, manual inspection of 100 Rust-related Stack Overflow questions. We sought to understand (1) what safety rules are challenging to learn and program with, (2) under which contexts a safety rule becomes more difficult to apply, and (3) whether the Rust compiler is sufficiently helpful in debugging safety-rule violations. We then performed an online survey with 101 Rust programmers to validate the findings of the empirical study. We invited participants to evaluate program variants that differ from each other, either in terms of violated safety rules or the code constructs involved in the violation, and compared the participants’ performance on the variants. Our mixed-methods investigation revealed a range of consistent findings that can benefit Rust learners, practitioners, and language designers.  more » « less
Award ID(s):
1955965
PAR ID:
10321050
Author(s) / Creator(s):
; ; ; ;
Date Published:
Journal Name:
Proceedings of the 44th International Conference on Software Engineering
Format(s):
Medium: X
Sponsoring Org:
National Science Foundation
More Like this
  1. The Rust Programming Language, developed by Mozilla, has gained popularity for combining performance and memory safety. Its ownership and borrowing mechanisms ensure memory safety and reduce common bugs, making Rust safe. In contrast, Unsafe Rust introduces potential vulnerabilities that can undermine these guarantees and cause difficult security flaws. Unsafe Rust allows low-level operations, interaction with other languages, and optimizations, but bypasses most security checks, so its use should be limited, reviewed, and validated. Static and dynamic code analysis tools help validate that unsafe regions do not contain vulnerabilities. Due to Rust’s rapid growth, documentation of such tools is sparse and difficult to navigate. This research reviews, analyzes, and tests multiple static code analysis tools, aiming to provide developers with a comprehensive resource tailored to Unsafe Rust. The results include insights into each tool’s functionality, strengths, weaknesses, and use cases, equipping developers to write safer, more secure, and reliable Rust code. 
    more » « less
  2. Programmers learning Rust struggle to understand ownership types, Rust’s core mechanism for ensuring memory safety without garbage collection. This paper describes our attempt to systematically design a pedagogy for ownership types. First, we studied Rust developers’ misconceptions of ownership to create the Ownership Inventory, a new instrument for measuring a person’s knowledge of ownership. We found that Rust learners could not connect Rust’s static and dynamic semantics, such as determining why an ill-typed program would (or would not) exhibit undefined behavior. Second, we created a conceptual model of Rust’s semantics that explains borrow checking in terms of flow-sensitive permissions on paths into memory. Third, we implemented a Rust compiler plugin that visualizes programs under the model. Fourth, we integrated the permissions model and visualizations into a broader pedagogy of ownership by writing a new ownership chapter forThe Rust Programming Language, a popular Rust textbook. Fifth, we evaluated an initial deployment of our pedagogy against the original version, using reader responses to the Ownership Inventory as a point of comparison. Thus far, the new pedagogy has improved learner scores on the Ownership Inventory by an average of 9 
    more » « less
  3. Memory safety is an important property for security-critical systems, but it cannot be easily extended to cryptography, which is a common source of memory safety vulnerabilities. Cryptography libraries use assembly for direct control of timing and performance, but assembly introduces unsafety when it is called from a high-level memory-safe language like Rust. To enable quick and safe integration of assembly into Rust, specifically for building memory-safe cryptography, we present CLAMS. CLAMS verifies cryptographic assembly against safety constraints derived directly from Rust’s type system. Verification is done through symbolic execution at compile time to minimize run-time overheads, and supports verifying loops over potentially unbounded input buffers. CLAMS’s procedural macro interface forces developers to map safe Rust types to registers and define preconditions on input and output parameters. CLAMS’s techniques can verify the memory safety of assembly from a popular open-source cryptography library. We evaluated CLAMS and found that verification is quick and imposes compile-time overheads under 100ms and negligible run-time overheads. 
    more » « less
  4. Rust is a young systems programming language, but it has gained tremendous popularity thanks to its assurance of memory safety. However, the performance of Rust has been less systematically understood, although many people are claiming that Rust is comparable to C/C++ regarding efficiency. In this paper, we aim to understand the performance of Rust, using C as the baseline. First, we collect a set of micro benchmarks where each program is implemented with both Rust and C. To ensure fairness, we manually validate that the Rust version and the C version implement the identical functionality using the same algorithm. Our measurement based on the micro benchmarks shows that Rust is in general slower than C, but the extent of the slowdown varies across different programs. On average, Rust brings a 1.77x “performance overhead” compared to C. Second, we dissect the root causes of the overhead and unveil that it is primarily incurred by run-time checks inserted by the compiler and restrictions enforced by the language design. With the run-time checks disabled and the restrictions loosened, Rust presents a performance indistinguishable from C. 
    more » « less
  5. This paper documents a year-long experiment to “profile” the process of learning a programming language: gathering data to understand what makes a language hard to learn, and using that data to improve the learning process. We added interactive quizzes to The Rust Programming Language, the official textbook for learning Rust. Over 13 months, 62,526 readers answered questions 1,140,202 times. First, we analyze the trajectories of readers. We find that many readers drop-out of the book early when faced with difficult language concepts like Rust’s ownership types. Second, we use classical test theory and item response theory to analyze the characteristics of quiz questions. We find that better questions are more conceptual in nature, such as asking why a program does not compile vs. whether a program compiles. Third, we performed 12 interventions into the book to help readers with difficult questions. We find that on average, interventions improved quiz scores on the targeted questions by +20 
    more » « less