Finish Rust 2018 post

content/technical/2018/01/goals-directions-rust-2018.md

@@ -6,44 +6,47 @@ Rust][rust2018] in 2017 and proposing goals and directions for 2018. See also
 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
+Over the course of the year we saw some software outside of Firefox and
-as [rustfmt], [racer], [rustup]) gain wider use and  make it into OS package archives.
+developer tools (such as [rustfmt], [racer], [rustup]) gain wider use and make
-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:
+it into OS package archives. At the time of writing there are [17 ports
+dependent 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
+- [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
+- [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
+As I spoke about at the [September Melbourne Rust Meetup][rust-talk], I think
-think adoption of tools written in Rust, outside the Rust community helps
+adoption of tools written in Rust outside the Rust community helps increase
-increase adoption of the language as whole. It means [packaging systems are
+adoption of the language as whole. It means [packaging systems are updated to
-updated to support Rust][uses-cargo], tools are exposed to more diverse environments,
+support Rust][uses-cargo], tools are exposed to more diverse environments, and
-and people are more likely to raise bugs or contribute fixes and improvements and maybe
+people are more likely to raise bugs or contribute fixes and improvements. They
-learn Rust in the process.
+may even learn some 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
+[Node.js][node] and [Go]. I found the fact that Futures were architected in a
-way that upholds the, [abstraction without overhead][zero-cost] (zero-cost
+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:
+With most of 2018 ahead there are four areas that I would like to see Rust
+improve on this year:
 
-1. Become a viable alternative to Go and node for building network daemons and HTTP
+1. Become a better option for building network daemons and HTTP
    micro-services.
-1. Continue to improve the discoverability and approacability of crates and
+1. Continue to improve the discoverability and approachability 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
@@ -51,9 +54,19 @@ Four areas that I would like to see Rust improve on in 2018 are:
 
 ### Network Services
 
-Stabilise async/await. I feel that a lot of folks turn to Go these days when building network daemons
+There's a [lot of interest these days in HTTP micro-services][microservices-trend],
-and micro services. To me it feels that the primary thing preventing Rust from parity in this space
+often running in containers on clusters. This is an area that Go does quite well at.
-is a stable networking, especially HTTP (inluding HTTP2) server.
+Its minimal runtime, language level async support, core http library, and easy
+cross compilation make it well suited to this task. Node.js too can work well for
+these types of services. On the face of it Rust should be as good or better than
+Go and Node at these types of services with its even smaller runtime footprint,
+sophisticated type system and extra guarantees. However, until Tokio matures it's
+not really in the running.
+
+I would like to see work continue on stabilising [async/await][async-await],
+stabilisation of [Hyper] and support for [HTTP/2][hyper-http2]. So that when
+a decision is being made about which technology to use for these types of services
+Rust is one of the contenders.
 
 ### Improve Rust's Web Presence
 
@@ -68,10 +81,10 @@ 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
+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
+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.
 
@@ -97,36 +110,45 @@ 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
+macOS, and Windows. These are the three most popular OSes and it's great that
-they're all supported. I would love to see more OSes gain tier 1 support.
+they're all supported. However, it would be great to see more OSes gain tier 1
-Platform diversity makes Rust a viable option for more projects and can also
+support. Platform diversity makes Rust a viable option for more projects and
-[help find bugs][llvm-linker-bug].
+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
+FreeBSD][freebsd-nightly-broken], etc. but in the end it would be easier to add
 more platforms in the future and the ecosystem would be more robust for it.
 
-### System Components
+### System Components and Increased Safety
 
-- One of Rust strengths is memory safety
+One of Rust's strengths is memory safety. Jokes about, "Rewrite it Rust", and
-  - Jokes about, "Rewrite it Rust", and the [Rust Evangelism Strike Force][resf] aside there has
+the [Rust Evangelism Strike Force][resf] aside there has been a lot of talk
-    been a lot of talk about the possibility for Rust to prevent some common causes of vulnerabilites
+about the possibility for Rust to prevent some common causes of vulnerabilities
-    in C and C++ code. It would be nice to see some of this talk turn into action. I'm not talking
+in C and C++ code. It would be nice to see some of this talk turn into action.
-    about rewiting LInux or cURL in Rust but:
+I'm not talking about rewiting Linux or [cURL] in Rust but start with replacing
-  - Build replacements for high value system components
+some high value parts of existing C libraries like what Federico Mena-Quintero
-    - Replace parts of C libraries
+has done with [librsvg].
-      - 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
+Maybe these start as forks/experimental branches that can be used as drop in
-community. However there are parts of it that relate to the project, such as [improving
+substitutes for the original so that adventurous users on bleeding edge systems
-the ability for Rust projects to integrate with existing build systems][rust-bulid-systems].
+like Arch, FreeBSD, or Gentoo could test them out.
 
+While this is perhaps less of a goal for the Rust project and more of one for
+the Rust community there are parts of it that relate to the project. For
+example building these hybrid libraries would surely exercise and provide
+feedback for the ongoing task to [improve the ability for Rust projects to
+integrate with existing build systems][rust-build-systems].
+
+## Conclusion
+
+So they are my hopes and dreams for Rust in 2018. I feel that in some ways I'm
+just sitting back telling other people about all the hard work they should do.
+On the other hand I feel like I am contributing as well by writing and
+publishing Rust code, doing talks, and providing bug reports and pull requests.
+
+Here's to another successful year of Rust ahead!
 
 [mgattozzi]: https://mgattozzi.com/rust-wasm
 [resf]: https://twitter.com/rustevangelism
@@ -155,3 +177,9 @@ the ability for Rust projects to integrate with existing build systems][rust-bul
 [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/
+[cURL]: https://curl.haxx.se/
+[librsvg]: https://people.gnome.org/~federico/news-2016-10.html#25
+[microservices-trend]: https://trends.google.com/trends/explore?date=today%205-y&q=microservices
+[Hyper]: https://hyper.rs/
+[async-await]: https://github.com/rust-lang/rfcs/issues/1081
+[hyper-http2]: https://github.com/hyperium/hyper/issues/304

content/technical/2018/01/goals-directions-rust-2018.yaml

@@ -0,0 +1,9 @@
+---
+title: Goals and Directions for Rust in 2018
+extra: Reflecting on Rust in 2017 and what might be worth focussing on in 2018.
+kind: article
+section: technical
+created_at: 2018-01-07 13:07:00.000000000 +11:00
+keywords:
+- rust
+short_url: http://j.mp/2CCHJ48

content/technical/2018/01/rust-2018.yaml

@@ -1,9 +0,0 @@
----
-title: Rust 2017
-extra: Reflecting on Rust in 2017 and looking to the year ahead.
-kind: article
-section: technical
-created_at: 2018-01-05 20:54:00.000000000 +11:00
-keywords:
-- rust
-short_url: 

content/technical/2018/01/software-contributions-2017.yaml

@@ -1,7 +1,7 @@
 ---
 title: Software Contributions 2017
-extra: In 2017 I tried to support more of the projects I use. This
+extra: In 2017 I tried to support more of the projects I use. This is a summary of
-  is a summary of how I went.
+  how I went.
 kind: article
 section: technical
 created_at: 2018-01-01 10:14:00.000000000 +11:00