Development

Toward a more approachable Rust

February 22, 2017

This article was contributed by Eddie Kovsky

The Rust programming language is designed with the principle that developers should never have to choose between performance and safety. While performance has long been the domain of the C programming language, C can often be the source of security bugs. Rust might one day be a viable replacement, but it is still maturing. This year, the project's leaders are changing their focus to make sure the Rust ecosystem can continue to grow.

C has long been the workhorse of low-level development. It has held up remarkably well over the years. As its creator once quipped: "C is quirky, flawed, and an enormous success." C grants programmers the freedom to write high-performance code that is virtually unmatched by any other language. That freedom also comes with its own pitfalls. There is even a book devoted to the subject. That same freedom creates the opportunity to introduce bugs that would not be possible in a higher-level language.

Rust has a strict type system that is designed to eliminate most of the memory-management errors that are a common source of bugs in low-level languages. (Rust's feature list even includes "guaranteed memory safety".) Rust introduces some new ideas not seen in other mainstream languages that make this possible. But these unique features, combined with Rust's rich syntax, may also be a barrier to the widespread adoption of the language.

Rust aims to match the performance characteristics of C while eliminating the safety risks. This is not enough, however, to guarantee its success. The Rust project leaders have decided that the biggest challenge facing the language is improving the on-boarding process for new programmers. While Rust is still young, the first stable release was in May 2015, most of the design and technical features are set in place. In 2017, there will not be any focus on new changes to the language or the standard library:

[...] our primary challenge isn't making Rust "better" in the abstract; it's making people productive with Rust. The need is most pronounced in the early stages of Rust learning, where we risk losing a large pool of interested people if we can't get them over the hump. Evidence from the survey and elsewhere suggests that once people do get over the initial learning curve, they tend to stick around.

When the Rust project conducted its 2016 survey it asked users what stood in the way of being able to use Rust. The top responses received were:

1 in 4: learning curve
1 in 7: lack of libraries
1 in 9: general "maturity" concerns

Some of the top priorities this year include improving documentation, for example a new version of the Rust book is under development, improving error messages generated by the compiler, and refining editor integration and other tooling. The full details are available in the 2017 roadmap.

A real-world test

Mozilla, which also sponsors the Rust project, has already started shipping Rust components in Firefox. Recently, another high-profile project had the opportunity to explore if Rust could actually replace C. The NTPsec project, which is intended to replace the Network Time Protocol (NTP) reference implementation, has a large code base written in C. Eric Raymond, who is working on NTPsec, has already completed a major cleanup of the existing code. He is also considering a complete rewrite in either Rust or Go.

In theory, Rust looked like a clear winner over Go and could even be a viable replacement for C. Rust is more "C-like", with machine code output, no garbage collection, and a stricter type system than Go. But Raymond concluded that Rust not only did not fit the project's needs, but that in its current state, Rust is unfit for production. The immaturity of the Rust ecosystem and the language syntax created a tax on productivity:

In practice, I found Rust painful to the point of near unusability, The learning curve was far worse than I expected; it took me those four days of struggling with inadequate documentation to write 67 lines of wrapper code for the server.

Even things that should be dirt-simple in Rust, like string concatenation, are unreasonably difficult. The language demands a huge amount of fussy, obscure ritual before you can get anything done.

The contrast with Go is extreme. By four days in of exploring Go I had mastered most of the language, had a working program and tests, and was adding features to taste.

Instead of a community design process, Raymond wonders if the Rust project might benefit from a single "Benevolent Dictator" (or a "core team" of some kind) making decisions. There is some evidence for the need for this in other parts of the language. Rust's type system lays the groundwork for concurrency, but the implementation is provided by libraries and is not part of the core language. According to the Rust documentation, this was a deliberate design decision to give programmers flexibility in their code:

Before we talk about the concurrency features that come with Rust, it's important to understand something: Rust is low-level enough that the vast majority of this is provided by the standard library, not by the language. This means that if you don't like some aspect of the way Rust handles concurrency, you can implement an alternative way of doing things.

Contrast that with the Go language, whose designers chose to use communicating sequential processes as the formal model to manage concurrency in the language. Signals and channels are first class primitives in Go, which makes it relatively easy to pass messages between threads.

The Rust roadmap does include plans to improve this situation. While the standard library is unlikely to change, there is a renewed focus on improving the quality of packages provided by Rust's third party "crates". Concurrency is one of the specific areas the project developers would like to improve. There is also work underway to improve the overall maturity of the ecosystem, including a ranking system for packages.

While Go's focus on programmer productivity may make it a better fit for NTPsec, Raymond hasn't actually committed to rewriting any of the remaining C code. In the meantime, the Rust project is listening to its critics. With the renewed focus on improving the language's usability, Rust is likely to become a more competitive choice for a wider variety of use cases. But that is all in the future. Until then, C will remain a safe bet.

Comments (53 posted)

Brief items

Development quotes of the week

Makefiles, where whitespace is the cause of, and solution to, all of your problems.

— msbarnett (Thanks to Josh Triplett)

This is really intriguing. I suspected your build environment must have been weird, but it looks fine to me. The likely elephant in the room is the single processor. I'm pretty amazed that this seems to be a stumbling block, but there we go.

— Jonathan Dowland [context here] (Thanks to Paul Wise)

Comments (none posted)

Go 1.8 released

The Go team has announced the release of Go 1.8. "The compiler back end introduced in Go 1.7 for 64-bit x86 is now used on all architectures, and those architectures should see significant performance improvements. For instance, the CPU time required by our benchmark programs was reduced by 20-30% on 32-bit ARM systems. There are also some modest performance improvements in this release for 64-bit x86 systems. The compiler and linker have been made faster. Compile times should be improved by about 15% over Go 1.7. There is still more work to be done in this area: expect faster compilation speeds in future releases." See the release notes for more details.

Comments (1 posted)

SystemTap 3.1 has been released

The SystemTap team has announced the 3.1 release of the tool that allows extracting performance and debugging information at runtime from the kernel as well as various user-space programs. New features include support for adding probes to Python 2 and 3 functions, Java probes now convert all parameters to strings before passing them to probes, a new @variance() statistical operator has been added, new sample scripts have been added, and more.

Full Story (comments: 3)

The "Upspin" global filesystem

A group of Google developers has announced the release of (an early version of) a new global filesystem called "Upspin". "Upspin looks a bit like a global file system, but its real contribution is a set of interfaces, protocols, and components from which an information management system can be built, with properties such as security and access control suited to a modern, networked world. Upspin is not an 'app' or a web service, but rather a suite of software components, intended to run in the network and on devices connected to it, that together provide a secure, modern information storage and sharing network."

Comments (3 posted)

Newsletters and articles

Development newsletters

Emacs news (February 20)
What's cooking in git.git (February 16)
What's cooking in git.git (February 21)
OCaml Weekly News (February 21)
Perl Weekly (February 20)
PostgreSQL Weekly News (February 19)
Python Weekly (February 16)
Ruby Weekly (February 16)
This Week in Rust (February 21)
Tahoe-LAFS Weekly News (February 20)
Wikimedia Tech News (February 20)

Comments (none posted)

A draft glibc year-2038 design document

The year-2038 apocalypse is now just under 21 years away. For those who are curious about how the GNU C Library plans to deal with this problem, there is a draft design document out for review. "In order to avoid duplicating APIs for 32-bit and 64-bit time, glibc will provide either one but not both for a given application; the application code will have to choose between 32-bit or 64-bit time support, and the same set of symbols (e.g. time_t or clock_gettime) will be provided in both cases."

Comments (9 posted)

Internet-enable your microcontroller projects for under $6 with ESP8266 (Opensource.com)

David Egts takes a look at the ESP8266 WiFi chip, on Opensource.com. "What is the ESP8266 exactly? The ESP8266 is a 32-bit RISC CPU made by Espressif Systems. Its clock runs at 80MHz, and it supports up to 16MB of flash RAM for program storage. These specifications are quite impressive when compared to an Arduino UNO, which runs at 16MHz, only has 32KB of RAM, and is several times more expensive. Another big difference is that the ESP8266 requires only 3.3 volts of power while most Arduinos require 5 volts. Keep this voltage difference in mind when extending your existing Arduino knowledge and projects to the ESP8266 to prevent magic smoke."

Comments (29 posted)

Turunen: Qt Roadmap for 2017

Tuukka Turunen presents a roadmap for Qt. "Qt 3D was first released with Qt 5.7 and in Qt 5.8 the focus was mostly on stability and performance. With Qt 5.9 we are providing many new features which significantly improve the functionality of Qt 3D. Notable new features include support for mesh morphing and keyframe animations, using Qt Quick items as a texture for 3D elements, as well as support for physically based rendering and particles. There are also multiple smaller features and improvements throughout the Qt 3D module."

Comments (2 posted)

Page editor: Rebecca Sobol
Next page: Announcements>>