wezm.net/content/technical/2018/01/rust-2018.md

_This is my response to the [call for community blog posts reflecting on
Rust][rust2018] in 2017 and proposing goals and directions for 2018. See also
[#Rust2018 on Twitter][#Rust2018]._

2017 saw some great progress in the Rust space. The project had a [clear roadmap for the
year][rust-roadmap] and followed it quite closely. It was a pleasure to see the
outcomes of the 2017 survey systematically addressed in the roadmap.

Over the course of the year we saw some software outside of Firefox and developer tools (such
as [rustfmt], [racer], [rustup]) gain wider use and  make it into OS package archives.
At the time of writing there are [17 ports dependant on rust in the FreeBSD ports tree][rust-ports], and [20 packages in the Arch Linux package repos][arch-rust] including:

- [bingrep](https://github.com/m4b/bingrep) --- grep for binaries (executables)
- [pijul](https://pijul.org/) --- distributed version control system
- [tokei](https://github.com/Aaronepower/tokei) --- count lines of code, quickly
- [xi-core](https://github.com/google/xi-editor) --- a text editor
- [librespot](https://github.com/plietar/librespot) --- Open source Spotify client library
- [exa](https://the.exa.website/) --- a more user friendly replacement for `ls`
- [fd](https://github.com/sharkdp/fd) --- a more user friendly alternative to `find`
- [flowgger](https://github.com/jedisct1/flowgger) --- a fast log data collector
- [ripgrep](https://github.com/BurntSushi/ripgrep/) --- a faster alternative to grep and ack
- [xsv](https://github.com/BurntSushi/xsv) --- A toolkit for manipulating and extracting data from CSV
- [alacritty](https://github.com/jwilm/alacritty) --- A cross-platform, GPU-accelerated terminal emulator

As I spoke about at the [September Melbourne Rust Meetup][rust-talk], I
think adoption of tools written in Rust, outside the Rust community helps
increase adoption of the language as whole. It means [packaging systems are
updated to support Rust][uses-cargo], tools are exposed to more diverse environments,
and people are more likely to raise bugs or contribute fixes and improvements and maybe
learn Rust in the process.

We also saw the initial release of Futures and [Tokio] --- the initial answer
to how Rust will support asynchronous I/O. I think these components will be
essential in making Rust a viable option for people wanting to build network
daemons and HTTP micro-services that can compete with the likes of
[Node.js][node] and [Go]. I found the fact that they were able to be built in a
way that upholds the, [abstraction without overhead][zero-cost] (zero-cost
abstractions) goal of Rust to be particularly impressive.

## 2018

Four areas that I would like to see Rust improve on in 2018 are:

1. Become a viable alternative to Go and node for building network daemons and HTTP
   micro-services.
1. Continue to improve the discoverability and approacability of crates and
   Rust's web presence in general.
1. Gain wider, more diverse tier-1 platform support (especially on servers).
1. Start delivering on the prospect of safer system components, with fewer
   security holes.

### Network Services

Stabilise async/await. I feel that a lot of folks turn to Go these days when building network daemons
and micro services. To me it feels that the primary thing preventing Rust from parity in this space
is a stable networking, especially HTTP (inluding HTTP2) server.

### Improve Rust's Web Presence

This is in part a continuation of the 2017 goal, [Rust should provide easy
access to high quality crates][rust-crates] and the, [Improve the
Approachability of the Design of rust-lang.org and/or
crates.io](https://blog.rust-lang.org/2017/06/27/Increasing-Rusts-Reach.html#3-improve-the-approachability-of-the-design-of-rust-langorg-andor-cratesio)
proposal in the [Increasing Rust's Reach][rust-reach] program.

Having a consistent, approachable, discoverable, and well designed web presence
makes it easier for visitors to find what they're looking for and adds signals
of credibility, attention to detail, and production readiness to the project.
It would be wonderful to see the proposal above picked and completed.

The large amount of rust code that already exists is not particularly visible
unless you know to look on crates.io or GitHub. Crates and Rust libraries
should be more discoverable through traditional search engines. [Aside from the
static documentation no pages on crates.io show up as search results on
DuckDuckGo][ddg-results]. They do show up in Google but the titles and
descriptions shown often aren't super useful.

When posting links to crates on Twitter or Slack, there is no rich preview,
which would help potential visitors know more about the link and what they
will find there.

<figure>
  <img src="/images/2018/crate-tweet.png" width="586" alt="Screenshot showing how a crate looks when tweeted." />
  <figcaption>How a crate looks when [tweeted](https://twitter.com/mitsuhiko/status/936749790553083905).</figcaption>
</figure>

<figure>
  <img src="/images/2018/npm-tweet.png" width="589" alt="Screenshot showing how an npm package looks when tweeted." />
  <figcaption>How an npm package looks when [tweeted](https://twitter.com/jaredforsyth/status/949497032087146498).</figcaption>
</figure>

The [Rust Cookbook][rust-cookbook] is an excellent resource, especially for
those just starting out. It should graduate from the nursery and be made more
discoverable, perhaps by integrating it with the [categories on
crates.io][crate-categories].

### Platform Support

Currently there are three [OSes with tier 1 support][platform-support]: Linux,
macOS, and Windows.  These are the big three at the moment and it's great that
they're all supported. I would love to see more OSes gain tier 1 support.
Platform diversity makes Rust a viable option for more projects and can also
[help find bugs][llvm-linker-bug].

Personally I would like to see [FreeBSD] promoted to tier 1 support. This would
be difficult at first as CI infrastructure would need to be built, contributors
would need to learn to address issues that would [break the build on
FreeBSD][freebsd-nightly-broken], etc. but in the end it make it easier to add
more platforms in the future and the ecosystem would be more robust for it.

### System Components

- One of Rust strengths is memory safety
  - Jokes about, "Rewrite it Rust", and the [Rust Evangelism Strike Force][resf] aside there has
    been a lot of talk about the possibility for Rust to prevent some common causes of vulnerabilites
    in C and C++ code. It would be nice to see some of this talk turn into action. I'm not talking
    about rewiting LInux or cURL in Rust but:
  - Build replacements for high value system components
    - Replace parts of C libraries
      - Like librsvg
    - Make an API compatible version of a C library
    - Get it to the point where a motivated user could build an Arch, Gentoo
      system with these components instead of the original to start testing. 
      Kind of like the way you can run Wayland

This one is perhaps less of a goal for the Rust project and more of one for the Rust
community. However there are parts of it that relate to the project, such as [improving
the ability for Rust projects to integrate with existing build systems][rust-bulid-systems].


[mgattozzi]: https://mgattozzi.com/rust-wasm
[resf]: https://twitter.com/rustevangelism
[arch-rust]: https://www.archlinux.org/packages/community/x86_64/rust/
[rust-ports]: https://www.freshports.org/search.php?stype=depends_all&method=match&query=lang%2Frust&num=100&orderby=category&orderbyupdown=asc&search=Search&format=html&branch=head
[rust2018]: https://blog.rust-lang.org/2018/01/03/new-years-rust-a-call-for-community-blogposts.html
[#Rust2018]: https://twitter.com/hashtag/Rust2018?src=hash
[rust-roadmap]: https://blog.rust-lang.org/2017/02/06/roadmap.html
[rustfmt]: https://github.com/rust-lang-nursery/rustfmt
[racer]: https://github.com/phildawes/racer
[rustup]: https://github.com/rust-lang-nursery/rustup.rs
[rust-talk]: /technical/2017/09/rust-tools-talk/
[Tokio]: https://tokio.rs/
[node]: https://nodejs.org/
[Go]: https://golang.org/
[uses-cargo]: https://www.freebsd.org/news/status/report-2017-04-2017-06.html#A-New-USES-Macro-for-Porting-Cargo-Based-Rust-Applications
[zero-cost]: http://blog.rust-lang.org/2015/05/11/traits.html
[rust-build-systems]: https://blog.rust-lang.org/2017/12/21/rust-in-2017.html#rust-should-integrate-easily-into-large-build-systems
[rust-servers]: https://blog.rust-lang.org/2017/12/21/rust-in-2017.html#rust-should-be-well-equipped-for-writing-robust-servers
[rust-crates]: https://blog.rust-lang.org/2017/12/21/rust-in-2017.html#rust-should-provide-easy-access-to-high-quality-crates
[rust-reach]: https://blog.rust-lang.org/2017/06/27/Increasing-Rusts-Reach.html
[rust-cookbook]: https://rust-lang-nursery.github.io/rust-cookbook/
[crate-categories]: https://crates.io/categories
[ddg-results]: https://duckduckgo.com/?q=site%3Acrates.io&t=ffab&ia=web
[platform-support]: https://forge.rust-lang.org/platform-support.html
[llvm-linker-bug]: https://twitter.com/wezm/status/931124516054491137
[freebsd-nightly-broken]: https://github.com/rust-lang/rust/issues/43427
[FreeBSD]: https://www.freebsd.org/