Rust 2018: Libraries in the 2018 Epoch - zayenz.seMenu

← Back to all blog posts← Newer<br>Older →

Rust 2018: Libraries in the 2018 EpochDRAFT<br>2018-01-23•10 min read•Cite<br>•rustprogramming

_p]:my-0<br>[&_li_>_ul]:my-2<br>[&_li_>_ol]:my-2<br>[&_a]:text-primary [&_a]:hover:underline [&_a]:font-medium<br>[&_blockquote]:max-w-[72ch] [&_blockquote]:border-l-4 [&_blockquote]:border-accent [&_blockquote]:pl-4 [&_blockquote]:italic [&_blockquote]:text-muted-foreground [&_blockquote]:my-4<br>[&_pre]:bg-muted [&_pre]:p-4 [&_pre]:rounded-lg [&_pre]:overflow-x-auto [&_pre]:my-4<br>[&_pre_code]:bg-transparent [&_pre_code]:p-0<br>[&_code]:bg-muted [&_code]:text-foreground [&_code]:px-1.5 [&_code]:py-1 [&_code]:rounded<br>[&_hr]:border-t [&_hr]:border-accent [&_hr]:my-8<br>[&_section[data-footnotes]]:mt-12 [&_section[data-footnotes]]:pt-0<br>[&_section[data-footnotes]]:border-t [&_section[data-footnotes]]:border-accent/60<br>[&_section[data-footnotes]]:text-sm [&_section[data-footnotes]_ol]:mt-1<br>[&_section[data-footnotes]_p]:my-2<br>[&_strong]:font-bold<br>[&_em]:italic<br>[&_table]:w-full [&_table]:my-4 [&_table]:border-collapse<br>[&_th]:border [&_th]:border-accent [&_th]:p-2 [&_th]:text-left [&_th]:font-semibold<br>[&_td]:border [&_td]:border-accent [&_td]:p-2<br>[&_img]:rounded-lg [&_img]:my-4<br>">The call for community blog posts has inspired lots of great responses. Most of the things that I feel are important have already been said. This post is a collection of thoughts on what I feel is important specifically for Rust to flourish in the future. It is perhaps a bit late in the process, but it may add some new perspectives.

Addendum 2018-02-01: When I wrote this post, I thought that the<br>epoch would come after 2018, not in the middle. Given the much<br>shorter time frame, the official<br>plan to postpone all<br>changes) to generic types (generic associated types, specialization,<br>and const generics) until after the epoch is very reasonable.

How should we prioritize?#

If we are to set up a list of goals to do, this means that we need to<br>prioritize what is important. As a natural consequence of this, we<br>also need to decide what not to do. A to do list that includes<br>everything is meaningless, since it gives us no guidance at all.

To effectively prioritize, there needs to be a goal that we want to<br>reach. In my view, there are two things that we should consider in<br>order to define the goal for the year to come.

The epochalypse cometh…#

It is planned to introduce a new<br>epoch<br>for Rust in 2018. According to the RFC, “the [epoch] concept is<br>primarily about putting together a coherent package.” The phrasing<br>indicates that the idea is to deliver a set of features that play well<br>togheter for the programmer to express themselves. That there is to be<br>an epoch in 2018 sets the time-frame for when these features need to<br>be available.

Libraries, libraries, libraries, libraries, …#

A language may be the best possible language for writing a program in,<br>but the amount of code any one developer or team is capable of writing<br>is limited. To produce something larger, relying on libraries is a<br>must.

The libraries available for a language defines the experience of<br>writing production code in that language. Rust has, through the crate<br>eco-system, a very good infrastructure for accessing and using<br>existing libraries. Many of these libraries are of very good quality,<br>and some are real joys to use. Expanding the number of high-quality<br>libraries is of course important, but more important is to consider<br>what kind of libraries are possible to write.

What to prioritize#

Given that writing libraries in the 2018 epoch of Rust is a worthy<br>goal, what would this goal mean more concretely?

What library…?#

This post has mentioned libraries several times, but it is important<br>to discuss what kinds of libraries are meant. There are several types of<br>libraries to consider, and they may have very different requirements<br>for language evolution. I’ve tried to divide it into three groups:<br>utilities, foundational, and applications. The division is of course<br>arbitrary, but may be useful for discussion.

Utility libraries are libraries that solve some specfic recurring task<br>that is not the main focus of the application. Utility libraries are<br>the bread and butter of libraries, and they are used in very many<br>contexts.

Foundational (or extension) libraries are libraries that either<br>significantly raises the level of abstraction for the code, or that<br>more or less enable the user to do new things with the language. This<br>category of libraries are the things that takes a language into new<br>domains of usage. Often, these libraries may have a large effect on<br>how the rest of the code is written.

An application library is something that fits with the specific needs<br>of a certain application. These kinds of libraries may in some cases<br>be frameworks, in that the whole application is structured around<br>them. Sometimes, they onyl affect part of the code.

To make the categories more concrete, the following list shows some<br>libraries in the...