From ef7f833c1fa907223f80a3a4af407cfcb11b38ef Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Mon, 8 Sep 2014 12:50:27 -0700 Subject: [PATCH 01/74] Initial --- .gitignore | 1 + _config.yml | 14 ++ _includes/footer.html | 55 +++++ _includes/head.html | 11 + _includes/header.html | 27 +++ _layouts/default.html | 20 ++ _layouts/page.html | 14 ++ _layouts/post.html | 15 ++ _posts/2014-09-08-welcome-to-jekyll.markdown | 25 ++ _sass/_base.scss | 203 ++++++++++++++++ _sass/_layout.scss | 236 +++++++++++++++++++ _sass/_syntax-highlighting.scss | 67 ++++++ about.md | 11 + css/main.scss | 49 ++++ feed.xml | 30 +++ index.html | 23 ++ 16 files changed, 801 insertions(+) create mode 100644 .gitignore create mode 100644 _config.yml create mode 100644 _includes/footer.html create mode 100644 _includes/head.html create mode 100644 _includes/header.html create mode 100644 _layouts/default.html create mode 100644 _layouts/page.html create mode 100644 _layouts/post.html create mode 100644 _posts/2014-09-08-welcome-to-jekyll.markdown create mode 100644 _sass/_base.scss create mode 100644 _sass/_layout.scss create mode 100644 _sass/_syntax-highlighting.scss create mode 100644 about.md create mode 100755 css/main.scss create mode 100644 feed.xml create mode 100644 index.html diff --git a/.gitignore b/.gitignore new file mode 100644 index 000000000..c08f9add7 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +_site \ No newline at end of file diff --git a/_config.yml b/_config.yml new file mode 100644 index 000000000..2f03e74d4 --- /dev/null +++ b/_config.yml @@ -0,0 +1,14 @@ +# Site settings +title: Your awesome title +email: your-email@domain.com +description: > # this means to ignore newlines until "baseurl:" + Write an awesome description for your new site here. You can edit this + line in _config.yml. It will appear in your document head meta (for + Google search results) and in your feed.xml site description. +baseurl: "" # the subpath of your site, e.g. /blog/ +url: "http://yourdomain.com" # the base hostname & protocol for your site +twitter_username: jekyllrb +github_username: jekyll + +# Build settings +markdown: kramdown diff --git a/_includes/footer.html b/_includes/footer.html new file mode 100644 index 000000000..be3976f7e --- /dev/null +++ b/_includes/footer.html @@ -0,0 +1,55 @@ + diff --git a/_includes/head.html b/_includes/head.html new file mode 100644 index 000000000..ec8f7ca5f --- /dev/null +++ b/_includes/head.html @@ -0,0 +1,11 @@ + + + + + + {% if page.title %}{{ page.title }}{% else %}{{ site.title }}{% endif %} + + + + + diff --git a/_includes/header.html b/_includes/header.html new file mode 100644 index 000000000..cfe381f75 --- /dev/null +++ b/_includes/header.html @@ -0,0 +1,27 @@ +
+ +
+ + {{ site.title }} + + + +
+ +
diff --git a/_layouts/default.html b/_layouts/default.html new file mode 100644 index 000000000..e4ab96fb0 --- /dev/null +++ b/_layouts/default.html @@ -0,0 +1,20 @@ + + + + {% include head.html %} + + + + {% include header.html %} + +
+
+ {{ content }} +
+
+ + {% include footer.html %} + + + + diff --git a/_layouts/page.html b/_layouts/page.html new file mode 100644 index 000000000..74c1a1184 --- /dev/null +++ b/_layouts/page.html @@ -0,0 +1,14 @@ +--- +layout: default +--- +
+ +
+

{{ page.title }}

+
+ +
+ {{ content }} +
+ +
diff --git a/_layouts/post.html b/_layouts/post.html new file mode 100644 index 000000000..a2b4e52fe --- /dev/null +++ b/_layouts/post.html @@ -0,0 +1,15 @@ +--- +layout: default +--- +
+ +
+

{{ page.title }}

+

{{ page.date | date: "%b %-d, %Y" }}{% if page.author %} • {{ page.author }}{% endif %}{% if page.meta %} • {{ page.meta }}{% endif %}

+
+ +
+ {{ content }} +
+ +
diff --git a/_posts/2014-09-08-welcome-to-jekyll.markdown b/_posts/2014-09-08-welcome-to-jekyll.markdown new file mode 100644 index 000000000..df6a3dc0e --- /dev/null +++ b/_posts/2014-09-08-welcome-to-jekyll.markdown @@ -0,0 +1,25 @@ +--- +layout: post +title: "Welcome to Jekyll!" +date: 2014-09-08 12:48:43 +categories: jekyll update +--- +You’ll find this post in your `_posts` directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run `jekyll serve --watch`, which launches a web server and auto-regenerates your site when a file is updated. + +To add new posts, simply add a file in the `_posts` directory that follows the convention `YYYY-MM-DD-name-of-post.ext` and includes the necessary front matter. Take a look at the source for this post to get an idea about how it works. + +Jekyll also offers powerful support for code snippets: + +{% highlight ruby %} +def print_hi(name) + puts "Hi, #{name}" +end +print_hi('Tom') +#=> prints 'Hi, Tom' to STDOUT. +{% endhighlight %} + +Check out the [Jekyll docs][jekyll] for more info on how to get the most out of Jekyll. File all bugs/feature requests at [Jekyll’s GitHub repo][jekyll-gh]. If you have questions, you can ask them on [Jekyll’s dedicated Help repository][jekyll-help]. + +[jekyll]: http://jekyllrb.com +[jekyll-gh]: https://github.com/jekyll/jekyll +[jekyll-help]: https://github.com/jekyll/jekyll-help diff --git a/_sass/_base.scss b/_sass/_base.scss new file mode 100644 index 000000000..d0fa8dcd8 --- /dev/null +++ b/_sass/_base.scss @@ -0,0 +1,203 @@ +/** + * Reset some basic elements + */ +body, h1, h2, h3, h4, h5, h6, +p, blockquote, pre, hr, +dl, dd, ol, ul, figure { + margin: 0; + padding: 0; +} + + + +/** + * Basic styling + */ +body { + font-family: $base-font-family; + font-size: $base-font-size; + line-height: $base-line-height; + font-weight: 300; + color: $text-color; + background-color: $background-color; +} + + + +/** + * Set `margin-bottom` to maintain vertycal rhythm + */ +h1, h2, h3, h4, h5, h6, +p, blockquote, pre, +ul, ol, dl, figure, +%vertical-rhythm { + margin-bottom: $spacing-unit / 2; +} + + + +/** + * Images + */ +img { + max-width: 100%; + vertical-align: middle; +} + + + +/** + * Figures + */ +figure > img { + display: block; +} + +figcaption { + font-size: $small-font-size; +} + + + +/** + * Lists + */ +ul, ol { + margin-left: $spacing-unit; +} + +li { + > ul, + > ol { + margin-bottom: 0; + } +} + + + +/** + * Headings + */ +h1, h2, h3, h4, h5, h6 { + font-weight: 300; +} + + + +/** + * Links + */ +a { + color: $brand-color; + text-decoration: none; + + &:visited { + color: darken($brand-color, 15%); + } + + &:hover { + color: $text-color; + text-decoration: underline; + } +} + + + +/** + * Blockquotes + */ +blockquote { + color: $grey-color; + border-left: 4px solid $grey-color-light; + padding-left: $spacing-unit / 2; + font-size: 18px; + letter-spacing: -1px; + font-style: italic; + + > :last-child { + margin-bottom: 0; + } +} + + + +/** + * Code formatting + */ +pre, +code { + font-size: 15px; + border: 1px solid $grey-color-light; + border-radius: 3px; + background-color: #eef; +} + +code { + padding: 1px 5px; +} + +pre { + padding: 8px 12px; + overflow-x: scroll; + + > code { + border: 0; + padding-right: 0; + padding-left: 0; + } +} + + + +/** + * Wrapper + */ +.wrapper { + max-width: -webkit-calc(800px - (#{$spacing-unit} * 2)); + max-width: calc(800px - (#{$spacing-unit} * 2)); + margin-right: auto; + margin-left: auto; + padding-right: $spacing-unit; + padding-left: $spacing-unit; + @extend %clearfix; + + @include media-query($on-laptop) { + max-width: -webkit-calc(800px - (#{$spacing-unit})); + max-width: calc(800px - (#{$spacing-unit})); + padding-right: $spacing-unit / 2; + padding-left: $spacing-unit / 2; + } +} + + + +/** + * Clearfix + */ +%clearfix { + + &:after { + content: ""; + display: table; + clear: both; + } +} + + + +/** + * Icons + */ +.icon { + + > svg { + display: inline-block; + width: 16px; + height: 16px; + vertical-align: middle; + + path { + fill: $grey-color; + } + } +} diff --git a/_sass/_layout.scss b/_sass/_layout.scss new file mode 100644 index 000000000..def56f896 --- /dev/null +++ b/_sass/_layout.scss @@ -0,0 +1,236 @@ +/** + * Site header + */ +.site-header { + border-top: 5px solid $grey-color-dark; + border-bottom: 1px solid $grey-color-light; + min-height: 56px; + + // Positioning context for the mobile navigation icon + position: relative; +} + +.site-title { + font-size: 26px; + line-height: 56px; + letter-spacing: -1px; + margin-bottom: 0; + float: left; + + &, + &:visited { + color: $grey-color-dark; + } +} + +.site-nav { + float: right; + line-height: 56px; + + .menu-icon { + display: none; + } + + .page-link { + color: $text-color; + line-height: $base-line-height; + + // Gaps between nav items, but not on the first one + &:not(:first-child) { + margin-left: 20px; + } + } + + @include media-query($on-palm) { + position: absolute; + top: 9px; + right: 30px; + background-color: $background-color; + border: 1px solid $grey-color-light; + border-radius: 5px; + text-align: right; + + .menu-icon { + display: block; + float: right; + width: 36px; + height: 26px; + line-height: 0; + padding-top: 10px; + text-align: center; + + > svg { + width: 18px; + height: 15px; + + path { + fill: $grey-color-dark; + } + } + } + + .trigger { + clear: both; + display: none; + } + + &:hover .trigger { + display: block; + padding-bottom: 5px; + } + + .page-link { + display: block; + padding: 5px 10px; + } + } +} + + + +/** + * Site footer + */ +.site-footer { + border-top: 1px solid $grey-color-light; + padding: $spacing-unit 0; +} + +.footer-heading { + font-size: 18px; + margin-bottom: $spacing-unit / 2; +} + +.contact-list, +.social-media-list { + list-style: none; + margin-left: 0; +} + +.footer-col-wrapper { + font-size: 15px; + color: $grey-color; + margin-left: -$spacing-unit / 2; + @extend %clearfix; +} + +.footer-col { + float: left; + margin-bottom: $spacing-unit / 2; + padding-left: $spacing-unit / 2; +} + +.footer-col-1 { + width: -webkit-calc(35% - (#{$spacing-unit} / 2)); + width: calc(35% - (#{$spacing-unit} / 2)); +} + +.footer-col-2 { + width: -webkit-calc(20% - (#{$spacing-unit} / 2)); + width: calc(20% - (#{$spacing-unit} / 2)); +} + +.footer-col-3 { + width: -webkit-calc(45% - (#{$spacing-unit} / 2)); + width: calc(45% - (#{$spacing-unit} / 2)); +} + +@include media-query($on-laptop) { + .footer-col-1, + .footer-col-2 { + width: -webkit-calc(50% - (#{$spacing-unit} / 2)); + width: calc(50% - (#{$spacing-unit} / 2)); + } + + .footer-col-3 { + width: -webkit-calc(100% - (#{$spacing-unit} / 2)); + width: calc(100% - (#{$spacing-unit} / 2)); + } +} + +@include media-query($on-palm) { + .footer-col { + float: none; + width: -webkit-calc(100% - (#{$spacing-unit} / 2)); + width: calc(100% - (#{$spacing-unit} / 2)); + } +} + + + +/** + * Page content + */ +.page-content { + padding: $spacing-unit 0; +} + +.page-heading { + font-size: 20px; +} + +.post-list { + margin-left: 0; + list-style: none; + + > li { + margin-bottom: $spacing-unit; + } +} + +.post-meta { + font-size: $small-font-size; + color: $grey-color; +} + +.post-link { + display: block; + font-size: 24px; +} + + + +/** + * Posts + */ +.post-header { + margin-bottom: $spacing-unit; +} + +.post-title { + font-size: 42px; + letter-spacing: -1px; + line-height: 1; + + @include media-query($on-laptop) { + font-size: 36px; + } +} + +.post-content { + margin-bottom: $spacing-unit; + + h2 { + font-size: 32px; + + @include media-query($on-laptop) { + font-size: 28px; + } + } + + h3 { + font-size: 26px; + + @include media-query($on-laptop) { + font-size: 22px; + } + } + + h4 { + font-size: 20px; + + @include media-query($on-laptop) { + font-size: 18px; + } + } +} diff --git a/_sass/_syntax-highlighting.scss b/_sass/_syntax-highlighting.scss new file mode 100644 index 000000000..e36627da7 --- /dev/null +++ b/_sass/_syntax-highlighting.scss @@ -0,0 +1,67 @@ +/** + * Syntax highlighting styles + */ +.highlight { + background: #fff; + @extend %vertical-rhythm; + + .c { color: #998; font-style: italic } // Comment + .err { color: #a61717; background-color: #e3d2d2 } // Error + .k { font-weight: bold } // Keyword + .o { font-weight: bold } // Operator + .cm { color: #998; font-style: italic } // Comment.Multiline + .cp { color: #999; font-weight: bold } // Comment.Preproc + .c1 { color: #998; font-style: italic } // Comment.Single + .cs { color: #999; font-weight: bold; font-style: italic } // Comment.Special + .gd { color: #000; background-color: #fdd } // Generic.Deleted + .gd .x { color: #000; background-color: #faa } // Generic.Deleted.Specific + .ge { font-style: italic } // Generic.Emph + .gr { color: #a00 } // Generic.Error + .gh { color: #999 } // Generic.Heading + .gi { color: #000; background-color: #dfd } // Generic.Inserted + .gi .x { color: #000; background-color: #afa } // Generic.Inserted.Specific + .go { color: #888 } // Generic.Output + .gp { color: #555 } // Generic.Prompt + .gs { font-weight: bold } // Generic.Strong + .gu { color: #aaa } // Generic.Subheading + .gt { color: #a00 } // Generic.Traceback + .kc { font-weight: bold } // Keyword.Constant + .kd { font-weight: bold } // Keyword.Declaration + .kp { font-weight: bold } // Keyword.Pseudo + .kr { font-weight: bold } // Keyword.Reserved + .kt { color: #458; font-weight: bold } // Keyword.Type + .m { color: #099 } // Literal.Number + .s { color: #d14 } // Literal.String + .na { color: #008080 } // Name.Attribute + .nb { color: #0086B3 } // Name.Builtin + .nc { color: #458; font-weight: bold } // Name.Class + .no { color: #008080 } // Name.Constant + .ni { color: #800080 } // Name.Entity + .ne { color: #900; font-weight: bold } // Name.Exception + .nf { color: #900; font-weight: bold } // Name.Function + .nn { color: #555 } // Name.Namespace + .nt { color: #000080 } // Name.Tag + .nv { color: #008080 } // Name.Variable + .ow { font-weight: bold } // Operator.Word + .w { color: #bbb } // Text.Whitespace + .mf { color: #099 } // Literal.Number.Float + .mh { color: #099 } // Literal.Number.Hex + .mi { color: #099 } // Literal.Number.Integer + .mo { color: #099 } // Literal.Number.Oct + .sb { color: #d14 } // Literal.String.Backtick + .sc { color: #d14 } // Literal.String.Char + .sd { color: #d14 } // Literal.String.Doc + .s2 { color: #d14 } // Literal.String.Double + .se { color: #d14 } // Literal.String.Escape + .sh { color: #d14 } // Literal.String.Heredoc + .si { color: #d14 } // Literal.String.Interpol + .sx { color: #d14 } // Literal.String.Other + .sr { color: #009926 } // Literal.String.Regex + .s1 { color: #d14 } // Literal.String.Single + .ss { color: #990073 } // Literal.String.Symbol + .bp { color: #999 } // Name.Builtin.Pseudo + .vc { color: #008080 } // Name.Variable.Class + .vg { color: #008080 } // Name.Variable.Global + .vi { color: #008080 } // Name.Variable.Instance + .il { color: #099 } // Literal.Number.Integer.Long +} diff --git a/about.md b/about.md new file mode 100644 index 000000000..3ed64bb62 --- /dev/null +++ b/about.md @@ -0,0 +1,11 @@ +--- +layout: page +title: About +permalink: /about/ +--- + +This is the base Jekyll theme. You can find out more info about customizing your Jekyll theme, as well as basic Jekyll usage documentation at [jekyllrb.com](http://jekyllrb.com/) + +You can find the source code for the Jekyll new theme at: [github.com/jglovier/jekyll-new](https://github.com/jglovier/jekyll-new) + +You can find the source code for Jekyll at [github.com/jekyll/jekyll](https://github.com/jekyll/jekyll) diff --git a/css/main.scss b/css/main.scss new file mode 100755 index 000000000..84bb3a5bf --- /dev/null +++ b/css/main.scss @@ -0,0 +1,49 @@ +--- +# Only the main Sass file needs front matter (the dashes are enough) +--- +@charset "utf-8"; + + + +// Our variables +$base-font-family: Helvetica, Arial, sans-serif; +$base-font-size: 16px; +$small-font-size: $base-font-size * 0.875; +$base-line-height: 1.5; + +$spacing-unit: 30px; + +$text-color: #111; +$background-color: #fdfdfd; +$brand-color: #2a7ae2; + +$grey-color: #828282; +$grey-color-light: lighten($grey-color, 40%); +$grey-color-dark: darken($grey-color, 25%); + +$on-palm: 600px; +$on-laptop: 800px; + + + +// Using media queries with like this: +// @include media-query($palm) { +// .wrapper { +// padding-right: $spacing-unit / 2; +// padding-left: $spacing-unit / 2; +// } +// } +@mixin media-query($device) { + @media screen and (max-width: $device) { + @content; + } +} + + + +// Import partials from `sass_dir` (defaults to `_sass`) +@import + "base", + "layout", + "syntax-highlighting" +; diff --git a/feed.xml b/feed.xml new file mode 100644 index 000000000..022378beb --- /dev/null +++ b/feed.xml @@ -0,0 +1,30 @@ +--- +layout: null +--- + + + + {{ site.title | xml_escape }} + {{ site.description | xml_escape }} + {{ site.url }}{{ site.baseurl }}/ + + {{ site.time | date_to_rfc822 }} + {{ site.time | date_to_rfc822 }} + Jekyll v{{ jekyll.version }} + {% for post in site.posts limit:10 %} + + {{ post.title | xml_escape }} + {{ post.content | xml_escape }} + {{ post.date | date_to_rfc822 }} + {{ post.url | prepend: site.baseurl | prepend: site.url }} + {{ post.url | prepend: site.baseurl | prepend: site.url }} + {% for tag in post.tags %} + {{ tag | xml_escape }} + {% endfor %} + {% for cat in post.categories %} + {{ cat | xml_escape }} + {% endfor %} + + {% endfor %} + + diff --git a/index.html b/index.html new file mode 100644 index 000000000..83d939851 --- /dev/null +++ b/index.html @@ -0,0 +1,23 @@ +--- +layout: default +--- + +
+ +

Posts

+ + + +

subscribe via RSS

+ +
From 1cdc50afd233d7d7189ffb4e034832b2a9b73716 Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Mon, 8 Sep 2014 13:02:00 -0700 Subject: [PATCH 02/74] Add the github-pages gem --- .gitignore | 1 + Gemfile | 1 + 2 files changed, 2 insertions(+) create mode 100644 Gemfile diff --git a/.gitignore b/.gitignore index c08f9add7..78bd97213 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ +.sass-cache _site \ No newline at end of file diff --git a/Gemfile b/Gemfile new file mode 100644 index 000000000..c5d8e4676 --- /dev/null +++ b/Gemfile @@ -0,0 +1 @@ +gem 'github-pages' \ No newline at end of file From 02e144ab86490ab9920da6e208f40f592254dbac Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Mon, 8 Sep 2014 13:08:45 -0700 Subject: [PATCH 03/74] Config --- _config.yml | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/_config.yml b/_config.yml index 2f03e74d4..45daabe43 100644 --- a/_config.yml +++ b/_config.yml @@ -1,14 +1,11 @@ # Site settings -title: Your awesome title -email: your-email@domain.com +title: The Rust Programming Language Blog description: > # this means to ignore newlines until "baseurl:" - Write an awesome description for your new site here. You can edit this - line in _config.yml. It will appear in your document head meta (for - Google search results) and in your feed.xml site description. + Words from the Rust team baseurl: "" # the subpath of your site, e.g. /blog/ -url: "http://yourdomain.com" # the base hostname & protocol for your site -twitter_username: jekyllrb -github_username: jekyll +url: "http://rust-lang.org" +twitter_username: rustlang +github_username: rust-lang # Build settings markdown: kramdown From 34623cf3f9bfbab82dadaad2692d9c49f895484b Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Mon, 8 Sep 2014 13:11:08 -0700 Subject: [PATCH 04/74] Fix canonical URL --- _config.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_config.yml b/_config.yml index 45daabe43..4fddd8eca 100644 --- a/_config.yml +++ b/_config.yml @@ -3,7 +3,7 @@ title: The Rust Programming Language Blog description: > # this means to ignore newlines until "baseurl:" Words from the Rust team baseurl: "" # the subpath of your site, e.g. /blog/ -url: "http://rust-lang.org" +url: "http://blog.rust-lang.org" twitter_username: rustlang github_username: rust-lang From 60e8fd449da8d8f83e6a7e07452933bd6d0677a7 Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Mon, 8 Sep 2014 13:23:58 -0700 Subject: [PATCH 05/74] Add CNAME --- CNAME | 1 + 1 file changed, 1 insertion(+) create mode 100644 CNAME diff --git a/CNAME b/CNAME new file mode 100644 index 000000000..a6d5f4379 --- /dev/null +++ b/CNAME @@ -0,0 +1 @@ +blog.rust-lang.org \ No newline at end of file From a8bf095455c3a2884ca921ce1bae2e0a61ca997e Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Mon, 8 Sep 2014 13:29:01 -0700 Subject: [PATCH 06/74] Bleh --- _config.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_config.yml b/_config.yml index 4fddd8eca..c9e370977 100644 --- a/_config.yml +++ b/_config.yml @@ -1,8 +1,8 @@ # Site settings title: The Rust Programming Language Blog -description: > # this means to ignore newlines until "baseurl:" +description: > Words from the Rust team -baseurl: "" # the subpath of your site, e.g. /blog/ +baseurl: "" url: "http://blog.rust-lang.org" twitter_username: rustlang github_username: rust-lang From 53c82eab08ec23f85dde88b0630e92be1b2149ec Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Mon, 8 Sep 2014 13:40:34 -0700 Subject: [PATCH 07/74] CNAME --- CNAME | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CNAME b/CNAME index a6d5f4379..b7cc76842 100644 --- a/CNAME +++ b/CNAME @@ -1 +1 @@ -blog.rust-lang.org \ No newline at end of file +blog.rust-lang.org From 420589dd0a60cec8dccc34c003b9c16ce4bcb64c Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Mon, 8 Sep 2014 15:34:25 -0700 Subject: [PATCH 08/74] Tweak --- .gitignore | 3 ++- _posts/2014-09-08-welcome-to-jekyll.markdown | 25 ------------------- _posts/2014-09-08-welcome-to-the-rust-blog.md | 6 +++++ about.md | 11 -------- 4 files changed, 8 insertions(+), 37 deletions(-) delete mode 100644 _posts/2014-09-08-welcome-to-jekyll.markdown create mode 100644 _posts/2014-09-08-welcome-to-the-rust-blog.md delete mode 100644 about.md diff --git a/.gitignore b/.gitignore index 78bd97213..6ef5f6739 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,3 @@ .sass-cache -_site \ No newline at end of file +_site +*~ \ No newline at end of file diff --git a/_posts/2014-09-08-welcome-to-jekyll.markdown b/_posts/2014-09-08-welcome-to-jekyll.markdown deleted file mode 100644 index df6a3dc0e..000000000 --- a/_posts/2014-09-08-welcome-to-jekyll.markdown +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: post -title: "Welcome to Jekyll!" -date: 2014-09-08 12:48:43 -categories: jekyll update ---- -You’ll find this post in your `_posts` directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run `jekyll serve --watch`, which launches a web server and auto-regenerates your site when a file is updated. - -To add new posts, simply add a file in the `_posts` directory that follows the convention `YYYY-MM-DD-name-of-post.ext` and includes the necessary front matter. Take a look at the source for this post to get an idea about how it works. - -Jekyll also offers powerful support for code snippets: - -{% highlight ruby %} -def print_hi(name) - puts "Hi, #{name}" -end -print_hi('Tom') -#=> prints 'Hi, Tom' to STDOUT. -{% endhighlight %} - -Check out the [Jekyll docs][jekyll] for more info on how to get the most out of Jekyll. File all bugs/feature requests at [Jekyll’s GitHub repo][jekyll-gh]. If you have questions, you can ask them on [Jekyll’s dedicated Help repository][jekyll-help]. - -[jekyll]: http://jekyllrb.com -[jekyll-gh]: https://github.com/jekyll/jekyll -[jekyll-help]: https://github.com/jekyll/jekyll-help diff --git a/_posts/2014-09-08-welcome-to-the-rust-blog.md b/_posts/2014-09-08-welcome-to-the-rust-blog.md new file mode 100644 index 000000000..93ab59930 --- /dev/null +++ b/_posts/2014-09-08-welcome-to-the-rust-blog.md @@ -0,0 +1,6 @@ +--- +layout: post +title: "Welcome to the Rust blog" +--- + +There's nothing here yet. diff --git a/about.md b/about.md deleted file mode 100644 index 3ed64bb62..000000000 --- a/about.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -layout: page -title: About -permalink: /about/ ---- - -This is the base Jekyll theme. You can find out more info about customizing your Jekyll theme, as well as basic Jekyll usage documentation at [jekyllrb.com](http://jekyllrb.com/) - -You can find the source code for the Jekyll new theme at: [github.com/jglovier/jekyll-new](https://github.com/jglovier/jekyll-new) - -You can find the source code for Jekyll at [github.com/jekyll/jekyll](https://github.com/jekyll/jekyll) From 49e2d55d1934baed3d92444513103b3e9ca913da Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 15 Sep 2014 14:19:05 -0400 Subject: [PATCH 09/74] Initial post --- _posts/2014-09-08-welcome-to-the-rust-blog.md | 6 - _posts/2014-09-15-Rust-1.0.md | 172 ++++++++++++++++++ 2 files changed, 172 insertions(+), 6 deletions(-) delete mode 100644 _posts/2014-09-08-welcome-to-the-rust-blog.md create mode 100644 _posts/2014-09-15-Rust-1.0.md diff --git a/_posts/2014-09-08-welcome-to-the-rust-blog.md b/_posts/2014-09-08-welcome-to-the-rust-blog.md deleted file mode 100644 index 93ab59930..000000000 --- a/_posts/2014-09-08-welcome-to-the-rust-blog.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -layout: post -title: "Welcome to the Rust blog" ---- - -There's nothing here yet. diff --git a/_posts/2014-09-15-Rust-1.0.md b/_posts/2014-09-15-Rust-1.0.md new file mode 100644 index 000000000..a84a4b7b3 --- /dev/null +++ b/_posts/2014-09-15-Rust-1.0.md @@ -0,0 +1,172 @@ +--- +layout: post +title: "Road to Rust 1.0" +--- + +Rust 1.0 is on its way! We have nailed down a concrete list of +features and are hard at work on implementing them. We plan to ship +the 1.0 beta around the end of the year. If all goes well, this will +go on to become the 1.0 release after the beta period. After +1.0 is released, future 1.x releases will be backwards compatible, +meaning that existing code will continue to compile unmodified (modulo +compiler bugs, of course). + +Of course, a Rust 1.0 release means something more than "your code +will continue to compile". Basically, it means that we think the +design of Rust finally feels right. More specifically, it feels +*minimal*. The language itself is now focused on a simple core +concept, which we call ownership and borrowing (more on this +later). Leveraging ownership and borrowing, we are been able to build +up everything else that we have needed in libraries. This is very +exciting, because any library we can write, you can write too. This +really gives us confidence that Rust will not only achieve its +original goals but also go beyond and be used for all kinds of things +that we haven't even envisioned. + +### The road to Rust 1.0 + +Rust has gone through a long evolution. If you haven't looked at Rust +in a while, you may be surprised at what you see: over the last year, +we've been radically simplifying the design. As a prominent example, +Rust once featured several pointer types, indicated by various sigils: +these are gone, and only the reference types (`&T`, `&mut T`) +remain. We have also been able to consolidate and simplify a number of +other language features, such as closures, that once sported a wide +variety of options. (Some of these changes are still in progress.) + +The key to all these changes has been a focus on the core concepts of +*ownership and borrowing*. Initially, we introduced ownership as a +means of transferring data safely and efficiently between tasks, but +over time we have realized that the same mechanism allows us to move +all sorts of things out of the language and into libraries. The +resulting design is not only simpler to learn, but it is also much +"closer to the metal" than we ever thought possible before. All Rust +language constructs have a very direct mapping to machine operations, +and Rust has no required runtime or external dependencies. When used +in its own most minimal configuration, it is even possible to write an +[operating][k1] [systems][k4] [kernel][k2] in Rust. + +Throughout these changes, though, Rust has remained true to its goal +of providing the **safety** and **convenience** of modern programming +languages, while still offering the **efficiency** and **low-level +control** that C and C++ offer. Basically, if you want to get your +hands dirty with the bare metal machine, but you don't want to spend +hours tracking down segfaults and data races, Rust is the language for +you. + +If you're not already familiar with Rust, don't worry. Over the next +few months, we plan on issuing a regular series of blog posts +exploring the language. The first few will focus on different aspects +of ownership and how it can be used to achieve safe manual memory +management, concurrency, and more. After that, we'll turn to other +aspects of the Rust language and ecosystem. + +### What is left to do + +We've made great progress, but there is still a lot to do before the +release. Here is a list of the big-ticket changes we are currently +working on: + +- *Dynamically sized types:* This extension to the type system allows + us to uniformly handle types where the size is not known at compile + time, such as an array type. This enables us to support + user-designed smart pointers that contain arrays or + objects. Nicholas Cameron [recently landed][dst] a heroic commit + implementing the bulk of the work. +- *Unboxed closures:* Our new [closure design][cd] unifies closures + and object types. Much of the spec has been implemented. +- *Associated types:* We are moving our trait system to use + [associated types][at], which really help to cut down on the level + of generic annotations required to write advanced generic + libraries. Patrick Walton has done an initial implementation. +- *Where clauses:* We are adding a flexible new form of constraints + called [where clauses][wc]. Patrick Walton already landed support + for the basic syntax, and I have implemented the remaining + functionality on a branch that should be landing soon. +- *Multidispatch traits:* We are extending traits so that they + can [match on more than one type at a time][at], which opens up a lot of + new opportunities for more ergonomic APIs. I have + prototyped this work on a branch. +- *Destructors:* We are improving our destructor semantics to not + require zeroing of memory, which should improve compilation and + execution times. Felix Klock has implemented the requisite analysis + and is in the process of landing it. +- *Green threading:* We are removing support from green threading from + the standard library and moving it out into an external + package. This allows for a closer match between the Rust model and + the underlying operating system, which makes for more efficient + programs. Aaron Turon has [written the RFC][gt] and is getting + started on that work now. + +At the library level, we are currently engaged in a sweep over libstd +to decide what portions are stable and which are not. You can +[monitor the progress][stability] here. (Note though that many of the +'unstable' items are simply things whose name will be changed slightly +to conform to conventions or other minor tweaks.) + +### Cargo and the library ecosystem + +Earlier I wrote that Rust 1.0 is not so much an endpoint as it is a +starting point. This is very true. The goal for Rust 1.0 is to be an +flexible substrate for building efficient libraries -- but libraries +aren't any good if nobody can find them or they are difficult to install. + +Enter [Cargo, the Rust package manager](http://crates.io). Cargo has +been undergoing rapid development lately and is already quite +functional. By the time +1.0 is released, we plan to also have a central repository up and +wunning, meaning that it will be simple to create and distribute Rust +libraries (which we call "crates"). Oh, and of course Cargo and its +associated server are both written in Rust. + +### Release process + +Rust releases have been following a train schedule for a long time and +we don't plan on changing that. Once we start having stable releases, +however, we'll also build up a bit more infrastructure. Our plan is to +adopt the "channel" system used by many other projects such as +[Firefox](https://www.mozilla.org/en-US/firefox/channel/), +[Chrome](http://www.chromium.org/getting-involved/dev-channel), and +[Ember.js](http://emberjs.com/builds/). + +The idea is that there are three channels: Nighly, Beta, and +Release. The Nightly channel is what you use if you want the latest +and greatest: it includes unstable features and libraries that may +still change in backwards incompatible ways. Every six weeks, we cut a +new branch and call it Beta. This branch excludes all the unstable +bits, so you know that if you are using Beta or Release, your code +will continue to compile. At the same time, the existing Beta branch +is promoted to the Stable release. We expect that production users +will prefer to test on the Beta branch and ship with the Stable +branch. Testing on Beta ensures that we get some advanced notice if we +accidentally break anything you are relying on. + +With regard to the 1.0 release specifically, the plan is to release +the 1.0 beta and then follow this same process to transition to the +official 1.0 release. However, if we find a serious flaw in the +1.0 beta, we may defer and run an additional beta period or two. After +all, it's better to wait a bit longer than wind up committed to +something broken. + +### Looking forward + +In many ways, Rust 1.0 is not so much an endpoint as it is a starting +point. Naturally, we plan on continuing to develop Rust: we have a lot +of features we want to add, many of which are already in the pipeline. +But the work that's most exciting to me is not the work that will be +done by the Rust team. Rather, I expect that having a stable base will +allow the Rust community and ecosystem to grow much more rapidly than +it already has. I can't wait to see what comes out of it. + +[f]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0 +[k1]: https://github.com/charliesome/rustboot +[k2]: https://github.com/jvns/puddle +[k3]: https://github.com/pczarn/rustboot +[k4]: https://github.com/ryanra/RustOS +[stability]: http://doc.rust-lang.org/std/stability.html +[dst]: https://github.com/rust-lang/rust/commit/7932b719ec2b65acfa8c3e74aad29346d47ee992 +[cd]: https://github.com/rust-lang/rfcs/blob/master/active/0044-closures.md +[wc]: https://github.com/rust-lang/rfcs/pull/135 +[at]: https://github.com/rust-lang/rfcs/pull/195 +[gt]: https://github.com/rust-lang/rfcs/pull/230 + From 76116d7548d60b1dd58f8d0c37e12539b2b01650 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 15 Sep 2014 14:36:42 -0400 Subject: [PATCH 10/74] add author --- _posts/2014-09-15-Rust-1.0.md | 1 + 1 file changed, 1 insertion(+) diff --git a/_posts/2014-09-15-Rust-1.0.md b/_posts/2014-09-15-Rust-1.0.md index a84a4b7b3..421ab7d56 100644 --- a/_posts/2014-09-15-Rust-1.0.md +++ b/_posts/2014-09-15-Rust-1.0.md @@ -1,6 +1,7 @@ --- layout: post title: "Road to Rust 1.0" +author: Niko Matsakis --- Rust 1.0 is on its way! We have nailed down a concrete list of From 75c283e4d26e7475bc26368876d6d2576a4a7d6b Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Mon, 15 Sep 2014 12:33:02 -0700 Subject: [PATCH 11/74] Release -> Stable --- _posts/2014-09-15-Rust-1.0.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/2014-09-15-Rust-1.0.md b/_posts/2014-09-15-Rust-1.0.md index 421ab7d56..f799b198c 100644 --- a/_posts/2014-09-15-Rust-1.0.md +++ b/_posts/2014-09-15-Rust-1.0.md @@ -131,11 +131,11 @@ adopt the "channel" system used by many other projects such as [Ember.js](http://emberjs.com/builds/). The idea is that there are three channels: Nighly, Beta, and -Release. The Nightly channel is what you use if you want the latest +Stable. The Nightly channel is what you use if you want the latest and greatest: it includes unstable features and libraries that may still change in backwards incompatible ways. Every six weeks, we cut a new branch and call it Beta. This branch excludes all the unstable -bits, so you know that if you are using Beta or Release, your code +bits, so you know that if you are using Beta or Stable, your code will continue to compile. At the same time, the existing Beta branch is promoted to the Stable release. We expect that production users will prefer to test on the Beta branch and ship with the Stable From 95fa5ecc771ed18861e352298af7d0ceef6255a4 Mon Sep 17 00:00:00 2001 From: Jesse Cooke Date: Mon, 15 Sep 2014 12:43:04 -0700 Subject: [PATCH 12/74] Fix typo --- _posts/2014-09-15-Rust-1.0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2014-09-15-Rust-1.0.md b/_posts/2014-09-15-Rust-1.0.md index f799b198c..1a7f3b2eb 100644 --- a/_posts/2014-09-15-Rust-1.0.md +++ b/_posts/2014-09-15-Rust-1.0.md @@ -116,7 +116,7 @@ Enter [Cargo, the Rust package manager](http://crates.io). Cargo has been undergoing rapid development lately and is already quite functional. By the time 1.0 is released, we plan to also have a central repository up and -wunning, meaning that it will be simple to create and distribute Rust +running, meaning that it will be simple to create and distribute Rust libraries (which we call "crates"). Oh, and of course Cargo and its associated server are both written in Rust. From 3f572c10f54499f61c218c8f1eb6001cd96d031d Mon Sep 17 00:00:00 2001 From: Steve Klabnik Date: Mon, 15 Sep 2014 15:46:03 -0400 Subject: [PATCH 13/74] add RSS autodiscovery link --- _includes/head.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_includes/head.html b/_includes/head.html index ec8f7ca5f..762c4a07b 100644 --- a/_includes/head.html +++ b/_includes/head.html @@ -5,7 +5,7 @@ {% if page.title %}{{ page.title }}{% else %}{{ site.title }}{% endif %} - + From 174018b02bee3609c7bda220a7d5660228fe4b40 Mon Sep 17 00:00:00 2001 From: Steve Klabnik Date: Mon, 15 Sep 2014 16:13:17 -0400 Subject: [PATCH 14/74] fix two typos http://www.reddit.com/r/rust/comments/2ghkxz/road_to_rust_10/ckj6o6r --- _posts/2014-09-15-Rust-1.0.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/2014-09-15-Rust-1.0.md b/_posts/2014-09-15-Rust-1.0.md index 1a7f3b2eb..66a15bf02 100644 --- a/_posts/2014-09-15-Rust-1.0.md +++ b/_posts/2014-09-15-Rust-1.0.md @@ -17,7 +17,7 @@ will continue to compile". Basically, it means that we think the design of Rust finally feels right. More specifically, it feels *minimal*. The language itself is now focused on a simple core concept, which we call ownership and borrowing (more on this -later). Leveraging ownership and borrowing, we are been able to build +later). Leveraging ownership and borrowing, we have been able to build up everything else that we have needed in libraries. This is very exciting, because any library we can write, you can write too. This really gives us confidence that Rust will not only achieve its @@ -92,7 +92,7 @@ working on: require zeroing of memory, which should improve compilation and execution times. Felix Klock has implemented the requisite analysis and is in the process of landing it. -- *Green threading:* We are removing support from green threading from +- *Green threading:* We are removing support for green threading from the standard library and moving it out into an external package. This allows for a closer match between the Rust model and the underlying operating system, which makes for more efficient From c0ab17003a6cfdf7c2c850b1e1d9b3be1d266c5d Mon Sep 17 00:00:00 2001 From: Chris Wong Date: Tue, 16 Sep 2014 20:16:13 +1200 Subject: [PATCH 15/74] Fix a typo --- _posts/2014-09-15-Rust-1.0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2014-09-15-Rust-1.0.md b/_posts/2014-09-15-Rust-1.0.md index 66a15bf02..711382d00 100644 --- a/_posts/2014-09-15-Rust-1.0.md +++ b/_posts/2014-09-15-Rust-1.0.md @@ -130,7 +130,7 @@ adopt the "channel" system used by many other projects such as [Chrome](http://www.chromium.org/getting-involved/dev-channel), and [Ember.js](http://emberjs.com/builds/). -The idea is that there are three channels: Nighly, Beta, and +The idea is that there are three channels: Nightly, Beta, and Stable. The Nightly channel is what you use if you want the latest and greatest: it includes unstable features and libraries that may still change in backwards incompatible ways. Every six weeks, we cut a From 8876b525e05ff88264b67357b7eb874c41a338da Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Thu, 30 Oct 2014 17:49:34 -0700 Subject: [PATCH 16/74] Blog post: Stability as a Deliverable --- _posts/2014-10-30-Stability.md | 196 +++++++++++++++++++++++++++++++++ 1 file changed, 196 insertions(+) create mode 100644 _posts/2014-10-30-Stability.md diff --git a/_posts/2014-10-30-Stability.md b/_posts/2014-10-30-Stability.md new file mode 100644 index 000000000..7c78d348f --- /dev/null +++ b/_posts/2014-10-30-Stability.md @@ -0,0 +1,196 @@ +--- +layout: post +title: "Stability as a Deliverable" +author: Niko Matsakis and Aaron Turon +--- + +The upcoming Rust 1.0 release means +[a lot](http://blog.rust-lang.org/2014/09/15/Rust-1.0.html), but most +fundamentally it is a commitment to stability, alongside our +long-running commitment to safety. + +Starting with 1.0, we will move to +a 6-week release cycle and a menu of release "channels". The stable +release channel will provide pain-free upgrades, and the nightly +channel will give early adopters access to unfinished features as we +work on them. + +### Committing to stability + +Since the early days of Rust, there have only been two things you +could count on: safety, and change. And sometimes not the first +one. In the process of developing Rust, we've encountered a lot of +dead ends, and so it's been essential to have the freedom to change +the language as needed. + +But Rust has matured, and core aspects of the language have been +steady for a long time. The design feels right. And there is a huge +amount of pent up interest in Rust, waiting for 1.0 to ship so that +there is a stable foundation to build on. + +It's important to be clear about what we mean by stable. We don't mean +that Rust will stop evolving. We will release new versions of Rust on +a regular, frequent basis, and we hope that people will upgrade just +as regularly. But for that to happen, those upgrades need to be +painless. + +To put it simply, our responsibility is to ensure that you never dread +upgrading Rust. If your code compiles on Rust stable 1.0, it should +compile with Rust stable 1.x with a minimum of hassle. + +### The plan + +We will use a variation of the train model, first introduced in web +browsers and now widely used to provide stability without stagnation: + +* New work lands directly in the master branch. + +* Each day, the last successful build from master becomes the new nightly release. + +* Every six weeks, a beta branch is created from the current state of + master, and the previous beta is promoted to be the new stable + release. + +In short, there are three release channels -- nightly, beta, and +stable -- with regular, frequent promotions from one channel to the +next. + +New features and new APIs will be flagged as unstable via feature gates +and +[stability attributes](http://doc.rust-lang.org/reference.html#stability), +respectively. +Unstable features and standard library APIs will only be available on +the nightly branch, and only if you explicitly "opt in" to the +instability. + +The beta and stable releases, on the other hand, will only include +features and APIs deemed *stable*, which represents a commitment to +avoid breaking code that uses those features or APIs. + +### The FAQ + +There are a lot of details involved in the above process, and we plan +to publish RFCs laying out the fine points. The rest of this post will +cover some of the most important details and potential worries about +this plan. + +#### What features will be stable for 1.0? + +We've done an analysis of the current Rust ecosystem to determine the +most used crates and the feature gates they depend on, and used this +data to guide our stabilization plan. The good news is that the vast +majority of what's currently being used will be stable by 1.0: + +* There are several features that are nearly finished already: struct + variants, default type parameters, tuple indexing, and slicing syntax. + +* There are two key features that need significant more work, but are + crucial for 1.0: unboxed closures and associated types. + +* Finally, there are some widely-used features with flaws that cannot + be addressed in the 1.0 timeframe: glob imports, macros, and syntax + extensions. This is where we have to make some tough decisions. + +After extensive discussion, we plan to release globs and macros as +stable at 1.0. For globs, we believe we can address problems in a +backwards-compatible way. For macros, we will likely provide an +alternative way to define macros (with better +[hygiene](http://en.wikipedia.org/wiki/Hygienic_macro)) at some later +date, and will incrementally improve the "macro rules" feature until +then. The 1.0 release will stabilize all current macro support, +including import/export. + +On the other hand, we *cannot* stabilize syntax extensions, which are +plugins with complete access to compiler internals. Stabilizing it +would effectively forever freeze the internals of the compiler; we +need to design a more deliberate interface between extensions and the +compiler. So syntax extensions will remain behind a feature gate for +1.0. + +Many major uses of syntax extensions could be replaced with +traditional code generation, and the Cargo tool will soon be growing +specific support for this use case. We plan to work with library +authors to help them migrate away from syntax extensions prior to +1.0. Because many syntax extensions don't fit this model, we also see +stabilizing syntax extensions as an immediate priority after the 1.0 +release. + +#### What parts of the standard library will be stable for 1.0? + +We have been steadily stabilizing the standard library, and have a +plan for nearly *all* of the modules it provides. The expectation is +that the vast majority of functionality in the standard library will +be stable for 1.0. We have also been migrating more experimental APIs +out of the standard library and into their own crates. + +#### What about stability attributes outside of the standard library? + +Library authors can continue to use stability attributes as they do +today to mark their own stability promises. These attributes are not +tied into the Rust release channels by default. That is, when you're +compiling on Rust stable, you can only use stable APIs from the +standard library, but you can opt into experimental APIs from other +libraries. The Rust release channels are about making upgrading *Rust +itself* (the compiler and standard library) painless. + +Library authors should follow [semver](http://semver.org/); we will +soon publish an RFC defining how library stability attributes and +semver interact. + +#### Why not allow opting in to instability in the stable release? + +There are three problems with allowing unstable features on the +stable release. + +First, as the web has shown numerous times, merely *advertising* +instability doesn't work. Once features are in wide use it is very +hard to change them -- and once features are available at all, it is +very hard to prevent them from being used. Mechanisms like "vendor +prefixes" on the web that were meant to support experimentation +instead led to de facto standardization. + +Second, unstable features are by definition work in progress. But the +beta/stable snapshots freeze the feature at scheduled points in time, +while library authors will want to work with the latest version of the +feature. + +Finally, we simply *cannot* deliver stability for Rust unless we +enforce it. Our promise is that, if you are using the stable release +of Rust, you will never dread upgrading to the next release. If +libraries could opt in to instability, then we could only keep this +promise if all library authors guaranteed the same thing by supporting +all three release channels simultaneously. + +It's not realistic or necessary for the entire ecosystem to flawlessly +deal with these problems. Instead, we will enforce that stable means +stable: the stable channel provides only stable features. + +#### Won't this split the ecosystem? Will everyone use nightly at 1.0? + +It doesn't split the ecosystem: it creates a subset. Programmers +working with the nightly release channel can freely use libraries that +are designed for the stable channel. There will be pressure to +stabilize important features and APIs, and so the incentives to stay +in the unstable world will shrink over time. + +We have carefully planned the 1.0 release so that the bulk of the +existing ecosystem will fit into the "stable" category, and thus +newcomers to Rust will immediately be able to use most libraries on +the stable 1.0 release. + +#### What are the stability caveats? + +We reserve the right to fix compiler bugs, patch safety holes, and +change type inference in ways that may occasionally require new type +annotations. We do not expect any of these changes to cause +headaches when upgrading Rust. + +The library API caveats will be laid out in a forthcoming RFC, but are +similarly designed to minimize upgrade pain in practice. + +#### Will Rust and its ecosystem continue their rapid development? + +Yes! Because new work can land on master at any time, the train model +doesn't slow down the pace of development or introduce artificial +delays. Rust has always evolved at a rapid pace, with lots of help +from amazing community members, and we expect this will only accelerate. From d6acbc693e4aa7d44daa8aecad3fe731e6a3deae Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Thu, 30 Oct 2014 17:55:46 -0700 Subject: [PATCH 17/74] Tweaks to stability post --- _posts/2014-10-30-Stability.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/_posts/2014-10-30-Stability.md b/_posts/2014-10-30-Stability.md index 7c78d348f..19b6a225a 100644 --- a/_posts/2014-10-30-Stability.md +++ b/_posts/2014-10-30-Stability.md @@ -1,7 +1,7 @@ --- layout: post title: "Stability as a Deliverable" -author: Niko Matsakis and Aaron Turon +author: Aaron Turon and Niko Matsakis --- The upcoming Rust 1.0 release means @@ -74,7 +74,7 @@ to publish RFCs laying out the fine points. The rest of this post will cover some of the most important details and potential worries about this plan. -#### What features will be stable for 1.0? +### What features will be stable for 1.0? We've done an analysis of the current Rust ecosystem to determine the most used crates and the feature gates they depend on, and used this @@ -115,7 +115,7 @@ authors to help them migrate away from syntax extensions prior to stabilizing syntax extensions as an immediate priority after the 1.0 release. -#### What parts of the standard library will be stable for 1.0? +### What parts of the standard library will be stable for 1.0? We have been steadily stabilizing the standard library, and have a plan for nearly *all* of the modules it provides. The expectation is @@ -123,7 +123,7 @@ that the vast majority of functionality in the standard library will be stable for 1.0. We have also been migrating more experimental APIs out of the standard library and into their own crates. -#### What about stability attributes outside of the standard library? +### What about stability attributes outside of the standard library? Library authors can continue to use stability attributes as they do today to mark their own stability promises. These attributes are not @@ -137,7 +137,7 @@ Library authors should follow [semver](http://semver.org/); we will soon publish an RFC defining how library stability attributes and semver interact. -#### Why not allow opting in to instability in the stable release? +### Why not allow opting in to instability in the stable release? There are three problems with allowing unstable features on the stable release. @@ -165,7 +165,7 @@ It's not realistic or necessary for the entire ecosystem to flawlessly deal with these problems. Instead, we will enforce that stable means stable: the stable channel provides only stable features. -#### Won't this split the ecosystem? Will everyone use nightly at 1.0? +### Won't this split the ecosystem? Will everyone use nightly at 1.0? It doesn't split the ecosystem: it creates a subset. Programmers working with the nightly release channel can freely use libraries that @@ -178,7 +178,7 @@ existing ecosystem will fit into the "stable" category, and thus newcomers to Rust will immediately be able to use most libraries on the stable 1.0 release. -#### What are the stability caveats? +### What are the stability caveats? We reserve the right to fix compiler bugs, patch safety holes, and change type inference in ways that may occasionally require new type @@ -188,7 +188,7 @@ headaches when upgrading Rust. The library API caveats will be laid out in a forthcoming RFC, but are similarly designed to minimize upgrade pain in practice. -#### Will Rust and its ecosystem continue their rapid development? +### Will Rust and its ecosystem continue their rapid development? Yes! Because new work can land on master at any time, the train model doesn't slow down the pace of development or introduce artificial From a8596a4bf5ab83bf079ec6236c88e0067edbcc24 Mon Sep 17 00:00:00 2001 From: Paolo Moretti Date: Fri, 31 Oct 2014 14:40:28 +0000 Subject: [PATCH 18/74] Fix a broken link --- _posts/2014-09-15-Rust-1.0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2014-09-15-Rust-1.0.md b/_posts/2014-09-15-Rust-1.0.md index 711382d00..3c8e06616 100644 --- a/_posts/2014-09-15-Rust-1.0.md +++ b/_posts/2014-09-15-Rust-1.0.md @@ -166,7 +166,7 @@ it already has. I can't wait to see what comes out of it. [k4]: https://github.com/ryanra/RustOS [stability]: http://doc.rust-lang.org/std/stability.html [dst]: https://github.com/rust-lang/rust/commit/7932b719ec2b65acfa8c3e74aad29346d47ee992 -[cd]: https://github.com/rust-lang/rfcs/blob/master/active/0044-closures.md +[cd]: https://github.com/rust-lang/rfcs/blob/master/text/0114-closures.md [wc]: https://github.com/rust-lang/rfcs/pull/135 [at]: https://github.com/rust-lang/rfcs/pull/195 [gt]: https://github.com/rust-lang/rfcs/pull/230 From 6628d471258d8d814794ce67ff4437fd38f28232 Mon Sep 17 00:00:00 2001 From: Huon Wilson Date: Sat, 1 Nov 2014 10:05:38 +1100 Subject: [PATCH 19/74] Add the Rust logo to the site heading. --- _config.yml | 1 + _includes/header.html | 2 +- _sass/_layout.scss | 6 ++++++ 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/_config.yml b/_config.yml index c9e370977..91a26e990 100644 --- a/_config.yml +++ b/_config.yml @@ -4,6 +4,7 @@ description: > Words from the Rust team baseurl: "" url: "http://blog.rust-lang.org" +logo: "http://www.rust-lang.org/logos/rust-logo-64x64-blk.png" twitter_username: rustlang github_username: rust-lang diff --git a/_includes/header.html b/_includes/header.html index cfe381f75..de7fad667 100644 --- a/_includes/header.html +++ b/_includes/header.html @@ -2,7 +2,7 @@
- {{ site.title }} + {{ site.title }}
From 231aeb2d0e2077e9397d37db8e33d7eba1ebd6be Mon Sep 17 00:00:00 2001 From: Huon Wilson Date: Sat, 1 Nov 2014 11:09:08 +1100 Subject: [PATCH 21/74] Add the site title to the page title always. --- _includes/head.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_includes/head.html b/_includes/head.html index 762c4a07b..f056adcec 100644 --- a/_includes/head.html +++ b/_includes/head.html @@ -3,7 +3,7 @@ - {% if page.title %}{{ page.title }}{% else %}{{ site.title }}{% endif %} + {% if page.title %}{{ page.title }} - {{ site.title }}{% else %}{{ site.title }}{% endif %} From d9d1b67c9b1681bf85f15513677bd08245b16db0 Mon Sep 17 00:00:00 2001 From: Huon Wilson Date: Sat, 1 Nov 2014 11:10:29 +1100 Subject: [PATCH 22/74] Add links to rust-lang.org and the guide. Hopefully people will click on these to start their Rust journey! --- _includes/footer.html | 10 +++------- _sass/_layout.scss | 8 +++++++- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/_includes/footer.html b/_includes/footer.html index be3976f7e..f2d236e92 100644 --- a/_includes/footer.html +++ b/_includes/footer.html @@ -1,15 +1,11 @@ +
More about Rust — Jump straight in
+
- -

{{ site.title }}

-
- +

{{ site.title }}

diff --git a/_sass/_layout.scss b/_sass/_layout.scss index 058cd70e1..4e88014ec 100644 --- a/_sass/_layout.scss +++ b/_sass/_layout.scss @@ -107,6 +107,12 @@ margin-bottom: $spacing-unit / 2; } +.footer-links { + text-align: center; + font-size: 18px; + margin-bottom: $spacing-unit / 2; +} + .contact-list, .social-media-list { list-style: none; @@ -168,7 +174,7 @@ * Page content */ .page-content { - padding: $spacing-unit 0; + //padding: $spacing-unit 0; } .page-heading { From 2f8bf3f3e587723e3c8643f2da01f4f9f95c08b2 Mon Sep 17 00:00:00 2001 From: Huon Wilson Date: Sat, 1 Nov 2014 11:33:46 +1100 Subject: [PATCH 23/74] Revert removal of page-content padding-top & tweak logo spacing. --- _sass/_layout.scss | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_sass/_layout.scss b/_sass/_layout.scss index 4e88014ec..06668458c 100644 --- a/_sass/_layout.scss +++ b/_sass/_layout.scss @@ -13,7 +13,7 @@ #site-logo { width: 48px; height: 48px; - padding: 2px; + padding: 5px 0; } .site-title { @@ -174,7 +174,7 @@ * Page content */ .page-content { - //padding: $spacing-unit 0; + padding-top: $spacing-unit; } .page-heading { From cf942e6e15daa92857d55708887c399b5097e46d Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Wed, 19 Nov 2014 11:33:21 -0800 Subject: [PATCH 24/74] Blog post: Cargo: Rust's community crate host --- _posts/2014-11-20-Cargo.md | 141 +++++++++++++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 _posts/2014-11-20-Cargo.md diff --git a/_posts/2014-11-20-Cargo.md b/_posts/2014-11-20-Cargo.md new file mode 100644 index 000000000..89f61b37b --- /dev/null +++ b/_posts/2014-11-20-Cargo.md @@ -0,0 +1,141 @@ +--- +layout: post +title: "Cargo: Rust's community crate host" +author: Alex Crichton +--- + +Today it is my pleasure to announce that [crates.io](https://crates.io/) is +online and ready for action. The site is a central location to +discover/download Rust crates, and Cargo is ready to start publishing to it +today. For the next few months, we are asking that intrepid early adopters +[help us](http://doc.crates.io/crates-io.html) get the registry battle-tested. + +Until Rust itself is stable early next year, registry dependencies will need to +be updated often. Production users may want to continue using git dependencies +until then. + +## What is Cargo? + +Cargo is a package manager [for Rust](http://www.rust-lang.org/), [in +Rust](https://github.com/rust-lang/cargo). Managing dependencies is a +fundamentally difficult problem, but fortunately over the last decade there's +been a lot of progress in the design of package managers. Designed by Carl +Lerche and Yehuda Katz, Cargo follows the tradition of successes like +[Bundler](http://bundler.io/) and [NPM](https://www.npmjs.org/): + +1. Cargo leverages crates.io to foster a thriving community of crates that can + easily interoperate with one another and last for years to come. + +2. Cargo releases developers from the worry of managing dependencies and ensures + that all collaborators are building the same code. + +3. Cargo lets your dependencies say how they should be built, and manages the + entire build process for you. + +## A Community on Cargo + +To get a feel for how Cargo achieves its goals, let's take a look at some of +its core mechanics. + +### Declaring Dependencies + +Cargo makes depending on third-party code as easy as depending on the standard +library. When using Cargo, each crate will have an associated +[manifest](http://doc.crates.io/manifest.html) to describe itself and its +dependencies. Adding a new dependency is now as simple as adding one line to the +manifest, and this ease has allowed Cargo in just a few short months to enable a +large and growing network of Rust projects and libraries which were simply +infeasible before. + +Cargo alone, however, is not quite the entire solution. Discovering dependencies +is still difficult, and ensuring that these dependencies are available for years +to come is also not guaranteed. + +### crates.io + +To pair with Cargo, the central crates.io site serves as a single location for +publishing and discovering libraries. This repository serves as permanent +storage for releases of crates over time to ensure that projects can always +build with the exact same versions years later. Up until now, users of Cargo +have largely just downloaded dependencies directly from the source GitHub +repository, but the primary source will now be shifting to crates.io. + +Other programming language communities have been quite successful with this form +of central repository. For example [rubygems.org](http://rubygems.org/) is your +one-stop-shop for [Bundler](http://bundler.io/) dependencies and +[npmjs.org](https://www.npmjs.org/) has had over 600 million downloads in just +this month alone! We intend for crates.io to serve a similar role for Rust as a +critical piece of infrastructure for [Rust's long-term stability story at +1.0][stab]. + +[stab]: http://blog.rust-lang.org/2014/10/30/Stability.html + +## Versioning and Reproducible Builds + +Over the past few years, the concept of [Semantic +Versioning](http://semver.org/) has gained traction as a way for library +developers to easily and clearly communicate with users when they make breaking +changes. The core idea of semantic versioning is simple: each new release is +categorized as a minor or major release, and only major releases can introduce +breakage. Cargo allows you to specify version ranges for your dependencies, with +the default meaning of "compatible with". + +When specifying a version range, applications often end up requesting +multiple versions of a single crate, and Cargo solves this by selecting the +highest version of each major version ("stable code") requested. This highly +encourages using stable distributions while still allowing duplicates of +unstable code (pre-1.0 and git for example). + +Once the set of dependencies and their versions have been calculated, Cargo +generates a [`Cargo.lock`][lock] to encode this information. This "lock file" is +then distributed to collaborators of applications to ensure that the crates +being built remain the same from one build to the next, across times, machines, +and environments. + +[lock]: http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock + +## Building Code + +Up to this point we've seen how Cargo facilitates discovery and reuse of +community projects while managing what versions to use. Now Cargo just has to +deal with the problem of actually compiling all this code! + +With a deep understanding of the Rust code that it is building, Cargo is able to +provide some nice standard features as well as some Rust-specific features: + +* By default, Cargo builds as many crates in parallel as possible. This not only + applies to upstream dependencies being built in parallel, but also items for + the local crate such as test suites, binaries, and unit tests. + +* Cargo supports unit testing out of the box both for crates themselves and in + the form of integration tests. This even includes example programs to ensure + they don't bitrot. + +* Cargo generates documentation for all crates in a dependency graph, and it can + even run [Rust's documentation + tests](http://doc.rust-lang.org/rustdoc.html#testing-the-documentation) to + ensure examples in documentation stay up to date. + +* Cargo can run a [build script][build-scripts] before any crate is compiled to + perform tasks such as code generation, compiling native dependencies, or + detecting native dependencies on the local system. + +* Cargo supports cross compilation out of the box. Cross compiling is done by + simply specifying a `--target` options and Cargo will manage tasks such as + compiling plugins and other build dependencies for the right platform. + +[build-scripts]: http://doc.crates.io/build-script.html + +## What else is in store? + +The launch of crates.io is a key step in moving the Cargo ecosystem forward, +but the story does not end here. Usage of crates.io is architected assuming a +stable compiler, which should be [coming soon][road-to-1]! There are also a +number of extensions to crates.io such as a hosted documentation service or a CI +build infrastructure hook. + +[road-to-1]: http://blog.rust-lang.org/2014/09/15/Rust-1.0.html + +This is just the beginning for crates.io, and I'm excited to start finding all +Rust crates from one location. I can't wait to see what the registry looks like +at 1.0, and I can only fathom what it will look like after 1.0! From 3d537e083aefd1b83313f932c57635d8544030bd Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Thu, 20 Nov 2014 11:40:26 -0800 Subject: [PATCH 25/74] Clarify a closing sentence --- _posts/2014-11-20-Cargo.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2014-11-20-Cargo.md b/_posts/2014-11-20-Cargo.md index 89f61b37b..d10dad708 100644 --- a/_posts/2014-11-20-Cargo.md +++ b/_posts/2014-11-20-Cargo.md @@ -132,7 +132,7 @@ The launch of crates.io is a key step in moving the Cargo ecosystem forward, but the story does not end here. Usage of crates.io is architected assuming a stable compiler, which should be [coming soon][road-to-1]! There are also a number of extensions to crates.io such as a hosted documentation service or a CI -build infrastructure hook. +build infrastructure hook which could be built out using the crates.io APIs. [road-to-1]: http://blog.rust-lang.org/2014/09/15/Rust-1.0.html From b03f110a7844315fb41ab2c946fcc8a9da797b17 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Thu, 11 Dec 2014 23:52:23 -0800 Subject: [PATCH 26/74] Blog post: Rust 1.0: Scheduling the trains --- _posts/2014-12-12-1.0-Timeline.md | 104 ++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 _posts/2014-12-12-1.0-Timeline.md diff --git a/_posts/2014-12-12-1.0-Timeline.md b/_posts/2014-12-12-1.0-Timeline.md new file mode 100644 index 000000000..0df8bb2e6 --- /dev/null +++ b/_posts/2014-12-12-1.0-Timeline.md @@ -0,0 +1,104 @@ +--- +layout: post +title: "Rust 1.0: Scheduling the trains" +author: Aaron Turon +--- + +As 2014 is drawing to a close, it's time to begin the Rust 1.0 release cycle! + +**TL;DR: we will transition to a six week release cycle on Jan 9, 2015, and +produce Rust 1.0.0 final at least two cycles afterwards**: + +* Rust 1.0.0-alpha -- Friday, Jan 9, 2015 +* Rust 1.0.0-beta1 -- Week of Feb 16, 2015 +* Rust 1.0.0 -- One or more six-week cycles later + +We talked before about [why Rust is reaching 1.0], and also about the +[6-week train model] (with Nightly, Beta, and Stable channels) that will enable +us to deliver stability without stagnation. This post finishes the story by +laying out the transition to this new release model and the stability guarantees +it provides. + +### The alpha release + +Reaching alpha means three things: + +* The language is feature-complete. All gates are removed from features we + expect to ship with 1.0. + +* The standard library is nearly feature-complete. The majority of APIs that + will ship in 1.0 stable will already be marked as `#[stable]`. + +* *Warnings* for `#[unstable]` features are turned on by default. (Note that the + `#[experimental]` stability level is + [going away](https://github.com/rust-lang/rfcs/pull/507).) + +In other words, 1.0.0-alpha gives a pretty accurate picture of what 1.0 will +look like, but doesn't yet institute release channels. By turning on warnings +for unstable APIs but not excluding them altogether, we can get community +feedback about which important APIs still need to be stabilized without those +APIs simply disappearing over night. + +While we expect the pace of breakage to slow dramatically when we reach +feature-complete status, **1.0.0-alpha is still a [pre-release]**: + + A pre-release version indicates that the version is unstable and might not + satisfy the intended compatibility requirements as denoted by its associated + normal version. + +That is, we will reserve the right to make minor breaking changes to both the +language and libraries -- including `#[stable]` APIs -- throughout the duration +of the alpha cycle. But we expect any such changes to be relatively minor +tweaks, and changes to `#[stable]` APIs to be very rare. + +### The beta release(s) + +Six weeks later, we will begin the beta period: + +* Both the language and libraries are feature-complete. All APIs shipping for + Rust 1.0 are marked `#[stable]`. + +* Release channels take effect: feature gates and `#[unstable]` APIs are + available on nightly builds, but not on the beta. This change is part of + [our commitment to stability](http://blog.rust-lang.org/2014/10/30/Stability.html). + +Unlike the alpha cycle, where we still expect some minor breakage, the beta +cycle should *not* involve breakage unless a very significant problem is +found. Ideally, **the beta cycle will be focused on testing, bugfixing, and +polish**. + +We plan to run at least one beta cycle before the final release. + +### The final release + +Finally, after one or more beta cycles, we will have produced a release +candidate that is **ready for the world**: + +* We are ready to promise stability -- + [hassle-free upgrades](http://blog.rust-lang.org/2014/10/30/Stability.html) -- + for the duration of the 1.X series. + +* The core documentation (The Guide/Guides) is fully in sync with the language and + libraries. + +We are incredibly excited for Rust to reach this point. + +### What this means for the ecosystem + +With the [launch](http://blog.rust-lang.org/2014/11/20/Cargo.html) of Cargo and +https://crates.io/, Rust's ecosystem has already seen significant expansion, but +it still takes a lot of work to track Rust's nightly releases. Beginning with +the alpha release, and especially approaching beta1, this will change +dramatically; **code that works with beta1 should work with 1.0 final without +any changes whatsoever**. + +This migration into stability should be a boon for library writers, and we hope +that by 1.0 final there will be a massive collection of crates ready for use on +the stable channel -- and ready for the droves of people trying out Rust for the +first time. + +Let's do this! + +[why Rust is reaching 1.0]: http://blog.rust-lang.org/2014/09/15/Rust-1.0.html +[6-week train model]: http://blog.rust-lang.org/2014/10/30/Stability.html +[pre-release]: http://semver.org/ From dc22dfb4b0d5997a5e32cd3696597b0aed82fce5 Mon Sep 17 00:00:00 2001 From: Huon Wilson Date: Fri, 12 Dec 2014 12:12:10 -0700 Subject: [PATCH 27/74] 1.0 Timeline: make the crates.io link a real link. --- _posts/2014-12-12-1.0-Timeline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2014-12-12-1.0-Timeline.md b/_posts/2014-12-12-1.0-Timeline.md index 0df8bb2e6..61e874214 100644 --- a/_posts/2014-12-12-1.0-Timeline.md +++ b/_posts/2014-12-12-1.0-Timeline.md @@ -86,7 +86,7 @@ We are incredibly excited for Rust to reach this point. ### What this means for the ecosystem With the [launch](http://blog.rust-lang.org/2014/11/20/Cargo.html) of Cargo and -https://crates.io/, Rust's ecosystem has already seen significant expansion, but +[crates.io](https://crates.io/), Rust's ecosystem has already seen significant expansion, but it still takes a lot of work to track Rust's nightly releases. Beginning with the alpha release, and especially approaching beta1, this will change dramatically; **code that works with beta1 should work with 1.0 final without From f2e628806ecda761411621e6d9e47563e8baa5d6 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 12 Dec 2014 14:55:46 -0500 Subject: [PATCH 28/74] Add a post announcing Yehuda Katz and Steve Klabnik for core team. --- _posts/2014-12-12-Core-Team.md | 45 ++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 _posts/2014-12-12-Core-Team.md diff --git a/_posts/2014-12-12-Core-Team.md b/_posts/2014-12-12-Core-Team.md new file mode 100644 index 000000000..356075429 --- /dev/null +++ b/_posts/2014-12-12-Core-Team.md @@ -0,0 +1,45 @@ +--- +layout: post +title: "Announcing Yehuda Katz and Steve Klabnik for the Core Team" +author: Niko Matsakis +--- + +I'm pleased to announce that Yehuda Katz and Steve Klabnik are joining +the [Rust core team]. Both of them are not only active and engaged +members of the Rust community, but they also bring a variety of skills +and experience with them. + +Yehuda Katz will be known to many in the Rust community for his work +on the initial design and implementation of the Cargo project. He is +also a co-founder of [Tilde], which has been using Rust commercially +in their [Skylight] product for quite some time. Finally, he has been +heavily involved with the Ruby ecosystem (through such projects as +[Ruby on Rails] and [Bundler]) and with JavaScript as well (through +the [Ember.js] and [jQuery] frameworks and the +[TC39 language committee]). + +Steve Klabnik is of course the primary author of the [Rust guide] as +well as much of Rust's documentation (not to mention independent works +like [Rust for Rubyists]). He is passionate about improving the +learnability of Rust and ensuring that the onboarding experience is +smooth. Finally, Steve is an enthusiastic and tireless +communicator. Wherever there is discussion about Rust to be found, be +it IRC, the [RFCs repo], or [Reddit]/[HackerNews], you can be sure to +find a comment or two from Steve there, explaining and clarifying the +situation. + +Thanks Yehuda and Steve for all your hard work, and welcome to the core team! + +[Rust core team]: https://github.com/rust-lang/rust/wiki/Note-core-team +[Ember.js]: http://emberjs.com/team/ +[Skylight]: https://www.skylight.io/ +[Tilde]: http://www.tilde.io/ +[Rust guide]: http://doc.rust-lang.org/guide.html +[Rust for Rubyists]: http://www.rustforrubyists.com/ +[Reddit]: http://www.reddit.com/r/rust +[HackerNews]: https://news.ycombinator.com/ +[RFCs repo]: https://github.com/rust-lang/rfcs/ +[Ruby on Rails]: http://rubyonrails.org/ +[jQuery]: http://jquery.com/ +[Bundler]: http://bundler.io/ +[TC39 language committee]: http://www.ecma-international.org/memento/TC39.htm From 9e2b00ea95b09692375edd4b1cf16853c7f61f09 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 12 Dec 2014 16:41:03 -0500 Subject: [PATCH 29/74] Adjust title. --- _posts/2014-12-12-Core-Team.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2014-12-12-Core-Team.md b/_posts/2014-12-12-Core-Team.md index 356075429..0311c618a 100644 --- a/_posts/2014-12-12-Core-Team.md +++ b/_posts/2014-12-12-Core-Team.md @@ -1,6 +1,6 @@ --- layout: post -title: "Announcing Yehuda Katz and Steve Klabnik for the Core Team" +title: Yehuda Katz and Steve Klabnik are joining the Rust Core Team" author: Niko Matsakis --- From f144dd6f2101e2de4fccffcff878a320e4d8e6dc Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 12 Dec 2014 16:42:49 -0500 Subject: [PATCH 30/74] Remove stray quotation mark --- _posts/2014-12-12-Core-Team.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2014-12-12-Core-Team.md b/_posts/2014-12-12-Core-Team.md index 0311c618a..dbb613714 100644 --- a/_posts/2014-12-12-Core-Team.md +++ b/_posts/2014-12-12-Core-Team.md @@ -1,6 +1,6 @@ --- layout: post -title: Yehuda Katz and Steve Klabnik are joining the Rust Core Team" +title: Yehuda Katz and Steve Klabnik are joining the Rust Core Team author: Niko Matsakis --- From 00567aabc845f86aaef218815c828bfbbfcc764a Mon Sep 17 00:00:00 2001 From: Huon Wilson Date: Fri, 9 Jan 2015 11:08:39 +1100 Subject: [PATCH 31/74] should be bold. --- _sass/_base.scss | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/_sass/_base.scss b/_sass/_base.scss index d0fa8dcd8..ff72f12c7 100644 --- a/_sass/_base.scss +++ b/_sass/_base.scss @@ -201,3 +201,10 @@ pre { } } } + +/** + * Text styling + */ +strong, b { + font-weight: bold; +} From d11e30c544f4d5b27de07113549be8850f2f95e6 Mon Sep 17 00:00:00 2001 From: Huon Wilson Date: Sat, 10 Jan 2015 01:20:58 +1100 Subject: [PATCH 32/74] Add meta tags for twitter cards. These make blog.rust-lang.org links on twitter slightly fancier. --- _config.yml | 2 ++ _includes/head.html | 11 +++++++++++ _posts/2014-09-15-Rust-1.0.md | 2 +- _posts/2014-10-30-Stability.md | 1 + _posts/2014-11-20-Cargo.md | 1 + _posts/2014-12-12-1.0-Timeline.md | 1 + _posts/2014-12-12-Core-Team.md | 1 + 7 files changed, 18 insertions(+), 1 deletion(-) diff --git a/_config.yml b/_config.yml index 91a26e990..8f9f594d4 100644 --- a/_config.yml +++ b/_config.yml @@ -10,3 +10,5 @@ github_username: rust-lang # Build settings markdown: kramdown + +root: http://blog.rust-lang.org diff --git a/_includes/head.html b/_includes/head.html index f056adcec..2aceb33cd 100644 --- a/_includes/head.html +++ b/_includes/head.html @@ -8,4 +8,15 @@ + + + + + {% if page.description %} + + {% else %} + + {% endif %} + + diff --git a/_posts/2014-09-15-Rust-1.0.md b/_posts/2014-09-15-Rust-1.0.md index 3c8e06616..def604672 100644 --- a/_posts/2014-09-15-Rust-1.0.md +++ b/_posts/2014-09-15-Rust-1.0.md @@ -2,6 +2,7 @@ layout: post title: "Road to Rust 1.0" author: Niko Matsakis +description: "Rust 1.0 is on its way! We have nailed down a concrete list of features and are hard at work on implementing them." --- Rust 1.0 is on its way! We have nailed down a concrete list of @@ -170,4 +171,3 @@ it already has. I can't wait to see what comes out of it. [wc]: https://github.com/rust-lang/rfcs/pull/135 [at]: https://github.com/rust-lang/rfcs/pull/195 [gt]: https://github.com/rust-lang/rfcs/pull/230 - diff --git a/_posts/2014-10-30-Stability.md b/_posts/2014-10-30-Stability.md index 19b6a225a..250b76fc2 100644 --- a/_posts/2014-10-30-Stability.md +++ b/_posts/2014-10-30-Stability.md @@ -2,6 +2,7 @@ layout: post title: "Stability as a Deliverable" author: Aaron Turon and Niko Matsakis +description: "The upcoming Rust 1.0 release means a lot, but most fundamentally it is a commitment to stability, alongside our long-running commitment to safety." --- The upcoming Rust 1.0 release means diff --git a/_posts/2014-11-20-Cargo.md b/_posts/2014-11-20-Cargo.md index d10dad708..87758f6b5 100644 --- a/_posts/2014-11-20-Cargo.md +++ b/_posts/2014-11-20-Cargo.md @@ -2,6 +2,7 @@ layout: post title: "Cargo: Rust's community crate host" author: Alex Crichton +description: "Today it is my pleasure to announce that crates.io is online and ready for action." --- Today it is my pleasure to announce that [crates.io](https://crates.io/) is diff --git a/_posts/2014-12-12-1.0-Timeline.md b/_posts/2014-12-12-1.0-Timeline.md index 61e874214..c7b177705 100644 --- a/_posts/2014-12-12-1.0-Timeline.md +++ b/_posts/2014-12-12-1.0-Timeline.md @@ -2,6 +2,7 @@ layout: post title: "Rust 1.0: Scheduling the trains" author: Aaron Turon +description: "As 2014 is drawing to a close, it's time to begin the Rust 1.0 release cycle!" --- As 2014 is drawing to a close, it's time to begin the Rust 1.0 release cycle! diff --git a/_posts/2014-12-12-Core-Team.md b/_posts/2014-12-12-Core-Team.md index dbb613714..de441ffae 100644 --- a/_posts/2014-12-12-Core-Team.md +++ b/_posts/2014-12-12-Core-Team.md @@ -2,6 +2,7 @@ layout: post title: Yehuda Katz and Steve Klabnik are joining the Rust Core Team author: Niko Matsakis +description: "I'm pleased to announce that Yehuda Katz and Steve Klabnik are joining the Rust core team." --- I'm pleased to announce that Yehuda Katz and Steve Klabnik are joining From 9e1c1fcebcd0292e6b5a4f18e56534b4cfc769d1 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 9 Jan 2015 09:07:35 -0800 Subject: [PATCH 33/74] Blog post: Announcing Rust 1.0 Alpha --- _posts/2015-01-09-Rust-1.0-alpha.md | 366 ++++++++++++++++++++++++++++ 1 file changed, 366 insertions(+) create mode 100644 _posts/2015-01-09-Rust-1.0-alpha.md diff --git a/_posts/2015-01-09-Rust-1.0-alpha.md b/_posts/2015-01-09-Rust-1.0-alpha.md new file mode 100644 index 000000000..68447d769 --- /dev/null +++ b/_posts/2015-01-09-Rust-1.0-alpha.md @@ -0,0 +1,366 @@ +--- +layout: post +title: "Announcing Rust 1.0 Alpha" +author: The Rust Core Team +--- + +Today, we're excited to [release](http://www.rust-lang.org/install.html) the alpha version of Rust 1.0, a systems programming language with a focus on safety, performance and concurrency. + +This release marks a huge milestone for Rust and its community: + +* **The language is feature-complete for 1.0**. While we plan to make many usability + improvements before the final release, all 1.0 language features are now in place + and we do not expect major breaking changes to them. + +* **The core libraries are feature-complete for 1.0**. API conventions have been + firmly established, and core functionality -- basic types, traits, data + structures and concurrency primitives -- has all been + [stabilized](http://blog.rust-lang.org/2014/10/30/Stability.html). Here again + we do not expect major breaking changes before 1.0. + +The Rust community really rolled up their sleeves to help push this release over the finish line; thanks to everyone who participated, and especially to the [friends of the tree](https://github.com/rust-lang/rust/wiki/Doc-friends-of-the-tree)! + +While we've come a long way in [the last four months](http://blog.rust-lang.org/2014/09/15/Rust-1.0.html), there's a lot left to do before Rust hits 1.0 final. Read on for more. + +### What happens during the alpha cycle? + +If you're already a Rust user, the first thing you'll notice during the alpha cycle is a *dramatic* drop in the pace of breaking changes. + +Most features and modules that will ship with Rust 1.0 are in place and will change in only limited ways during this cycle, as detailed later in this post. Only a few modules -- the key ones being path manipulation and I/O -- are still stabilizing. + +We need your help to iterate on those final libraries before the beta release, and to hammer out any remaining issues on the parts of Rust we have already marked as stable. **During the alpha cycle, we recommend using the nightly releases, which will continue to evolve as these APIs take their final shape.** + +The alpha release is part of our [transition](http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html) into [stability guarantees](http://blog.rust-lang.org/2014/10/30/Stability.html). While we're not ready to make full stability guarantees yet, this release cycle moves +us much closer to that 1.0 goal. When 1.0-beta1 is released [six weeks from now](http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html), these important remaining APIs will be stable. Code that compiles on the beta release should do so with minimal changes on 1.0 final as well. + +### What's shipping in alpha? + +Since the [previous release](https://mail.mozilla.org/pipermail/rust-dev/2014-October/011267.html), we've made an enormous amount of progress. We'll cover a +few of the highlights here; the full details are in [the release notes](https://github.com/rust-lang/rust/blob/master/RELEASES.md). + +#### Language features + +* **Dynamically-sized types (DSTs):** [Types whose size is only known at runtime](http://smallcultfollowing.com/babysteps/blog/2014/01/05/dst-take-5/) (such as array slices and trait objects) are now largely integrated into the language, including basic integration with user-defined smart pointers. *Implemented by Nick Cameron; rolled out by Jorge Aparicio*. + +* **Multidispatch traits:** Trait implementations can now be selected via [multiple types](https://github.com/rust-lang/rfcs/pull/195) (not just `Self`), which has opened the door to [many](https://github.com/rust-lang/rfcs/pull/201) [interesting](https://github.com/rust-lang/rfcs/pull/235) [APIs](https://github.com/rust-lang/rfcs/pull/529). *Implemented by Niko Matsakis; rolled out by Jorge Aparicio and Aaron Turon*. + +* **Associated types:** Traits can now have [associated types](https://github.com/rust-lang/rfcs/pull/195), which cuts down on verbosity with generics and aids type inference. *Implemented by Patrick Walton, Niko Matsakis, and Nick Cameron; rolled out by Jorge Aparicio*. + +* **Where clauses:** A powerful new way of specifying trait bounds, [where clauses](https://github.com/rust-lang/rfcs/pull/135) have landed and enabled some [significant](https://github.com/rust-lang/rust/pull/20398) [simplifications](https://github.com/rust-lang/rust/pull/20560) in the standard library. *Implemented by Niko Matsakis, Patrick Walton, and Jared Roesch; rolled out by Jorge Aparicio and Aaron Turon.* + +* **"Unboxed" closures:** Closures are now [just another way of using the trait system](https://github.com/rust-lang/rfcs/pull/114), which required adding [higher-ranked lifetimes](https://github.com/rust-lang/rfcs/pull/387); this allows much greater flexibility for both ownership and choosing static or dynamic dispatch. *Implemented by Patrick Walton, Brian Koropoff and Niko Matsakis; rolled out by Jorge Aparicio.* + +* **Macros:** The `macro_rules` system has been [significantly](https://github.com/rust-lang/rfcs/pull/453) [revised](https://github.com/rust-lang/rfcs/pull/550), cleaning up a number of rough edges and future-proofing in various ways. While macros suffer from some significant deficiencies, the macro system is a powerful and important part of Rust programming that will ship with 1.0. We plan to build a second-generation macro system after the 1.0 release. *Implemented by Keegan McAllister and Corey Richardson.* + +* **Integer type changes:** The long-running debate about integer types was [recently resolved](https://github.com/rust-lang/rfcs/pull/544#issuecomment-68760871): `int` and `uint` are now known as `isize` and `usize`, and no longer suggest the role of "default integer" in Rust. *Credit goes to the entire community for the vigorous debate.* + +* **Opt-in builtin traits**: The marker traits that Rust uses to classify data as copyable, thread-safe, and so forth have been [significantly refactored to have safer, more predicable defaults](https://github.com/rust-lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md). *Implemented by Patrick Walton and Flavio Percoco Premoli.* + +All of these language features have been rolled out throughout the standard library. + +#### Library features + +* **Consistent conventions:** +[A](https://github.com/rust-lang/rfcs/pull/199) +[large](https://github.com/rust-lang/rfcs/pull/236) +[number](https://github.com/rust-lang/rfcs/pull/240) +[of](https://github.com/rust-lang/rfcs/pull/344) +[conventions](https://github.com/rust-lang/rfcs/pull/430) +[RFCs](https://github.com/rust-lang/rfcs/pull/445) +have been approved, and are largely summarized [in the Rust Guidelines](http://aturon.github.io/); these conventions have been rolled out through all `#[stable]` parts of `std`. *Led by Aaron Turon*. + +* **Stable core types and traits:** All of the primitive types and basic building blocks (like `char`, `String`, `Vec`, `Box`, `Arc`, `RefCell` and so on) are now `#[stable]`. *Implemented by Aaron Turon, Alex Crichton, Brian Anderson, Brendan Zabarauskas and Huon Wilson*. + +* **Iterators and collections:** A [series](https://github.com/rust-lang/rfcs/pull/216) [of](https://github.com/rust-lang/rfcs/pull/235) [RFCs](https://github.com/rust-lang/rfcs/pull/509) have been implemented to revamp and stabilize the collections APIs; iterators are also `#[stable]`. *Designed by Aaron Turon and Alexis Beingessner, implemented together with Chase Southwood, Piotr Czarnecki, Félix Raimundo, Clark Gaebel and others.* + +* **Concurrency primitives:** Rust's concurrency modules have seen an overhaul, including +[thread-local storage](https://github.com/rust-lang/rfcs/pull/461), [synchronization primitives](https://github.com/rust-lang/rust/pull/19274/), and a new [thread API](https://github.com/rust-lang/rust/pull/20615) that will soon allow child threads to share data on their parent's stack. These APIs are more efficient and idiomatic than previous versions, and most are already `#[stable]`. *Implemented by Alex Crichton and Aaron Turon*. + +* **Runtime freedom:** Rust's runtime system and green-threading model has been [entirely removed](https://github.com/rust-lang/rfcs/pull/230), which cut the static binary size of "hello world" in half and has [opened the door](https://github.com/rust-lang/rust/pull/19169) to lower-level hooks into the standard library. *Implemented by Aaron Turon*. + +#### Documentation + +* **The Rust Programming Language:** The previous split between "The Guide" and "The guides" has been rectified by combining them into ["The book"](https://github.com/rust-lang/rust/pull/19897). *Led by Steve Klabnik*. + +* **Rust by Example:** The lovely http://rustbyexample.com/ introduction to Rust is now part of the official documentation. *Initiated by Jorge Aparicio*. + +* **Additional API documentation:** A lot of work has gone into improving API documentation, both by expanding the overview text and adding examples throughout. *Credit goes to the the entire community, who worked tirelessly to improve these docs*. + +### What remains to be done? + +A detailed list of possible breaking changes to *stable* features/APIs can be found [here](https://github.com/rust-lang/rust/wiki/Anticipated-breaking-changes-during-1.0-alpha). Below is a list of major areas of improvement for the alpha cycle: + +* **Improvements to [associated types](https://github.com/rust-lang/rust/issues/17307) and [unboxed closures](https://github.com/rust-lang/rust/issues/18101):** Both of these features are functional, but we plan to make significant ergonomic improvements during the beta cycle, such as [more sophisticated capture-clause inference](https://github.com/rust-lang/rfcs/blob/master/text/0231-upvar-capture-inference.md) and more [uniform support for shorthands like `X::Type`](https://github.com/rust-lang/rust/issues/20300). + +* **Improvements to generics:** We will explore [avenues](http://smallcultfollowing.com/babysteps/blog/2014/07/06/implied-bounds/) to cut down on the number of redundant trait bounds that are currently required. + +* **Path reform:** The `path` module will soon be [reformed](https://github.com/rust-lang/rfcs/pull/474) to make use of DST, to give a better account of platform differences, and to more closely align with the [new C++ standard](http://article.gmane.org/gmane.comp.lib.boost.devel/256220). Implementation work is largely complete, and the rollout should occur soon after alpha. + +* **IO reform:** An [overhaul of the IO APIs](https://github.com/rust-lang/rfcs/pull/517/) is being planned; please join in the conversation! These changes will be landing throughout the alpha cycle. + +* **Sync/Send changes:** We plan to tweak the definitions of the `Sync` and `Send` markers so that [threads can share stack data](https://github.com/rust-lang/rfcs/pull/458). This may cause some minor breakage. + +* **Integer type auditing:** During the alpha cycle, we will finalize formal conventions for choosing integer types and re-audit the use of these types in `std`. This auditing may cause some breakage to `#[stable]` APIs. + +* **Documentation for all features:** Some recent feature additions, such as associated types and unboxed closures, have their RFC as the only documentation. User-facing documentation for these features will be added during the alpha cycle. The [reference](http://doc.rust-lang.org/reference.html) will likewise be brought up to date and improved. + +* **Complete API documentation:** Everything marked stable will have _at least_ a usage example, and hopefully complete textual explanation, before beta. + +And, of course, we will continue to fix bugs and add polish throughout the alpha cycle. + +### Contributors to Rust 1.0.0-alpha + +This alpha release could not have happened without the help of Rust's enthusiastic community. Thanks go to: + +``` +Aaron Friel +Aaron Liblong +Aaron Turon +Aaron Weiss +Adam Szkoda +Adolfo Ochagavía +Adrien Tétar +Aidan Cully +A.J. Gardner +Akos Kiss +Aleksandr Koshlo +Alexander Light +Alex Crichton +Alex Gaynor +Alexis Beingessner +Alex Lyon +Alfie John +Andrea Canciani +Andrew Cann +Andrew Paseltiner +Andrew Wagner +areski +Ariel Ben-Yehuda +Artem +Arthur Liao +arturo +Austin Bonander +Barosl Lee +Ben Foppa +Ben Gamari +Ben S +Bheesham Persaud +Björn Steinbrink +bluss +bombless +Boris Egorov +bors +Brandon Sanderson +Brendan Zabarauskas +Brian Anderson +Brian J Brennan +Brian Koropoff +Carol Nichols +Chase Southwood +Chris Morgan +Chris Wong +Clark Gaebel +Cody P Schafer +Colin Sherratt +Corey Farwell +Corey Ford +Corey Richardson +crhino +Cristi Burcă +Damien Radtke +Dan Burkert +dan@daramos.com +Daniel Hofstetter +Daniel Micay +Dan Luu +David Creswick +Davis Silverman +Diego Giagio +Dirk Gadsden +Earl St Sauver +Eduard Burtescu +Eduardo Bautista +elszben +Eric Allen +Eric Kidd +Erick Tryzelaar +Erwan +Fabrice Desré +FakeKane +Falco Hirschenberger +Felix Raimundo +Felix S. Klock II +Flavio Percoco +Florian Gilcher +Florian Hahn +Florian Wilkens +gamazeps +Gil Cottle +Gleb Kozyrev +Graham Fawcett +Guillaume Pinot +Huon Wilson +Ian Connolly +inrustwetrust +Ivan Petkov +Ivan Ukhov +Jacob Edelman +Jake Goulding +Jakub Bukaj +James Miller +Jared Roesch +Jarod Liu +Jashank Jeremy +Jauhien Piatlicki +jbranchaud +Jeff Parsons +Jelte Fennema +jfager +Jim Apple +jmu303 +Johannes Hoff +Johannes Muenzel +John Albietz +John Gallagher +John Kåre Alsaker +John Kleint +Jonathan Reem +Jonathan S +Jon Haddad +JONNALAGADDA Srinivas +Joonas Javanainen +Jorge Aparicio +Joseph Crail +Joseph Rushton Wakeling +Josh Haberman +Josh Stone +Joshua Yanovski +jrincayc +Julian Orth +juxiliary +jxv +Kang Seonghoon +Kasey Carrothers +Keegan McAllister +Ken Tossell +Kevin Ballard +Kevin Mehall +Kevin Yap +klutzy +kulakowski +Laurence Tratt +Liigo Zhuang +Lionel Flandrin +Luke Metz +Luqman Aden +Manish Goregaokar +Markus Siemens +Martin Pool +Marvin Löbel +Matej Lach +Mathieu Poumeyrol +Matt McPherrin +Matt Murphy +Matt Windsor +Maxime Quandalle +Maximilian Haack +Maya Nitu +mchaput +mdinger +Michael Gehring +Michael Neumann +Michael Sproul +Michael Woerister +Mike Dilger +Mike Pedersen +Mike Robinson +Ms2ger +Mukilan Thiyagarajan +Murarth +Nafis +Nathan Zadoks +Neil Pankey +Nicholas Bishop +Nick Cameron +Nick Howell +Niels Egberts +Niko Matsakis +NODA, Kai +OGINO Masanori +oli-obk +Oliver Schneider +olivren +P1start +Pascal Hertleif +Patrick Walton +Paul Collier +Pedro Larroy +Peter Atashian +Peter Elmers +Phil Dawes +Philip Munksgaard +Philipp Gesang +Piotr Czarnecki +Piotr Jawniak +Piotr Szotkowski +qwitwa +Raphael Speyer +Ray Clanan +Richard Diamond +Richo Healey +Ricky Taylor +rjz +Robin Gloster +Robin Stocker +Rohit Joshi +Rolf Timmermans +Rolf van de Krol +Roy Crihfield +Ruud van Asseldonk +Sean Collins +Sean Gillespie +Sean Jensen-Grey +Sean McArthur +Sean T Allen +Seo Sanghyeon +Seth Pollack +sheroze1123 +Simonas Kazlauskas +Simon Sapin +Simon Wollwage +Son +Stefan Bucur +Stepan Koltsov +Steve Klabnik +Steven Fackler +Stuart Pernsteiner +Subhash Bhushan +Tamir Duberstein +Taylor Hutchison +th0114nd +thiagopnts +Timon Rapp +Titouan Vervack +Tobias Bucher +Tom Jakubowski +tshakah +Tshepang Lekhonkhobe +Ulysse Carion +Utkarsh Kukreti +Vadim Chugunov +Vadim Petrochenkov +Valerii Hiora +Victor Berger +Victor van den Elzen +Viktor Dahl +ville-h +Vitali Haravy +Vladimir Matveev +Vladimir Smola +we +whataloadofwhat +YawarRaza7349 +York Xiang +Zbigniew Siciarz +Ziad Hatahet +``` From 1b5a6a8999629a9b40d87a3d5c4ace4dea49652b Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Fri, 9 Jan 2015 10:20:38 -0800 Subject: [PATCH 34/74] Fix contributor list --- _posts/2015-01-09-Rust-1.0-alpha.md | 502 ++++++++++++++-------------- 1 file changed, 250 insertions(+), 252 deletions(-) diff --git a/_posts/2015-01-09-Rust-1.0-alpha.md b/_posts/2015-01-09-Rust-1.0-alpha.md index 68447d769..a363e0e54 100644 --- a/_posts/2015-01-09-Rust-1.0-alpha.md +++ b/_posts/2015-01-09-Rust-1.0-alpha.md @@ -112,255 +112,253 @@ And, of course, we will continue to fix bugs and add polish throughout the alpha This alpha release could not have happened without the help of Rust's enthusiastic community. Thanks go to: -``` -Aaron Friel -Aaron Liblong -Aaron Turon -Aaron Weiss -Adam Szkoda -Adolfo Ochagavía -Adrien Tétar -Aidan Cully -A.J. Gardner -Akos Kiss -Aleksandr Koshlo -Alexander Light -Alex Crichton -Alex Gaynor -Alexis Beingessner -Alex Lyon -Alfie John -Andrea Canciani -Andrew Cann -Andrew Paseltiner -Andrew Wagner -areski -Ariel Ben-Yehuda -Artem -Arthur Liao -arturo -Austin Bonander -Barosl Lee -Ben Foppa -Ben Gamari -Ben S -Bheesham Persaud -Björn Steinbrink -bluss -bombless -Boris Egorov -bors -Brandon Sanderson -Brendan Zabarauskas -Brian Anderson -Brian J Brennan -Brian Koropoff -Carol Nichols -Chase Southwood -Chris Morgan -Chris Wong -Clark Gaebel -Cody P Schafer -Colin Sherratt -Corey Farwell -Corey Ford -Corey Richardson -crhino -Cristi Burcă -Damien Radtke -Dan Burkert -dan@daramos.com -Daniel Hofstetter -Daniel Micay -Dan Luu -David Creswick -Davis Silverman -Diego Giagio -Dirk Gadsden -Earl St Sauver -Eduard Burtescu -Eduardo Bautista -elszben -Eric Allen -Eric Kidd -Erick Tryzelaar -Erwan -Fabrice Desré -FakeKane -Falco Hirschenberger -Felix Raimundo -Felix S. Klock II -Flavio Percoco -Florian Gilcher -Florian Hahn -Florian Wilkens -gamazeps -Gil Cottle -Gleb Kozyrev -Graham Fawcett -Guillaume Pinot -Huon Wilson -Ian Connolly -inrustwetrust -Ivan Petkov -Ivan Ukhov -Jacob Edelman -Jake Goulding -Jakub Bukaj -James Miller -Jared Roesch -Jarod Liu -Jashank Jeremy -Jauhien Piatlicki -jbranchaud -Jeff Parsons -Jelte Fennema -jfager -Jim Apple -jmu303 -Johannes Hoff -Johannes Muenzel -John Albietz -John Gallagher -John Kåre Alsaker -John Kleint -Jonathan Reem -Jonathan S -Jon Haddad -JONNALAGADDA Srinivas -Joonas Javanainen -Jorge Aparicio -Joseph Crail -Joseph Rushton Wakeling -Josh Haberman -Josh Stone -Joshua Yanovski -jrincayc -Julian Orth -juxiliary -jxv -Kang Seonghoon -Kasey Carrothers -Keegan McAllister -Ken Tossell -Kevin Ballard -Kevin Mehall -Kevin Yap -klutzy -kulakowski -Laurence Tratt -Liigo Zhuang -Lionel Flandrin -Luke Metz -Luqman Aden -Manish Goregaokar -Markus Siemens -Martin Pool -Marvin Löbel -Matej Lach -Mathieu Poumeyrol -Matt McPherrin -Matt Murphy -Matt Windsor -Maxime Quandalle -Maximilian Haack -Maya Nitu -mchaput -mdinger -Michael Gehring -Michael Neumann -Michael Sproul -Michael Woerister -Mike Dilger -Mike Pedersen -Mike Robinson -Ms2ger -Mukilan Thiyagarajan -Murarth -Nafis -Nathan Zadoks -Neil Pankey -Nicholas Bishop -Nick Cameron -Nick Howell -Niels Egberts -Niko Matsakis -NODA, Kai -OGINO Masanori -oli-obk -Oliver Schneider -olivren -P1start -Pascal Hertleif -Patrick Walton -Paul Collier -Pedro Larroy -Peter Atashian -Peter Elmers -Phil Dawes -Philip Munksgaard -Philipp Gesang -Piotr Czarnecki -Piotr Jawniak -Piotr Szotkowski -qwitwa -Raphael Speyer -Ray Clanan -Richard Diamond -Richo Healey -Ricky Taylor -rjz -Robin Gloster -Robin Stocker -Rohit Joshi -Rolf Timmermans -Rolf van de Krol -Roy Crihfield -Ruud van Asseldonk -Sean Collins -Sean Gillespie -Sean Jensen-Grey -Sean McArthur -Sean T Allen -Seo Sanghyeon -Seth Pollack -sheroze1123 -Simonas Kazlauskas -Simon Sapin -Simon Wollwage -Son -Stefan Bucur -Stepan Koltsov -Steve Klabnik -Steven Fackler -Stuart Pernsteiner -Subhash Bhushan -Tamir Duberstein -Taylor Hutchison -th0114nd -thiagopnts -Timon Rapp -Titouan Vervack -Tobias Bucher -Tom Jakubowski -tshakah -Tshepang Lekhonkhobe -Ulysse Carion -Utkarsh Kukreti -Vadim Chugunov -Vadim Petrochenkov -Valerii Hiora -Victor Berger -Victor van den Elzen -Viktor Dahl -ville-h -Vitali Haravy -Vladimir Matveev -Vladimir Smola -we -whataloadofwhat -YawarRaza7349 -York Xiang -Zbigniew Siciarz -Ziad Hatahet -``` +* Aaron Friel +* Aaron Liblong +* Aaron Turon +* Aaron Weiss +* Adam Szkoda +* Adolfo Ochagavía +* Adrien Tétar +* Aidan Cully +* A.J. Gardner +* Akos Kiss +* Aleksandr Koshlo +* Alexander Light +* Alex Crichton +* Alex Gaynor +* Alexis Beingessner +* Alex Lyon +* Alfie John +* Andrea Canciani +* Andrew Cann +* Andrew Paseltiner +* Andrew Wagner +* areski +* Ariel Ben-Yehuda +* Artem +* Arthur Liao +* arturo +* Austin Bonander +* Barosl Lee +* Ben Foppa +* Ben Gamari +* Ben S +* Bheesham Persaud +* Björn Steinbrink +* bluss +* bombless +* Boris Egorov +* bors +* Brandon Sanderson +* Brendan Zabarauskas +* Brian Anderson +* Brian J Brennan +* Brian Koropoff +* Carol Nichols +* Chase Southwood +* Chris Morgan +* Chris Wong +* Clark Gaebel +* Cody P Schafer +* Colin Sherratt +* Corey Farwell +* Corey Ford +* Corey Richardson +* crhino +* Cristi Burcă +* Damien Radtke +* Dan Burkert +* dan@daramos.com +* Daniel Hofstetter +* Daniel Micay +* Dan Luu +* David Creswick +* Davis Silverman +* Diego Giagio +* Dirk Gadsden +* Earl St Sauver +* Eduard Burtescu +* Eduardo Bautista +* elszben +* Eric Allen +* Eric Kidd +* Erick Tryzelaar +* Erwan +* Fabrice Desré +* FakeKane +* Falco Hirschenberger +* Felix Raimundo +* Felix S. Klock II +* Flavio Percoco +* Florian Gilcher +* Florian Hahn +* Florian Wilkens +* gamazeps +* Gil Cottle +* Gleb Kozyrev +* Graham Fawcett +* Guillaume Pinot +* Huon Wilson +* Ian Connolly +* inrustwetrust +* Ivan Petkov +* Ivan Ukhov +* Jacob Edelman +* Jake Goulding +* Jakub Bukaj +* James Miller +* Jared Roesch +* Jarod Liu +* Jashank Jeremy +* Jauhien Piatlicki +* jbranchaud +* Jeff Parsons +* Jelte Fennema +* jfager +* Jim Apple +* jmu303 +* Johannes Hoff +* Johannes Muenzel +* John Albietz +* John Gallagher +* John Kåre Alsaker +* John Kleint +* Jonathan Reem +* Jonathan S +* Jon Haddad +* JONNALAGADDA Srinivas +* Joonas Javanainen +* Jorge Aparicio +* Joseph Crail +* Joseph Rushton Wakeling +* Josh Haberman +* Josh Stone +* Joshua Yanovski +* jrincayc +* Julian Orth +* juxiliary +* jxv +* Kang Seonghoon +* Kasey Carrothers +* Keegan McAllister +* Ken Tossell +* Kevin Ballard +* Kevin Mehall +* Kevin Yap +* klutzy +* kulakowski +* Laurence Tratt +* Liigo Zhuang +* Lionel Flandrin +* Luke Metz +* Luqman Aden +* Manish Goregaokar +* Markus Siemens +* Martin Pool +* Marvin Löbel +* Matej Lach +* Mathieu Poumeyrol +* Matt McPherrin +* Matt Murphy +* Matt Windsor +* Maxime Quandalle +* Maximilian Haack +* Maya Nitu +* mchaput +* mdinger +* Michael Gehring +* Michael Neumann +* Michael Sproul +* Michael Woerister +* Mike Dilger +* Mike Pedersen +* Mike Robinson +* Ms2ger +* Mukilan Thiyagarajan +* Murarth +* Nafis +* Nathan Zadoks +* Neil Pankey +* Nicholas Bishop +* Nick Cameron +* Nick Howell +* Niels Egberts +* Niko Matsakis +* NODA, Kai +* OGINO Masanori +* oli-obk +* Oliver Schneider +* olivren +* P1start +* Pascal Hertleif +* Patrick Walton +* Paul Collier +* Pedro Larroy +* Peter Atashian +* Peter Elmers +* Phil Dawes +* Philip Munksgaard +* Philipp Gesang +* Piotr Czarnecki +* Piotr Jawniak +* Piotr Szotkowski +* qwitwa +* Raphael Speyer +* Ray Clanan +* Richard Diamond +* Richo Healey +* Ricky Taylor +* rjz +* Robin Gloster +* Robin Stocker +* Rohit Joshi +* Rolf Timmermans +* Rolf van de Krol +* Roy Crihfield +* Ruud van Asseldonk +* Sean Collins +* Sean Gillespie +* Sean Jensen-Grey +* Sean McArthur +* Sean T Allen +* Seo Sanghyeon +* Seth Pollack +* sheroze1123 +* Simonas Kazlauskas +* Simon Sapin +* Simon Wollwage +* Son +* Stefan Bucur +* Stepan Koltsov +* Steve Klabnik +* Steven Fackler +* Stuart Pernsteiner +* Subhash Bhushan +* Tamir Duberstein +* Taylor Hutchison +* th0114nd +* thiagopnts +* Timon Rapp +* Titouan Vervack +* Tobias Bucher +* Tom Jakubowski +* tshakah +* Tshepang Lekhonkhobe +* Ulysse Carion +* Utkarsh Kukreti +* Vadim Chugunov +* Vadim Petrochenkov +* Valerii Hiora +* Victor Berger +* Victor van den Elzen +* Viktor Dahl +* ville-h +* Vitali Haravy +* Vladimir Matveev +* Vladimir Smola +* we +* whataloadofwhat +* YawarRaza7349 +* York Xiang +* Zbigniew Siciarz +* Ziad Hatahet From c93ca39fb4d53882854a8ba97f826616a38dcef6 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 9 Jan 2015 10:20:36 -0800 Subject: [PATCH 35/74] Space out contribs --- _posts/2015-01-09-Rust-1.0-alpha.md | 752 +++++++++++++++++++--------- 1 file changed, 502 insertions(+), 250 deletions(-) diff --git a/_posts/2015-01-09-Rust-1.0-alpha.md b/_posts/2015-01-09-Rust-1.0-alpha.md index a363e0e54..dc49ebbbe 100644 --- a/_posts/2015-01-09-Rust-1.0-alpha.md +++ b/_posts/2015-01-09-Rust-1.0-alpha.md @@ -112,253 +112,505 @@ And, of course, we will continue to fix bugs and add polish throughout the alpha This alpha release could not have happened without the help of Rust's enthusiastic community. Thanks go to: -* Aaron Friel -* Aaron Liblong -* Aaron Turon -* Aaron Weiss -* Adam Szkoda -* Adolfo Ochagavía -* Adrien Tétar -* Aidan Cully -* A.J. Gardner -* Akos Kiss -* Aleksandr Koshlo -* Alexander Light -* Alex Crichton -* Alex Gaynor -* Alexis Beingessner -* Alex Lyon -* Alfie John -* Andrea Canciani -* Andrew Cann -* Andrew Paseltiner -* Andrew Wagner -* areski -* Ariel Ben-Yehuda -* Artem -* Arthur Liao -* arturo -* Austin Bonander -* Barosl Lee -* Ben Foppa -* Ben Gamari -* Ben S -* Bheesham Persaud -* Björn Steinbrink -* bluss -* bombless -* Boris Egorov -* bors -* Brandon Sanderson -* Brendan Zabarauskas -* Brian Anderson -* Brian J Brennan -* Brian Koropoff -* Carol Nichols -* Chase Southwood -* Chris Morgan -* Chris Wong -* Clark Gaebel -* Cody P Schafer -* Colin Sherratt -* Corey Farwell -* Corey Ford -* Corey Richardson -* crhino -* Cristi Burcă -* Damien Radtke -* Dan Burkert -* dan@daramos.com -* Daniel Hofstetter -* Daniel Micay -* Dan Luu -* David Creswick -* Davis Silverman -* Diego Giagio -* Dirk Gadsden -* Earl St Sauver -* Eduard Burtescu -* Eduardo Bautista -* elszben -* Eric Allen -* Eric Kidd -* Erick Tryzelaar -* Erwan -* Fabrice Desré -* FakeKane -* Falco Hirschenberger -* Felix Raimundo -* Felix S. Klock II -* Flavio Percoco -* Florian Gilcher -* Florian Hahn -* Florian Wilkens -* gamazeps -* Gil Cottle -* Gleb Kozyrev -* Graham Fawcett -* Guillaume Pinot -* Huon Wilson -* Ian Connolly -* inrustwetrust -* Ivan Petkov -* Ivan Ukhov -* Jacob Edelman -* Jake Goulding -* Jakub Bukaj -* James Miller -* Jared Roesch -* Jarod Liu -* Jashank Jeremy -* Jauhien Piatlicki -* jbranchaud -* Jeff Parsons -* Jelte Fennema -* jfager -* Jim Apple -* jmu303 -* Johannes Hoff -* Johannes Muenzel -* John Albietz -* John Gallagher -* John Kåre Alsaker -* John Kleint -* Jonathan Reem -* Jonathan S -* Jon Haddad -* JONNALAGADDA Srinivas -* Joonas Javanainen -* Jorge Aparicio -* Joseph Crail -* Joseph Rushton Wakeling -* Josh Haberman -* Josh Stone -* Joshua Yanovski -* jrincayc -* Julian Orth -* juxiliary -* jxv -* Kang Seonghoon -* Kasey Carrothers -* Keegan McAllister -* Ken Tossell -* Kevin Ballard -* Kevin Mehall -* Kevin Yap -* klutzy -* kulakowski -* Laurence Tratt -* Liigo Zhuang -* Lionel Flandrin -* Luke Metz -* Luqman Aden -* Manish Goregaokar -* Markus Siemens -* Martin Pool -* Marvin Löbel -* Matej Lach -* Mathieu Poumeyrol -* Matt McPherrin -* Matt Murphy -* Matt Windsor -* Maxime Quandalle -* Maximilian Haack -* Maya Nitu -* mchaput -* mdinger -* Michael Gehring -* Michael Neumann -* Michael Sproul -* Michael Woerister -* Mike Dilger -* Mike Pedersen -* Mike Robinson -* Ms2ger -* Mukilan Thiyagarajan -* Murarth -* Nafis -* Nathan Zadoks -* Neil Pankey -* Nicholas Bishop -* Nick Cameron -* Nick Howell -* Niels Egberts -* Niko Matsakis -* NODA, Kai -* OGINO Masanori -* oli-obk -* Oliver Schneider -* olivren -* P1start -* Pascal Hertleif -* Patrick Walton -* Paul Collier -* Pedro Larroy -* Peter Atashian -* Peter Elmers -* Phil Dawes -* Philip Munksgaard -* Philipp Gesang -* Piotr Czarnecki -* Piotr Jawniak -* Piotr Szotkowski -* qwitwa -* Raphael Speyer -* Ray Clanan -* Richard Diamond -* Richo Healey -* Ricky Taylor -* rjz -* Robin Gloster -* Robin Stocker -* Rohit Joshi -* Rolf Timmermans -* Rolf van de Krol -* Roy Crihfield -* Ruud van Asseldonk -* Sean Collins -* Sean Gillespie -* Sean Jensen-Grey -* Sean McArthur -* Sean T Allen -* Seo Sanghyeon -* Seth Pollack -* sheroze1123 -* Simonas Kazlauskas -* Simon Sapin -* Simon Wollwage -* Son -* Stefan Bucur -* Stepan Koltsov -* Steve Klabnik -* Steven Fackler -* Stuart Pernsteiner -* Subhash Bhushan -* Tamir Duberstein -* Taylor Hutchison -* th0114nd -* thiagopnts -* Timon Rapp -* Titouan Vervack -* Tobias Bucher -* Tom Jakubowski -* tshakah -* Tshepang Lekhonkhobe -* Ulysse Carion -* Utkarsh Kukreti -* Vadim Chugunov -* Vadim Petrochenkov -* Valerii Hiora -* Victor Berger -* Victor van den Elzen -* Viktor Dahl -* ville-h -* Vitali Haravy -* Vladimir Matveev -* Vladimir Smola -* we -* whataloadofwhat -* YawarRaza7349 -* York Xiang -* Zbigniew Siciarz -* Ziad Hatahet +``` +Aaron Friel + +Aaron Liblong + +Aaron Turon + +Aaron Weiss + +Adam Szkoda + +Adolfo Ochagavía + +Adrien Tétar + +Aidan Cully + +A.J. Gardner + +Akos Kiss + +Aleksandr Koshlo + +Alexander Light + +Alex Crichton + +Alex Gaynor + +Alexis Beingessner + +Alex Lyon + +Alfie John + +Andrea Canciani + +Andrew Cann + +Andrew Paseltiner + +Andrew Wagner + +areski + +Ariel Ben-Yehuda + +Artem + +Arthur Liao + +arturo + +Austin Bonander + +Barosl Lee + +Ben Foppa + +Ben Gamari + +Ben S + +Bheesham Persaud + +Björn Steinbrink + +bluss + +bombless + +Boris Egorov + +bors + +Brandon Sanderson + +Brendan Zabarauskas + +Brian Anderson + +Brian J Brennan + +Brian Koropoff + +Carol Nichols + +Chase Southwood + +Chris Morgan + +Chris Wong + +Clark Gaebel + +Cody P Schafer + +Colin Sherratt + +Corey Farwell + +Corey Ford + +Corey Richardson + +crhino + +Cristi Burcă + +Damien Radtke + +Dan Burkert + +dan@daramos.com + +Daniel Hofstetter + +Daniel Micay + +Dan Luu + +David Creswick + +Davis Silverman + +Diego Giagio + +Dirk Gadsden + +Earl St Sauver + +Eduard Burtescu + +Eduardo Bautista + +elszben + +Eric Allen + +Eric Kidd + +Erick Tryzelaar + +Erwan + +Fabrice Desré + +FakeKane + +Falco Hirschenberger + +Felix Raimundo + +Felix S. Klock II + +Flavio Percoco + +Florian Gilcher + +Florian Hahn + +Florian Wilkens + +gamazeps + +Gil Cottle + +Gleb Kozyrev + +Graham Fawcett + +Guillaume Pinot + +Huon Wilson + +Ian Connolly + +inrustwetrust + +Ivan Petkov + +Ivan Ukhov + +Jacob Edelman + +Jake Goulding + +Jakub Bukaj + +James Miller + +Jared Roesch + +Jarod Liu + +Jashank Jeremy + +Jauhien Piatlicki + +jbranchaud + +Jeff Parsons + +Jelte Fennema + +jfager + +Jim Apple + +jmu303 + +Johannes Hoff + +Johannes Muenzel + +John Albietz + +John Gallagher + +John Kåre Alsaker + +John Kleint + +Jonathan Reem + +Jonathan S + +Jon Haddad + +JONNALAGADDA Srinivas + +Joonas Javanainen + +Jorge Aparicio + +Joseph Crail + +Joseph Rushton Wakeling + +Josh Haberman + +Josh Stone + +Joshua Yanovski + +jrincayc + +Julian Orth + +juxiliary + +jxv + +Kang Seonghoon + +Kasey Carrothers + +Keegan McAllister + +Ken Tossell + +Kevin Ballard + +Kevin Mehall + +Kevin Yap + +klutzy + +kulakowski + +Laurence Tratt + +Liigo Zhuang + +Lionel Flandrin + +Luke Metz + +Luqman Aden + +Manish Goregaokar + +Markus Siemens + +Martin Pool + +Marvin Löbel + +Matej Lach + +Mathieu Poumeyrol + +Matt McPherrin + +Matt Murphy + +Matt Windsor + +Maxime Quandalle + +Maximilian Haack + +Maya Nitu + +mchaput + +mdinger + +Michael Gehring + +Michael Neumann + +Michael Sproul + +Michael Woerister + +Mike Dilger + +Mike Pedersen + +Mike Robinson + +Ms2ger + +Mukilan Thiyagarajan + +Murarth + +Nafis + +Nathan Zadoks + +Neil Pankey + +Nicholas Bishop + +Nick Cameron + +Nick Howell + +Niels Egberts + +Niko Matsakis + +NODA, Kai + +OGINO Masanori + +oli-obk + +Oliver Schneider + +olivren + +P1start + +Pascal Hertleif + +Patrick Walton + +Paul Collier + +Pedro Larroy + +Peter Atashian + +Peter Elmers + +Phil Dawes + +Philip Munksgaard + +Philipp Gesang + +Piotr Czarnecki + +Piotr Jawniak + +Piotr Szotkowski + +qwitwa + +Raphael Speyer + +Ray Clanan + +Richard Diamond + +Richo Healey + +Ricky Taylor + +rjz + +Robin Gloster + +Robin Stocker + +Rohit Joshi + +Rolf Timmermans + +Rolf van de Krol + +Roy Crihfield + +Ruud van Asseldonk + +Sean Collins + +Sean Gillespie + +Sean Jensen-Grey + +Sean McArthur + +Sean T Allen + +Seo Sanghyeon + +Seth Pollack + +sheroze1123 + +Simonas Kazlauskas + +Simon Sapin + +Simon Wollwage + +Son + +Stefan Bucur + +Stepan Koltsov + +Steve Klabnik + +Steven Fackler + +Stuart Pernsteiner + +Subhash Bhushan + +Tamir Duberstein + +Taylor Hutchison + +th0114nd + +thiagopnts + +Timon Rapp + +Titouan Vervack + +Tobias Bucher + +Tom Jakubowski + +tshakah + +Tshepang Lekhonkhobe + +Ulysse Carion + +Utkarsh Kukreti + +Vadim Chugunov + +Vadim Petrochenkov + +Valerii Hiora + +Victor Berger + +Victor van den Elzen + +Viktor Dahl + +ville-h + +Vitali Haravy + +Vladimir Matveev + +Vladimir Smola + +we + +whataloadofwhat + +YawarRaza7349 + +York Xiang + +Zbigniew Siciarz + +Ziad Hatahet + +``` From 2c7d51009a5f096da6707ab7703b1f7e73b91c16 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 9 Jan 2015 10:24:29 -0800 Subject: [PATCH 36/74] Revert "Space out contribs" This reverts commit c93ca39fb4d53882854a8ba97f826616a38dcef6. --- _posts/2015-01-09-Rust-1.0-alpha.md | 752 +++++++++------------------- 1 file changed, 250 insertions(+), 502 deletions(-) diff --git a/_posts/2015-01-09-Rust-1.0-alpha.md b/_posts/2015-01-09-Rust-1.0-alpha.md index dc49ebbbe..a363e0e54 100644 --- a/_posts/2015-01-09-Rust-1.0-alpha.md +++ b/_posts/2015-01-09-Rust-1.0-alpha.md @@ -112,505 +112,253 @@ And, of course, we will continue to fix bugs and add polish throughout the alpha This alpha release could not have happened without the help of Rust's enthusiastic community. Thanks go to: -``` -Aaron Friel - -Aaron Liblong - -Aaron Turon - -Aaron Weiss - -Adam Szkoda - -Adolfo Ochagavía - -Adrien Tétar - -Aidan Cully - -A.J. Gardner - -Akos Kiss - -Aleksandr Koshlo - -Alexander Light - -Alex Crichton - -Alex Gaynor - -Alexis Beingessner - -Alex Lyon - -Alfie John - -Andrea Canciani - -Andrew Cann - -Andrew Paseltiner - -Andrew Wagner - -areski - -Ariel Ben-Yehuda - -Artem - -Arthur Liao - -arturo - -Austin Bonander - -Barosl Lee - -Ben Foppa - -Ben Gamari - -Ben S - -Bheesham Persaud - -Björn Steinbrink - -bluss - -bombless - -Boris Egorov - -bors - -Brandon Sanderson - -Brendan Zabarauskas - -Brian Anderson - -Brian J Brennan - -Brian Koropoff - -Carol Nichols - -Chase Southwood - -Chris Morgan - -Chris Wong - -Clark Gaebel - -Cody P Schafer - -Colin Sherratt - -Corey Farwell - -Corey Ford - -Corey Richardson - -crhino - -Cristi Burcă - -Damien Radtke - -Dan Burkert - -dan@daramos.com - -Daniel Hofstetter - -Daniel Micay - -Dan Luu - -David Creswick - -Davis Silverman - -Diego Giagio - -Dirk Gadsden - -Earl St Sauver - -Eduard Burtescu - -Eduardo Bautista - -elszben - -Eric Allen - -Eric Kidd - -Erick Tryzelaar - -Erwan - -Fabrice Desré - -FakeKane - -Falco Hirschenberger - -Felix Raimundo - -Felix S. Klock II - -Flavio Percoco - -Florian Gilcher - -Florian Hahn - -Florian Wilkens - -gamazeps - -Gil Cottle - -Gleb Kozyrev - -Graham Fawcett - -Guillaume Pinot - -Huon Wilson - -Ian Connolly - -inrustwetrust - -Ivan Petkov - -Ivan Ukhov - -Jacob Edelman - -Jake Goulding - -Jakub Bukaj - -James Miller - -Jared Roesch - -Jarod Liu - -Jashank Jeremy - -Jauhien Piatlicki - -jbranchaud - -Jeff Parsons - -Jelte Fennema - -jfager - -Jim Apple - -jmu303 - -Johannes Hoff - -Johannes Muenzel - -John Albietz - -John Gallagher - -John Kåre Alsaker - -John Kleint - -Jonathan Reem - -Jonathan S - -Jon Haddad - -JONNALAGADDA Srinivas - -Joonas Javanainen - -Jorge Aparicio - -Joseph Crail - -Joseph Rushton Wakeling - -Josh Haberman - -Josh Stone - -Joshua Yanovski - -jrincayc - -Julian Orth - -juxiliary - -jxv - -Kang Seonghoon - -Kasey Carrothers - -Keegan McAllister - -Ken Tossell - -Kevin Ballard - -Kevin Mehall - -Kevin Yap - -klutzy - -kulakowski - -Laurence Tratt - -Liigo Zhuang - -Lionel Flandrin - -Luke Metz - -Luqman Aden - -Manish Goregaokar - -Markus Siemens - -Martin Pool - -Marvin Löbel - -Matej Lach - -Mathieu Poumeyrol - -Matt McPherrin - -Matt Murphy - -Matt Windsor - -Maxime Quandalle - -Maximilian Haack - -Maya Nitu - -mchaput - -mdinger - -Michael Gehring - -Michael Neumann - -Michael Sproul - -Michael Woerister - -Mike Dilger - -Mike Pedersen - -Mike Robinson - -Ms2ger - -Mukilan Thiyagarajan - -Murarth - -Nafis - -Nathan Zadoks - -Neil Pankey - -Nicholas Bishop - -Nick Cameron - -Nick Howell - -Niels Egberts - -Niko Matsakis - -NODA, Kai - -OGINO Masanori - -oli-obk - -Oliver Schneider - -olivren - -P1start - -Pascal Hertleif - -Patrick Walton - -Paul Collier - -Pedro Larroy - -Peter Atashian - -Peter Elmers - -Phil Dawes - -Philip Munksgaard - -Philipp Gesang - -Piotr Czarnecki - -Piotr Jawniak - -Piotr Szotkowski - -qwitwa - -Raphael Speyer - -Ray Clanan - -Richard Diamond - -Richo Healey - -Ricky Taylor - -rjz - -Robin Gloster - -Robin Stocker - -Rohit Joshi - -Rolf Timmermans - -Rolf van de Krol - -Roy Crihfield - -Ruud van Asseldonk - -Sean Collins - -Sean Gillespie - -Sean Jensen-Grey - -Sean McArthur - -Sean T Allen - -Seo Sanghyeon - -Seth Pollack - -sheroze1123 - -Simonas Kazlauskas - -Simon Sapin - -Simon Wollwage - -Son - -Stefan Bucur - -Stepan Koltsov - -Steve Klabnik - -Steven Fackler - -Stuart Pernsteiner - -Subhash Bhushan - -Tamir Duberstein - -Taylor Hutchison - -th0114nd - -thiagopnts - -Timon Rapp - -Titouan Vervack - -Tobias Bucher - -Tom Jakubowski - -tshakah - -Tshepang Lekhonkhobe - -Ulysse Carion - -Utkarsh Kukreti - -Vadim Chugunov - -Vadim Petrochenkov - -Valerii Hiora - -Victor Berger - -Victor van den Elzen - -Viktor Dahl - -ville-h - -Vitali Haravy - -Vladimir Matveev - -Vladimir Smola - -we - -whataloadofwhat - -YawarRaza7349 - -York Xiang - -Zbigniew Siciarz - -Ziad Hatahet - -``` +* Aaron Friel +* Aaron Liblong +* Aaron Turon +* Aaron Weiss +* Adam Szkoda +* Adolfo Ochagavía +* Adrien Tétar +* Aidan Cully +* A.J. Gardner +* Akos Kiss +* Aleksandr Koshlo +* Alexander Light +* Alex Crichton +* Alex Gaynor +* Alexis Beingessner +* Alex Lyon +* Alfie John +* Andrea Canciani +* Andrew Cann +* Andrew Paseltiner +* Andrew Wagner +* areski +* Ariel Ben-Yehuda +* Artem +* Arthur Liao +* arturo +* Austin Bonander +* Barosl Lee +* Ben Foppa +* Ben Gamari +* Ben S +* Bheesham Persaud +* Björn Steinbrink +* bluss +* bombless +* Boris Egorov +* bors +* Brandon Sanderson +* Brendan Zabarauskas +* Brian Anderson +* Brian J Brennan +* Brian Koropoff +* Carol Nichols +* Chase Southwood +* Chris Morgan +* Chris Wong +* Clark Gaebel +* Cody P Schafer +* Colin Sherratt +* Corey Farwell +* Corey Ford +* Corey Richardson +* crhino +* Cristi Burcă +* Damien Radtke +* Dan Burkert +* dan@daramos.com +* Daniel Hofstetter +* Daniel Micay +* Dan Luu +* David Creswick +* Davis Silverman +* Diego Giagio +* Dirk Gadsden +* Earl St Sauver +* Eduard Burtescu +* Eduardo Bautista +* elszben +* Eric Allen +* Eric Kidd +* Erick Tryzelaar +* Erwan +* Fabrice Desré +* FakeKane +* Falco Hirschenberger +* Felix Raimundo +* Felix S. Klock II +* Flavio Percoco +* Florian Gilcher +* Florian Hahn +* Florian Wilkens +* gamazeps +* Gil Cottle +* Gleb Kozyrev +* Graham Fawcett +* Guillaume Pinot +* Huon Wilson +* Ian Connolly +* inrustwetrust +* Ivan Petkov +* Ivan Ukhov +* Jacob Edelman +* Jake Goulding +* Jakub Bukaj +* James Miller +* Jared Roesch +* Jarod Liu +* Jashank Jeremy +* Jauhien Piatlicki +* jbranchaud +* Jeff Parsons +* Jelte Fennema +* jfager +* Jim Apple +* jmu303 +* Johannes Hoff +* Johannes Muenzel +* John Albietz +* John Gallagher +* John Kåre Alsaker +* John Kleint +* Jonathan Reem +* Jonathan S +* Jon Haddad +* JONNALAGADDA Srinivas +* Joonas Javanainen +* Jorge Aparicio +* Joseph Crail +* Joseph Rushton Wakeling +* Josh Haberman +* Josh Stone +* Joshua Yanovski +* jrincayc +* Julian Orth +* juxiliary +* jxv +* Kang Seonghoon +* Kasey Carrothers +* Keegan McAllister +* Ken Tossell +* Kevin Ballard +* Kevin Mehall +* Kevin Yap +* klutzy +* kulakowski +* Laurence Tratt +* Liigo Zhuang +* Lionel Flandrin +* Luke Metz +* Luqman Aden +* Manish Goregaokar +* Markus Siemens +* Martin Pool +* Marvin Löbel +* Matej Lach +* Mathieu Poumeyrol +* Matt McPherrin +* Matt Murphy +* Matt Windsor +* Maxime Quandalle +* Maximilian Haack +* Maya Nitu +* mchaput +* mdinger +* Michael Gehring +* Michael Neumann +* Michael Sproul +* Michael Woerister +* Mike Dilger +* Mike Pedersen +* Mike Robinson +* Ms2ger +* Mukilan Thiyagarajan +* Murarth +* Nafis +* Nathan Zadoks +* Neil Pankey +* Nicholas Bishop +* Nick Cameron +* Nick Howell +* Niels Egberts +* Niko Matsakis +* NODA, Kai +* OGINO Masanori +* oli-obk +* Oliver Schneider +* olivren +* P1start +* Pascal Hertleif +* Patrick Walton +* Paul Collier +* Pedro Larroy +* Peter Atashian +* Peter Elmers +* Phil Dawes +* Philip Munksgaard +* Philipp Gesang +* Piotr Czarnecki +* Piotr Jawniak +* Piotr Szotkowski +* qwitwa +* Raphael Speyer +* Ray Clanan +* Richard Diamond +* Richo Healey +* Ricky Taylor +* rjz +* Robin Gloster +* Robin Stocker +* Rohit Joshi +* Rolf Timmermans +* Rolf van de Krol +* Roy Crihfield +* Ruud van Asseldonk +* Sean Collins +* Sean Gillespie +* Sean Jensen-Grey +* Sean McArthur +* Sean T Allen +* Seo Sanghyeon +* Seth Pollack +* sheroze1123 +* Simonas Kazlauskas +* Simon Sapin +* Simon Wollwage +* Son +* Stefan Bucur +* Stepan Koltsov +* Steve Klabnik +* Steven Fackler +* Stuart Pernsteiner +* Subhash Bhushan +* Tamir Duberstein +* Taylor Hutchison +* th0114nd +* thiagopnts +* Timon Rapp +* Titouan Vervack +* Tobias Bucher +* Tom Jakubowski +* tshakah +* Tshepang Lekhonkhobe +* Ulysse Carion +* Utkarsh Kukreti +* Vadim Chugunov +* Vadim Petrochenkov +* Valerii Hiora +* Victor Berger +* Victor van den Elzen +* Viktor Dahl +* ville-h +* Vitali Haravy +* Vladimir Matveev +* Vladimir Smola +* we +* whataloadofwhat +* YawarRaza7349 +* York Xiang +* Zbigniew Siciarz +* Ziad Hatahet From 1f480dd2508725c611e33f473e2083d51afebd09 Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Fri, 9 Jan 2015 10:26:21 -0800 Subject: [PATCH 37/74] Put contributors in code + bulleted list --- _posts/2015-01-09-Rust-1.0-alpha.md | 500 ++++++++++++++-------------- 1 file changed, 250 insertions(+), 250 deletions(-) diff --git a/_posts/2015-01-09-Rust-1.0-alpha.md b/_posts/2015-01-09-Rust-1.0-alpha.md index a363e0e54..511581a6b 100644 --- a/_posts/2015-01-09-Rust-1.0-alpha.md +++ b/_posts/2015-01-09-Rust-1.0-alpha.md @@ -112,253 +112,253 @@ And, of course, we will continue to fix bugs and add polish throughout the alpha This alpha release could not have happened without the help of Rust's enthusiastic community. Thanks go to: -* Aaron Friel -* Aaron Liblong -* Aaron Turon -* Aaron Weiss -* Adam Szkoda -* Adolfo Ochagavía -* Adrien Tétar -* Aidan Cully -* A.J. Gardner -* Akos Kiss -* Aleksandr Koshlo -* Alexander Light -* Alex Crichton -* Alex Gaynor -* Alexis Beingessner -* Alex Lyon -* Alfie John -* Andrea Canciani -* Andrew Cann -* Andrew Paseltiner -* Andrew Wagner -* areski -* Ariel Ben-Yehuda -* Artem -* Arthur Liao -* arturo -* Austin Bonander -* Barosl Lee -* Ben Foppa -* Ben Gamari -* Ben S -* Bheesham Persaud -* Björn Steinbrink -* bluss -* bombless -* Boris Egorov -* bors -* Brandon Sanderson -* Brendan Zabarauskas -* Brian Anderson -* Brian J Brennan -* Brian Koropoff -* Carol Nichols -* Chase Southwood -* Chris Morgan -* Chris Wong -* Clark Gaebel -* Cody P Schafer -* Colin Sherratt -* Corey Farwell -* Corey Ford -* Corey Richardson -* crhino -* Cristi Burcă -* Damien Radtke -* Dan Burkert -* dan@daramos.com -* Daniel Hofstetter -* Daniel Micay -* Dan Luu -* David Creswick -* Davis Silverman -* Diego Giagio -* Dirk Gadsden -* Earl St Sauver -* Eduard Burtescu -* Eduardo Bautista -* elszben -* Eric Allen -* Eric Kidd -* Erick Tryzelaar -* Erwan -* Fabrice Desré -* FakeKane -* Falco Hirschenberger -* Felix Raimundo -* Felix S. Klock II -* Flavio Percoco -* Florian Gilcher -* Florian Hahn -* Florian Wilkens -* gamazeps -* Gil Cottle -* Gleb Kozyrev -* Graham Fawcett -* Guillaume Pinot -* Huon Wilson -* Ian Connolly -* inrustwetrust -* Ivan Petkov -* Ivan Ukhov -* Jacob Edelman -* Jake Goulding -* Jakub Bukaj -* James Miller -* Jared Roesch -* Jarod Liu -* Jashank Jeremy -* Jauhien Piatlicki -* jbranchaud -* Jeff Parsons -* Jelte Fennema -* jfager -* Jim Apple -* jmu303 -* Johannes Hoff -* Johannes Muenzel -* John Albietz -* John Gallagher -* John Kåre Alsaker -* John Kleint -* Jonathan Reem -* Jonathan S -* Jon Haddad -* JONNALAGADDA Srinivas -* Joonas Javanainen -* Jorge Aparicio -* Joseph Crail -* Joseph Rushton Wakeling -* Josh Haberman -* Josh Stone -* Joshua Yanovski -* jrincayc -* Julian Orth -* juxiliary -* jxv -* Kang Seonghoon -* Kasey Carrothers -* Keegan McAllister -* Ken Tossell -* Kevin Ballard -* Kevin Mehall -* Kevin Yap -* klutzy -* kulakowski -* Laurence Tratt -* Liigo Zhuang -* Lionel Flandrin -* Luke Metz -* Luqman Aden -* Manish Goregaokar -* Markus Siemens -* Martin Pool -* Marvin Löbel -* Matej Lach -* Mathieu Poumeyrol -* Matt McPherrin -* Matt Murphy -* Matt Windsor -* Maxime Quandalle -* Maximilian Haack -* Maya Nitu -* mchaput -* mdinger -* Michael Gehring -* Michael Neumann -* Michael Sproul -* Michael Woerister -* Mike Dilger -* Mike Pedersen -* Mike Robinson -* Ms2ger -* Mukilan Thiyagarajan -* Murarth -* Nafis -* Nathan Zadoks -* Neil Pankey -* Nicholas Bishop -* Nick Cameron -* Nick Howell -* Niels Egberts -* Niko Matsakis -* NODA, Kai -* OGINO Masanori -* oli-obk -* Oliver Schneider -* olivren -* P1start -* Pascal Hertleif -* Patrick Walton -* Paul Collier -* Pedro Larroy -* Peter Atashian -* Peter Elmers -* Phil Dawes -* Philip Munksgaard -* Philipp Gesang -* Piotr Czarnecki -* Piotr Jawniak -* Piotr Szotkowski -* qwitwa -* Raphael Speyer -* Ray Clanan -* Richard Diamond -* Richo Healey -* Ricky Taylor -* rjz -* Robin Gloster -* Robin Stocker -* Rohit Joshi -* Rolf Timmermans -* Rolf van de Krol -* Roy Crihfield -* Ruud van Asseldonk -* Sean Collins -* Sean Gillespie -* Sean Jensen-Grey -* Sean McArthur -* Sean T Allen -* Seo Sanghyeon -* Seth Pollack -* sheroze1123 -* Simonas Kazlauskas -* Simon Sapin -* Simon Wollwage -* Son -* Stefan Bucur -* Stepan Koltsov -* Steve Klabnik -* Steven Fackler -* Stuart Pernsteiner -* Subhash Bhushan -* Tamir Duberstein -* Taylor Hutchison -* th0114nd -* thiagopnts -* Timon Rapp -* Titouan Vervack -* Tobias Bucher -* Tom Jakubowski -* tshakah -* Tshepang Lekhonkhobe -* Ulysse Carion -* Utkarsh Kukreti -* Vadim Chugunov -* Vadim Petrochenkov -* Valerii Hiora -* Victor Berger -* Victor van den Elzen -* Viktor Dahl -* ville-h -* Vitali Haravy -* Vladimir Matveev -* Vladimir Smola -* we -* whataloadofwhat -* YawarRaza7349 -* York Xiang -* Zbigniew Siciarz -* Ziad Hatahet +* `Aaron Friel ` +* `Aaron Liblong ` +* `Aaron Turon ` +* `Aaron Weiss ` +* `Adam Szkoda ` +* `Adolfo Ochagavía ` +* `Adrien Tétar ` +* `Aidan Cully ` +* `A.J. Gardner ` +* `Akos Kiss ` +* `Aleksandr Koshlo ` +* `Alexander Light ` +* `Alex Crichton ` +* `Alex Gaynor ` +* `Alexis Beingessner ` +* `Alex Lyon ` +* `Alfie John ` +* `Andrea Canciani ` +* `Andrew Cann ` +* `Andrew Paseltiner ` +* `Andrew Wagner ` +* `areski ` +* `Ariel Ben-Yehuda ` +* `Artem ` +* `Arthur Liao ` +* `arturo ` +* `Austin Bonander ` +* `Barosl Lee ` +* `Ben Foppa ` +* `Ben Gamari ` +* `Ben S ` +* `Bheesham Persaud ` +* `Björn Steinbrink ` +* `bluss ` +* `bombless ` +* `Boris Egorov ` +* `bors ` +* `Brandon Sanderson ` +* `Brendan Zabarauskas ` +* `Brian Anderson ` +* `Brian J Brennan ` +* `Brian Koropoff ` +* `Carol Nichols ` +* `Chase Southwood ` +* `Chris Morgan ` +* `Chris Wong ` +* `Clark Gaebel ` +* `Cody P Schafer ` +* `Colin Sherratt ` +* `Corey Farwell ` +* `Corey Ford ` +* `Corey Richardson ` +* `crhino ` +* `Cristi Burcă ` +* `Damien Radtke ` +* `Dan Burkert ` +* `dan@daramos.com ` +* `Daniel Hofstetter ` +* `Daniel Micay ` +* `Dan Luu ` +* `David Creswick ` +* `Davis Silverman ` +* `Diego Giagio ` +* `Dirk Gadsden ` +* `Earl St Sauver ` +* `Eduard Burtescu ` +* `Eduardo Bautista ` +* `elszben ` +* `Eric Allen ` +* `Eric Kidd ` +* `Erick Tryzelaar ` +* `Erwan ` +* `Fabrice Desré ` +* `FakeKane ` +* `Falco Hirschenberger ` +* `Felix Raimundo ` +* `Felix S. Klock II ` +* `Flavio Percoco ` +* `Florian Gilcher ` +* `Florian Hahn ` +* `Florian Wilkens ` +* `gamazeps ` +* `Gil Cottle ` +* `Gleb Kozyrev ` +* `Graham Fawcett ` +* `Guillaume Pinot ` +* `Huon Wilson ` +* `Ian Connolly ` +* `inrustwetrust ` +* `Ivan Petkov ` +* `Ivan Ukhov ` +* `Jacob Edelman ` +* `Jake Goulding ` +* `Jakub Bukaj ` +* `James Miller ` +* `Jared Roesch ` +* `Jarod Liu ` +* `Jashank Jeremy ` +* `Jauhien Piatlicki ` +* `jbranchaud ` +* `Jeff Parsons ` +* `Jelte Fennema ` +* `jfager ` +* `Jim Apple ` +* `jmu303 ` +* `Johannes Hoff ` +* `Johannes Muenzel ` +* `John Albietz ` +* `John Gallagher ` +* `John Kåre Alsaker ` +* `John Kleint ` +* `Jonathan Reem ` +* `Jonathan S ` +* `Jon Haddad ` +* `JONNALAGADDA Srinivas ` +* `Joonas Javanainen ` +* `Jorge Aparicio ` +* `Joseph Crail ` +* `Joseph Rushton Wakeling ` +* `Josh Haberman ` +* `Josh Stone ` +* `Joshua Yanovski ` +* `jrincayc ` +* `Julian Orth ` +* `juxiliary ` +* `jxv ` +* `Kang Seonghoon ` +* `Kasey Carrothers ` +* `Keegan McAllister ` +* `Ken Tossell ` +* `Kevin Ballard ` +* `Kevin Mehall ` +* `Kevin Yap ` +* `klutzy ` +* `kulakowski ` +* `Laurence Tratt ` +* `Liigo Zhuang ` +* `Lionel Flandrin ` +* `Luke Metz ` +* `Luqman Aden ` +* `Manish Goregaokar ` +* `Markus Siemens ` +* `Martin Pool ` +* `Marvin Löbel ` +* `Matej Lach ` +* `Mathieu Poumeyrol ` +* `Matt McPherrin ` +* `Matt Murphy ` +* `Matt Windsor ` +* `Maxime Quandalle ` +* `Maximilian Haack ` +* `Maya Nitu ` +* `mchaput ` +* `mdinger ` +* `Michael Gehring ` +* `Michael Neumann ` +* `Michael Sproul ` +* `Michael Woerister ` +* `Mike Dilger ` +* `Mike Pedersen ` +* `Mike Robinson ` +* `Ms2ger ` +* `Mukilan Thiyagarajan ` +* `Murarth ` +* `Nafis ` +* `Nathan Zadoks ` +* `Neil Pankey ` +* `Nicholas Bishop ` +* `Nick Cameron ` +* `Nick Howell ` +* `Niels Egberts ` +* `Niko Matsakis ` +* `NODA, Kai ` +* `OGINO Masanori ` +* `oli-obk ` +* `Oliver Schneider ` +* `olivren ` +* `P1start ` +* `Pascal Hertleif ` +* `Patrick Walton ` +* `Paul Collier ` +* `Pedro Larroy ` +* `Peter Atashian ` +* `Peter Elmers ` +* `Phil Dawes ` +* `Philip Munksgaard ` +* `Philipp Gesang ` +* `Piotr Czarnecki ` +* `Piotr Jawniak ` +* `Piotr Szotkowski ` +* `qwitwa ` +* `Raphael Speyer ` +* `Ray Clanan ` +* `Richard Diamond ` +* `Richo Healey ` +* `Ricky Taylor ` +* `rjz ` +* `Robin Gloster ` +* `Robin Stocker ` +* `Rohit Joshi ` +* `Rolf Timmermans ` +* `Rolf van de Krol ` +* `Roy Crihfield ` +* `Ruud van Asseldonk ` +* `Sean Collins ` +* `Sean Gillespie ` +* `Sean Jensen-Grey ` +* `Sean McArthur ` +* `Sean T Allen ` +* `Seo Sanghyeon ` +* `Seth Pollack ` +* `sheroze1123 ` +* `Simonas Kazlauskas ` +* `Simon Sapin ` +* `Simon Wollwage ` +* `Son ` +* `Stefan Bucur ` +* `Stepan Koltsov ` +* `Steve Klabnik ` +* `Steven Fackler ` +* `Stuart Pernsteiner ` +* `Subhash Bhushan ` +* `Tamir Duberstein ` +* `Taylor Hutchison ` +* `th0114nd ` +* `thiagopnts ` +* `Timon Rapp ` +* `Titouan Vervack ` +* `Tobias Bucher ` +* `Tom Jakubowski ` +* `tshakah ` +* `Tshepang Lekhonkhobe ` +* `Ulysse Carion ` +* `Utkarsh Kukreti ` +* `Vadim Chugunov ` +* `Vadim Petrochenkov ` +* `Valerii Hiora ` +* `Victor Berger ` +* `Victor van den Elzen ` +* `Viktor Dahl ` +* `ville-h ` +* `Vitali Haravy ` +* `Vladimir Matveev ` +* `Vladimir Smola ` +* `we ` +* `whataloadofwhat ` +* `YawarRaza7349 ` +* `York Xiang ` +* `Zbigniew Siciarz ` +* `Ziad Hatahet ` From c643b71dfd84cfd262ebfa281b56c1882aa5a789 Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Fri, 9 Jan 2015 10:44:14 -0800 Subject: [PATCH 38/74] Fix "Jump straight in" link Closes #18 --- _includes/footer.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_includes/footer.html b/_includes/footer.html index f2d236e92..f33228c0d 100644 --- a/_includes/footer.html +++ b/_includes/footer.html @@ -1,4 +1,4 @@ -
More about Rust — Jump straight in
+
More about Rust — Jump straight in
From 75b1ef1aa0000748d67622b1633b36a180fe53f3 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 9 Jan 2015 11:10:28 -0800 Subject: [PATCH 39/74] Clarify credits --- _posts/2015-01-09-Rust-1.0-alpha.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/2015-01-09-Rust-1.0-alpha.md b/_posts/2015-01-09-Rust-1.0-alpha.md index 511581a6b..ea0c496dc 100644 --- a/_posts/2015-01-09-Rust-1.0-alpha.md +++ b/_posts/2015-01-09-Rust-1.0-alpha.md @@ -69,9 +69,9 @@ All of these language features have been rolled out throughout the standard libr [RFCs](https://github.com/rust-lang/rfcs/pull/445) have been approved, and are largely summarized [in the Rust Guidelines](http://aturon.github.io/); these conventions have been rolled out through all `#[stable]` parts of `std`. *Led by Aaron Turon*. -* **Stable core types and traits:** All of the primitive types and basic building blocks (like `char`, `String`, `Vec`, `Box`, `Arc`, `RefCell` and so on) are now `#[stable]`. *Implemented by Aaron Turon, Alex Crichton, Brian Anderson, Brendan Zabarauskas and Huon Wilson*. +* **Stable core types and traits:** All of the primitive types and basic building blocks (like `char`, `String`, `Vec`, `Box`, `Arc`, `RefCell` and so on) are now `#[stable]`. *Stabilized by Aaron Turon, Alex Crichton, Brian Anderson, Brendan Zabarauskas and Huon Wilson*. -* **Iterators and collections:** A [series](https://github.com/rust-lang/rfcs/pull/216) [of](https://github.com/rust-lang/rfcs/pull/235) [RFCs](https://github.com/rust-lang/rfcs/pull/509) have been implemented to revamp and stabilize the collections APIs; iterators are also `#[stable]`. *Designed by Aaron Turon and Alexis Beingessner, implemented together with Chase Southwood, Piotr Czarnecki, Félix Raimundo, Clark Gaebel and others.* +* **Iterators and collections:** A [series](https://github.com/rust-lang/rfcs/pull/216) [of](https://github.com/rust-lang/rfcs/pull/235) [RFCs](https://github.com/rust-lang/rfcs/pull/509) have been implemented to revamp and stabilize the collections APIs; iterators are also `#[stable]`. *RFCs by Aaron Turon and Alexis Beingessner, stabilized together with Chase Southwood, Piotr Czarnecki, Félix Raimundo, Clark Gaebel and others.* * **Concurrency primitives:** Rust's concurrency modules have seen an overhaul, including [thread-local storage](https://github.com/rust-lang/rfcs/pull/461), [synchronization primitives](https://github.com/rust-lang/rust/pull/19274/), and a new [thread API](https://github.com/rust-lang/rust/pull/20615) that will soon allow child threads to share data on their parent's stack. These APIs are more efficient and idiomatic than previous versions, and most are already `#[stable]`. *Implemented by Alex Crichton and Aaron Turon*. From 7f30e2468e0f22a35741d2cfc399a88726a622d3 Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Fri, 9 Jan 2015 11:15:25 -0800 Subject: [PATCH 40/74] Add google analytics --- _includes/footer.html | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/_includes/footer.html b/_includes/footer.html index f33228c0d..6370c4df6 100644 --- a/_includes/footer.html +++ b/_includes/footer.html @@ -49,3 +49,14 @@

{{ site.title }}

+ + From 2a86f1db73b1c4737f9488633f158da182c07884 Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Fri, 9 Jan 2015 11:19:24 -0800 Subject: [PATCH 41/74] Update analytics tracking number --- _includes/footer.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_includes/footer.html b/_includes/footer.html index 6370c4df6..9e267faee 100644 --- a/_includes/footer.html +++ b/_includes/footer.html @@ -56,7 +56,7 @@

{{ site.title }}

m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); - ga('create', 'UA-58390457-1', 'auto'); + ga('create', 'UA-58390457-2', 'auto'); ga('send', 'pageview'); From 382823b01273b6f3f0c675e7dd75f37f44f70e88 Mon Sep 17 00:00:00 2001 From: Huon Wilson Date: Tue, 13 Jan 2015 00:31:50 +1100 Subject: [PATCH 42/74] Add some xml_escape's to twitter cards. Quotes etc. in titles or descriptions will make HTML & twitter unhappy without these. --- _includes/head.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_includes/head.html b/_includes/head.html index 2aceb33cd..8dba01e36 100644 --- a/_includes/head.html +++ b/_includes/head.html @@ -13,9 +13,9 @@ {% if page.description %} - + {% else %} - + {% endif %} From 32b3922fb2b1e21e411d53650906e4596ffabe79 Mon Sep 17 00:00:00 2001 From: Steve Klabnik Date: Mon, 12 Jan 2015 11:40:50 -0500 Subject: [PATCH 43/74] Add @dylanede to 1.0 alpha contributors list https://github.com/rust-lang/rust/commit/25eada15740fbe12ee2cae7fc6fe8e2c228b699d was in alpha, but Dylan wasn't credited. --- _posts/2015-01-09-Rust-1.0-alpha.md | 1 + 1 file changed, 1 insertion(+) diff --git a/_posts/2015-01-09-Rust-1.0-alpha.md b/_posts/2015-01-09-Rust-1.0-alpha.md index ea0c496dc..425663a63 100644 --- a/_posts/2015-01-09-Rust-1.0-alpha.md +++ b/_posts/2015-01-09-Rust-1.0-alpha.md @@ -176,6 +176,7 @@ This alpha release could not have happened without the help of Rust's enthusiast * `Davis Silverman ` * `Diego Giagio ` * `Dirk Gadsden ` +* `Dylan Ede ` * `Earl St Sauver ` * `Eduard Burtescu ` * `Eduardo Bautista ` From 3cead0e4c4b7eee43c4c84a6d3a1bda665f7e561 Mon Sep 17 00:00:00 2001 From: Steve Klabnik Date: Tue, 13 Jan 2015 11:02:46 -0500 Subject: [PATCH 44/74] Update @rohitjoshi's email --- _posts/2015-01-09-Rust-1.0-alpha.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2015-01-09-Rust-1.0-alpha.md b/_posts/2015-01-09-Rust-1.0-alpha.md index 425663a63..d89b7db91 100644 --- a/_posts/2015-01-09-Rust-1.0-alpha.md +++ b/_posts/2015-01-09-Rust-1.0-alpha.md @@ -312,7 +312,7 @@ This alpha release could not have happened without the help of Rust's enthusiast * `rjz ` * `Robin Gloster ` * `Robin Stocker ` -* `Rohit Joshi ` +* `Rohit Joshi ` * `Rolf Timmermans ` * `Rolf van de Krol ` * `Roy Crihfield ` From 69c3cdf5b1b2caf79f10fa897aeb1e46f3feda7e Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 13 Feb 2015 11:16:06 -0800 Subject: [PATCH 45/74] Blog post: Rust 1.0: status report and final timeline --- _posts/2015-02-13-Final-1.0-timeline.md | 168 ++++++++++++++++++++++++ 1 file changed, 168 insertions(+) create mode 100644 _posts/2015-02-13-Final-1.0-timeline.md diff --git a/_posts/2015-02-13-Final-1.0-timeline.md b/_posts/2015-02-13-Final-1.0-timeline.md new file mode 100644 index 000000000..70cbaba12 --- /dev/null +++ b/_posts/2015-02-13-Final-1.0-timeline.md @@ -0,0 +1,168 @@ +--- +layout: post +title: "Rust 1.0: status report and final timeline" +author: The Rust Core Team +--- + +It's been five weeks since we released Rust 1.0-alpha! Before this +release cycle finishes next week, we want to give a status report and +update on the road to 1.0 final. + +**TL;DR: Rust 1.0 final will be released by May 15, 2015** + +## What is the overall timeline? + +Based on the progress in this release cycle, we are now comfortable +committing to a precise release schedule for 1.0: + +* Rust 1.0-alpha2 -- Feb 20 +* All 1.0 modules stable on nightly -- around Mar 9 +* Rust 1.0-beta -- Mar 31 +* Rust 1.0 -- May 15 + +This schedule differs from the +[previous one](http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html) +by nailing down an exact set of release cycles. It also opts for a +second alpha release and only a single beta release. + +The main reason for calling the next release alpha2 rather than beta1 +is that new path and IO APIs have only recently landed, and we would +like more time to collect feedback before marking the new path and IO +APIs stable. More details are below. + +## What's shipping in alpha2? + +We've managed to land almost all of the features +[previously expected](http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html) +for this cycle. + +**The big headline here is that all major API revisions are +finished**: path and IO reform have landed. At this point, all modules +shipping for 1.0 are in what we expect to be their final form, modulo +minor tweaks during the alpha2 cycle. + +Other highlights are as follows: + +* **Closures**: Rust now supports + [full capture-clause inference](https://github.com/rust-lang/rfcs/blob/master/text/0231-upvar-capture-inference.md) + and has deprecated the temporary `|:|` notation, making closures + much more ergonomic to use. + +* **Destructors**: New + [destructor rules](https://github.com/rust-lang/rfcs/pull/769) + landed, obviating the need for `#[unsafe destructor]`. + +* **Path reform**: The `path` module has been completely + [redesigned](https://github.com/rust-lang/rfcs/pull/474) to resolve + a number of semantic and ergonomic problems with the old module, and + to take advantage of DST. + +* **IO reform**: The `io` system has been + [thoroughly revised](https://github.com/rust-lang/rfcs/blob/master/text/0517-io-os-reform.md) + to improve robustness and cross-platform behavior, and to eschew + ambitious high-level abstractions over the system. While almost all + of the APIs are effected by this change, the changes move toward a + much more conservative and consistent design. + +* **Deref coercions**: A + [new coercion](https://github.com/rust-lang/rfcs/pull/241) will + follow smart pointers, so that you can pass `&Vec` where `&[T]` + is wanted, or `&Arc` where `&T` is wanted. This removes most need + for explicit slicing or the dreaded "cross-borrowing" `&*`, and + means that `&` can be thought of as a general "borrow" operator. + +* **Feature staging**: Rust now has a notion of + [named API *features*](https://github.com/rust-lang/rfcs/pull/475) + akin to language features, which is how we will manage API + stabilization going forward. These named features make it easier to + manage progress in `std`, and make it plausible to detect the + minimum version of Rust needed for a crate. + +* **For loops**: The new `IntoIterator` trait is now available and + used for `for` loops, making it possible to write `for x in &vec` + rather than `for x in vec.iter()`. + +* **Range notation**: We have + [finalized range notation](https://github.com/rust-lang/rfcs/pull/702), + introducing `..` for "full ranges", which will make APIs like + `collection.remove(..)` possible in the future. + +* **Trait system**: New coherence rules were + [finalized](http://internals.rust-lang.org/t/orphan-rules/1322), + providing both flexibility and soundness for trait implementations. + +* **Overflow semantics**: After a long debate, the final integer + overflow semantics has + [been decided](https://github.com/rust-lang/rfcs/pull/560) and is + expected to land for alpha2. This change is expected to make it much + easier to find over/underflow bugs when used in conjunction with + fuzzing, etc. + +* **Associated types**: many compiler bugs around associated types + have been fixed, making them usable at large scale. + +Some other changes have not landed at the time of writing but are +expected for alpha2: +[variance for type parameters](https://github.com/rust-lang/rfcs/pull/738), +[Send changes](https://github.com/rust-lang/rfcs/pull/458), and +[the great integer audit](https://github.com/rust-lang/rust/issues/22240). + +Complete details will be available in the release notes next week. + +## Why another alpha? + +The main reason is that we want to leave recently-landed APIs, like IO +and path, unstable for a few more weeks while we collect feedback -- +but the beta release is intended to disallow use of unstable features. + +In more detail, Rust is drawing a +[difference between alpha and beta](http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html) +connected with our +[stability system](http://blog.rust-lang.org/2014/10/30/Stability.html). +In alpha releases, it's possible to opt-in to unstable features, but +after beta, this will be possible only when using nightly builds. The +beta release will mark the point when a substantial portion of the +community can move off of nightlies. + +As mentioned above, we have landed all of the major API revisions +needed for the 1.0 release, including path and IO reform. However, +some of these revisions landed relatively late in the cycle, and as a +community we don't have enough experience with the revised APIs to +declare them stable yet. Note that the API changes are, with a +couple exceptions, very conservative: they generally move us in the +direction of existing, successful libraries. + +By producing 1.0-alpha2, we leave open a longer window for tweaks to +these APIs before declaring them stable. That window will close around +March 9. + +### Is there risk of slippage by not moving to beta now? + +It seems unlikely. Essentially all of the language and library +features needed for 1.0 have already landed, meaning that we will have +*12 weeks* of time to polish between alpha2 and 1.0 final. + +## What will happen before 1.0? + +All features that are required for shipping 1.0 have now landed. What +remains is polish, performance improvements, bugfixing, documentation +-- and gaining enough confidence in recently revised APIs to mark them +`#[stable]`. + +The alpha2 release will officially deprecate (but leave available) the +old path and IO APIs. The new APIs are scheduled to be stabilized +by March 9. **Please try out these new APIs and help uncover +problems!** + +After the March 9 deadline, it should be possible for substantial +crates to work with "stable Rust", i.e. without any use of +`#[feature]`. Between then and the beta release, we hope to work +directly with authors of crates.io packages to help move code to +stable Rust, and to uncover any gaps in stabilization. + +By beta, we hope that a substantial part of the ecosystem will be off +of nightlies and on to stable releases. Getting there will require a +community-wide push toward stabilization, which we're coordinating via +[discuss](http://users.rust-lang.org/t/using-unstable-apis-tell-us-about-it/157/26) +-- if you haven't, please drop by and tell us the key unstable APIs +you're using. From 5991d72ffe253f5950238a019f3f4d3dfcb7b993 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 13 Feb 2015 11:35:52 -0800 Subject: [PATCH 46/74] Fix typos --- _posts/2015-02-13-Final-1.0-timeline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2015-02-13-Final-1.0-timeline.md b/_posts/2015-02-13-Final-1.0-timeline.md index 70cbaba12..b7341d99b 100644 --- a/_posts/2015-02-13-Final-1.0-timeline.md +++ b/_posts/2015-02-13-Final-1.0-timeline.md @@ -61,7 +61,7 @@ Other highlights are as follows: [thoroughly revised](https://github.com/rust-lang/rfcs/blob/master/text/0517-io-os-reform.md) to improve robustness and cross-platform behavior, and to eschew ambitious high-level abstractions over the system. While almost all - of the APIs are effected by this change, the changes move toward a + of the APIs are affected by this change, the changes move toward a much more conservative and consistent design. * **Deref coercions**: A From 404f85b1d4d3496b7b0e72b587366997c42495b8 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 13 Feb 2015 11:39:02 -0800 Subject: [PATCH 47/74] Fix redundancy --- _posts/2015-02-13-Final-1.0-timeline.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/2015-02-13-Final-1.0-timeline.md b/_posts/2015-02-13-Final-1.0-timeline.md index b7341d99b..c7db38c59 100644 --- a/_posts/2015-02-13-Final-1.0-timeline.md +++ b/_posts/2015-02-13-Final-1.0-timeline.md @@ -27,8 +27,8 @@ second alpha release and only a single beta release. The main reason for calling the next release alpha2 rather than beta1 is that new path and IO APIs have only recently landed, and we would -like more time to collect feedback before marking the new path and IO -APIs stable. More details are below. +like more time to collect feedback before marking them stable. More +details are below. ## What's shipping in alpha2? From 1565d2c25e3adb3c182d6e85988a8d0436660675 Mon Sep 17 00:00:00 2001 From: Steve Klabnik Date: Fri, 20 Feb 2015 14:57:43 -0500 Subject: [PATCH 48/74] Rust 1.0-alpha2 --- _posts/2015-02-20-Rust-1.0-alpha2.md | 244 +++++++++++++++++++++++++++ 1 file changed, 244 insertions(+) create mode 100644 _posts/2015-02-20-Rust-1.0-alpha2.md diff --git a/_posts/2015-02-20-Rust-1.0-alpha2.md b/_posts/2015-02-20-Rust-1.0-alpha2.md new file mode 100644 index 000000000..28bc33490 --- /dev/null +++ b/_posts/2015-02-20-Rust-1.0-alpha2.md @@ -0,0 +1,244 @@ +--- +layout: post +title: "Announcing Rust 1.0-alpha2" +author: Steve Klabnik +description: "Rust 1.0-alpha2 has been released." +--- + +Today, we are happy to announce the release of Rust 1.0.0.alpha.2! Rust is a +systems programming language perusing the trifecta: safe, fast, and concurrent. + +In accordance with our [status report](/2015/02/13/Final-1.0-timeline.html) +last week, this is a second alpha release, rather than a first beta release. +The beta release will be six weeks from today, with the final coming six weeks +after that. + +We’ve managed to land almost all of the features previously expected for this +cycle. **The big headline here is that all major API revisions are finished**: +path and IO reform have landed. At this point, all modules shipping for 1.0 are +in what we expect to be their final form, modulo minor tweaks during the alpha2 +cycle. See the [previous post](/2015/02/13/Final-1.0-timeline.html) for more +details. + +This coming release cycle is crucial to Rust, as this will be the last cycle +that we recommend nightly builds for most users. Part of the way through the +cycle, around March 9th, we expect to have all major functionality we expect in +1.0 marked as stable; we will fill in stability gaps between then and beta on +March 31st. The beta release will fully introduce the "stable channel", which +will not allow use of unstable features but will guarantee +backwards-compatibility (after 1.0). Unstable features will only be available +in nightly. + +For more detail, please see the [Release +notes](https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-100-alpha2-february-2015). + +Thank you to all 207 contributors for this release: + +* `Aaron Turon ` +* `Adam Roben ` +* `Adolfo Ochagavía ` +* `Ahmed Charles ` +* `Aidan Hobson Sayers ` +* `Akos Kiss ` +* `Alexander Bliskovsky ` +* `Alexander Korolkov ` +* `Alexander Light ` +* `Alex Crichton ` +* `Alexis ` +* `Alfie John ` +* `Alfie John ` +* `Andrea Canciani ` +* `Andrew Barchuk ` +* `Andrew Paseltiner ` +* `Ariel Ben-Yehuda ` +* `Ariel Ben-Yehuda ` +* `Armin Preiml ` +* `Artem ` +* `Barosl Lee ` +* `Benjamin Peterson ` +* `Ben S ` +* `Björn Steinbrink ` +* `blackbeam ` +* `bombless ` +* `Brian Anderson ` +* `Brian Leibig ` +* `caipre ` +* `Cam Jackson ` +* `Carl Lerche ` +* `Carol Nichols ` +* `Carter Hinsley ` +* `CarVac ` +* `Caspar Krieger ` +* `Chase Southwood ` +* `Chris Morgan ` +* `Chris Thorn ` +* `Chris Wong ` +* `Clifford Caoile ` +* `Corey Farwell ` +* `Corey Richardson ` +* `Daniel Griffen ` +* `Daniel Grunwald ` +* `Daniel Raloff ` +* `Daniil Smirnov ` +* `Dan Yang ` +* `David Creswick ` +* `Diggory Blake ` +* `Dominik Inführ ` +* `Duane Edwards ` +* `Duncan Regan ` +* `Dzmitry Malyshau ` +* `Earl St Sauver ` +* `Eduard Burtescu ` +* `Edward Wang ` +* `Elantsev Serj ` +* `emanueLczirai ` +* `Erick Rivas ` +* `Erick Tryzelaar ` +* `Eunji Jeong ` +* `Felix S. Klock II ` +* `Fenhl ` +* `Filip SzczepaÅ„ski ` +* `Flavio Percoco ` +* `Florian Hahn ` +* `Garrett Heel ` +* `Geoffrey Thomas ` +* `Greg Chapple ` +* `Guillaume Gomez ` +* `GuillaumeGomez ` +* `Guillaume Pinot ` +* `Henrik Schopmans ` +* `Hugo van der Wijst ` +* `Huon Wilson ` +* `Ignacio Corderi ` +* `Ingo Blechschmidt ` +* `Jake Goulding ` +* `James Miller ` +* `Jared Roesch ` +* `Jason Fager ` +* `jatinn ` +* `Jay True ` +* `Jeff Belgum ` +* `John Hodge ` +* `John KaÌŠre Alsaker ` +* `John KÃ¥re Alsaker ` +* `Jonathan Reem ` +* `JONNALAGADDA Srinivas ` +* `Jorge Aparicio ` +* `Jorge Israel Peña ` +* `Jormundir ` +* `Joseph Crail ` +* `JP Sugarbroad ` +* `Julian Orth ` +* `Junseok Lee ` +* `Kang Seonghoon ` +* `Keegan McAllister ` +* `Keegan McAllister ` +* `Ken Tossell ` +* `KernelJ ` +* `Kevin Ballard ` +* `Kevin Butler ` +* `Kevin Yap ` +* `Kim Røen ` +* `klutzy ` +* `Kostas Karachalios ` +* `kud1ing ` +* `Lai Jiangshan ` +* `Lauri Lehmijoki ` +* `Leo Testard ` +* `Liigo Zhuang ` +* `Logan Chien ` +* `Loïc Damien ` +* `Luca Bruno ` +* `Luke Francl ` +* `Luke Steensen ` +* `madmalik ` +* `Manish Goregaokar ` +* `Markus Siemens ` +* `Marvin Löbel ` +* `Matt Roche ` +* `Mátyás Mustoha ` +* `mdinger ` +* `Michael Budde ` +* `Michael Neumann ` +* `Michael Pankov ` +* `Michael Sproul ` +* `Michael Woerister ` +* `Mike English ` +* `Mikhail Zabaluev ` +* `Ms2ger ` +* `NAKASHIMA, Makoto ` +* `nathan dotz ` +* `Nathaniel Theis ` +* `Nathan Stoddard ` +* `Nelson Chen ` +* `Nick Cameron ` +* `Nick Howell ` +* `Nick Sarten ` +* `Niko Matsakis ` +* `NODA, Kai ` +* `Oliver 'ker' Schneider ` +* `Oliver Schneider ` +* `Orpheus Lummis ` +* `P1start ` +* `Pascal Hertleif ` +* `Paul Collier ` +* `Paul Crowley ` +* `Peter Atashian ` +* `Peter Schuller ` +* `Pierre Baillet ` +* `Piotr Czarnecki ` +* `posixphreak ` +* `Potpourri ` +* `Pyfisch ` +* `Raul Gutierrez S ` +* `Renato Alves ` +* `Renato Zannon ` +* `Richo Healey ` +* `Robin Stocker ` +* `Rohit Joshi ` +* `Ryan Levick ` +* `Sean Collins ` +* `Sean Gillespie ` +* `Sean Patrick Santos ` +* `Sean T Allen ` +* `Sebastian Gesemann ` +* `Sebastian Rasmussen ` +* `Sébastien Marie ` +* `Seo Sanghyeon ` +* `Seth Faxon ` +* `Simonas Kazlauskas ` +* `Stepan Koltsov ` +* `Steve Klabnik ` +* `Steven Allen ` +* `Steven Crockett ` +* `Steven Fackler ` +* `Strahinja Val Markovic ` +* `Thiago Carvalho ` +* `Tim Brooks ` +* `Tim Cuthbertson ` +* `Tim Dumol ` +* `Tim Parenti ` +* `Tobias Bucher ` +* `Toby Scrace ` +* `Tom Chittenden ` +* `Tom Jakubowski ` +* `Toni Cárdenas ` +* `Travis Watkins ` +* `Tristan Storch ` +* `Tshepang Lekhonkhobe ` +* `Tyler Thrailkill ` +* `Ulrik Sverdrup ` +* `Vadim Chugunov ` +* `Vadim Petrochenkov ` +* `Valerii Hiora ` +* `Victory ` +* `visualfc ` +* `Vojtech Kral ` +* `Volker Mische ` +* `Wangshan Lu ` +* `we ` +* `Willson Mock ` +* `Will ` +* `wonyong kim ` +* `York Xiang ` + From a8c58a5000966f4a83363d37a822154bf630fb8e Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Fri, 20 Feb 2015 12:05:57 -0800 Subject: [PATCH 49/74] Fix names --- _posts/2015-02-20-Rust-1.0-alpha2.md | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/_posts/2015-02-20-Rust-1.0-alpha2.md b/_posts/2015-02-20-Rust-1.0-alpha2.md index 28bc33490..a7fdf4496 100644 --- a/_posts/2015-02-20-Rust-1.0-alpha2.md +++ b/_posts/2015-02-20-Rust-1.0-alpha2.md @@ -36,7 +36,7 @@ Thank you to all 207 contributors for this release: * `Aaron Turon ` * `Adam Roben ` -* `Adolfo Ochagavía ` +* `Adolfo Ochagavía ` * `Ahmed Charles ` * `Aidan Hobson Sayers ` * `Akos Kiss ` @@ -57,7 +57,7 @@ Thank you to all 207 contributors for this release: * `Barosl Lee ` * `Benjamin Peterson ` * `Ben S ` -* `Björn Steinbrink ` +* `Björn Steinbrink ` * `blackbeam ` * `bombless ` * `Brian Anderson ` @@ -83,7 +83,7 @@ Thank you to all 207 contributors for this release: * `Dan Yang ` * `David Creswick ` * `Diggory Blake ` -* `Dominik Inführ ` +* `Dominik Inführ ` * `Duane Edwards ` * `Duncan Regan ` * `Dzmitry Malyshau ` @@ -97,7 +97,7 @@ Thank you to all 207 contributors for this release: * `Eunji Jeong ` * `Felix S. Klock II ` * `Fenhl ` -* `Filip SzczepaÅ„ski ` +* `Filip Szczepański ` * `Flavio Percoco ` * `Florian Hahn ` * `Garrett Heel ` @@ -119,12 +119,12 @@ Thank you to all 207 contributors for this release: * `Jay True ` * `Jeff Belgum ` * `John Hodge ` -* `John KaÌŠre Alsaker ` -* `John KÃ¥re Alsaker ` +* `John Kåre Alsaker ` +* `John Kåre Alsaker ` * `Jonathan Reem ` * `JONNALAGADDA Srinivas ` * `Jorge Aparicio ` -* `Jorge Israel Peña ` +* `Jorge Israel Peña ` * `Jormundir ` * `Joseph Crail ` * `JP Sugarbroad ` @@ -138,7 +138,7 @@ Thank you to all 207 contributors for this release: * `Kevin Ballard ` * `Kevin Butler ` * `Kevin Yap ` -* `Kim Røen ` +* `Kim Røen ` * `klutzy ` * `Kostas Karachalios ` * `kud1ing ` @@ -147,16 +147,16 @@ Thank you to all 207 contributors for this release: * `Leo Testard ` * `Liigo Zhuang ` * `Logan Chien ` -* `Loïc Damien ` +* `Loïc Damien ` * `Luca Bruno ` * `Luke Francl ` * `Luke Steensen ` * `madmalik ` * `Manish Goregaokar ` * `Markus Siemens ` -* `Marvin Löbel ` +* `Marvin Löbel ` * `Matt Roche ` -* `Mátyás Mustoha ` +* `Mátyás Mustoha ` * `mdinger ` * `Michael Budde ` * `Michael Neumann ` @@ -203,7 +203,7 @@ Thank you to all 207 contributors for this release: * `Sean T Allen ` * `Sebastian Gesemann ` * `Sebastian Rasmussen ` -* `Sébastien Marie ` +* `Sébastien Marie ` * `Seo Sanghyeon ` * `Seth Faxon ` * `Simonas Kazlauskas ` @@ -222,7 +222,7 @@ Thank you to all 207 contributors for this release: * `Toby Scrace ` * `Tom Chittenden ` * `Tom Jakubowski ` -* `Toni Cárdenas ` +* `Toni Cárdenas ` * `Travis Watkins ` * `Tristan Storch ` * `Tshepang Lekhonkhobe ` @@ -241,4 +241,3 @@ Thank you to all 207 contributors for this release: * `Will ` * `wonyong kim ` * `York Xiang ` - From 27f2520e58373cea6e4b3ac7130c9d45b35a63da Mon Sep 17 00:00:00 2001 From: Steve Klabnik Date: Fri, 20 Feb 2015 15:13:34 -0500 Subject: [PATCH 50/74] versioning is hard, consistent versioning is harder --- _posts/2015-02-20-Rust-1.0-alpha2.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/2015-02-20-Rust-1.0-alpha2.md b/_posts/2015-02-20-Rust-1.0-alpha2.md index a7fdf4496..51b5be9d2 100644 --- a/_posts/2015-02-20-Rust-1.0-alpha2.md +++ b/_posts/2015-02-20-Rust-1.0-alpha2.md @@ -1,8 +1,8 @@ --- layout: post -title: "Announcing Rust 1.0-alpha2" +title: "Announcing Rust 1.0.0.alpha.2" author: Steve Klabnik -description: "Rust 1.0-alpha2 has been released." +description: "Rust 1.0.0.alpha.2 has been released." --- Today, we are happy to announce the release of Rust 1.0.0.alpha.2! Rust is a From c755e9d2dc1f222f62213050af62b7857cbce1af Mon Sep 17 00:00:00 2001 From: elliottcf Date: Fri, 20 Feb 2015 14:55:47 -0600 Subject: [PATCH 51/74] Fixed word choice Replaced perusing or pursuing --- _posts/2015-02-20-Rust-1.0-alpha2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2015-02-20-Rust-1.0-alpha2.md b/_posts/2015-02-20-Rust-1.0-alpha2.md index 51b5be9d2..32b7f59e0 100644 --- a/_posts/2015-02-20-Rust-1.0-alpha2.md +++ b/_posts/2015-02-20-Rust-1.0-alpha2.md @@ -6,7 +6,7 @@ description: "Rust 1.0.0.alpha.2 has been released." --- Today, we are happy to announce the release of Rust 1.0.0.alpha.2! Rust is a -systems programming language perusing the trifecta: safe, fast, and concurrent. +systems programming language pursuing the trifecta: safe, fast, and concurrent. In accordance with our [status report](/2015/02/13/Final-1.0-timeline.html) last week, this is a second alpha release, rather than a first beta release. From 84fa18acd40a50c6b0a39790e9de2a7e491e925a Mon Sep 17 00:00:00 2001 From: Steve Klabnik Date: Fri, 20 Feb 2015 16:08:40 -0500 Subject: [PATCH 52/74] Fix typo Thanks parley https://news.ycombinator.com/item?id=9082849 --- _posts/2015-02-20-Rust-1.0-alpha2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2015-02-20-Rust-1.0-alpha2.md b/_posts/2015-02-20-Rust-1.0-alpha2.md index 51b5be9d2..32b7f59e0 100644 --- a/_posts/2015-02-20-Rust-1.0-alpha2.md +++ b/_posts/2015-02-20-Rust-1.0-alpha2.md @@ -6,7 +6,7 @@ description: "Rust 1.0.0.alpha.2 has been released." --- Today, we are happy to announce the release of Rust 1.0.0.alpha.2! Rust is a -systems programming language perusing the trifecta: safe, fast, and concurrent. +systems programming language pursuing the trifecta: safe, fast, and concurrent. In accordance with our [status report](/2015/02/13/Final-1.0-timeline.html) last week, this is a second alpha release, rather than a first beta release. From e2cb108333687274fc1bd2f2d8f781d8bda0f8d9 Mon Sep 17 00:00:00 2001 From: sjef Date: Fri, 20 Feb 2015 23:20:17 +0100 Subject: [PATCH 53/74] Remove duplicate name in contributor list --- _posts/2015-02-20-Rust-1.0-alpha2.md | 1 - 1 file changed, 1 deletion(-) diff --git a/_posts/2015-02-20-Rust-1.0-alpha2.md b/_posts/2015-02-20-Rust-1.0-alpha2.md index 32b7f59e0..eff3c945a 100644 --- a/_posts/2015-02-20-Rust-1.0-alpha2.md +++ b/_posts/2015-02-20-Rust-1.0-alpha2.md @@ -119,7 +119,6 @@ Thank you to all 207 contributors for this release: * `Jay True ` * `Jeff Belgum ` * `John Hodge ` -* `John Kåre Alsaker ` * `John Kåre Alsaker ` * `Jonathan Reem ` * `JONNALAGADDA Srinivas ` From e0e6b44ff98707715e9a1699868cc27f68c7e588 Mon Sep 17 00:00:00 2001 From: Ingve Date: Fri, 20 Feb 2015 23:48:56 +0100 Subject: [PATCH 54/74] Remove duplicate name in contributor list Surely it is the same person. --- _posts/2015-02-20-Rust-1.0-alpha2.md | 1 - 1 file changed, 1 deletion(-) diff --git a/_posts/2015-02-20-Rust-1.0-alpha2.md b/_posts/2015-02-20-Rust-1.0-alpha2.md index eff3c945a..b4b748969 100644 --- a/_posts/2015-02-20-Rust-1.0-alpha2.md +++ b/_posts/2015-02-20-Rust-1.0-alpha2.md @@ -104,7 +104,6 @@ Thank you to all 207 contributors for this release: * `Geoffrey Thomas ` * `Greg Chapple ` * `Guillaume Gomez ` -* `GuillaumeGomez ` * `Guillaume Pinot ` * `Henrik Schopmans ` * `Hugo van der Wijst ` From 6f8a6b3a40c93a785f52be422be31585c19b7842 Mon Sep 17 00:00:00 2001 From: Ingve Date: Fri, 20 Feb 2015 23:52:49 +0100 Subject: [PATCH 55/74] Correct the amount of contributors --- _posts/2015-02-20-Rust-1.0-alpha2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2015-02-20-Rust-1.0-alpha2.md b/_posts/2015-02-20-Rust-1.0-alpha2.md index b4b748969..75f727b3e 100644 --- a/_posts/2015-02-20-Rust-1.0-alpha2.md +++ b/_posts/2015-02-20-Rust-1.0-alpha2.md @@ -32,7 +32,7 @@ in nightly. For more detail, please see the [Release notes](https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-100-alpha2-february-2015). -Thank you to all 207 contributors for this release: +Thank you to all 205 contributors for this release: * `Aaron Turon ` * `Adam Roben ` From 6a5ee2c775957f81439512e60480e8ddf5ae7ff7 Mon Sep 17 00:00:00 2001 From: York Xiang Date: Sat, 21 Feb 2015 06:56:15 +0800 Subject: [PATCH 56/74] Remove duplicate contributor --- _posts/2015-01-09-Rust-1.0-alpha.md | 1 - _posts/2015-02-20-Rust-1.0-alpha2.md | 3 +-- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/_posts/2015-01-09-Rust-1.0-alpha.md b/_posts/2015-01-09-Rust-1.0-alpha.md index d89b7db91..657fec2d1 100644 --- a/_posts/2015-01-09-Rust-1.0-alpha.md +++ b/_posts/2015-01-09-Rust-1.0-alpha.md @@ -146,7 +146,6 @@ This alpha release could not have happened without the help of Rust's enthusiast * `Bheesham Persaud ` * `Björn Steinbrink ` * `bluss ` -* `bombless ` * `Boris Egorov ` * `bors ` * `Brandon Sanderson ` diff --git a/_posts/2015-02-20-Rust-1.0-alpha2.md b/_posts/2015-02-20-Rust-1.0-alpha2.md index eff3c945a..1e8d217f8 100644 --- a/_posts/2015-02-20-Rust-1.0-alpha2.md +++ b/_posts/2015-02-20-Rust-1.0-alpha2.md @@ -32,7 +32,7 @@ in nightly. For more detail, please see the [Release notes](https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-100-alpha2-february-2015). -Thank you to all 207 contributors for this release: +Thank you to all 205 contributors for this release: * `Aaron Turon ` * `Adam Roben ` @@ -59,7 +59,6 @@ Thank you to all 207 contributors for this release: * `Ben S ` * `Björn Steinbrink ` * `blackbeam ` -* `bombless ` * `Brian Anderson ` * `Brian Leibig ` * `caipre ` From 0548c8e6459493e45dcc189e5d7458a0b0c10fa5 Mon Sep 17 00:00:00 2001 From: York Xiang Date: Sat, 21 Feb 2015 09:10:22 +0800 Subject: [PATCH 57/74] Correct amount of contributors --- _posts/2015-02-20-Rust-1.0-alpha2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2015-02-20-Rust-1.0-alpha2.md b/_posts/2015-02-20-Rust-1.0-alpha2.md index 3c578919b..b0e957681 100644 --- a/_posts/2015-02-20-Rust-1.0-alpha2.md +++ b/_posts/2015-02-20-Rust-1.0-alpha2.md @@ -32,7 +32,7 @@ in nightly. For more detail, please see the [Release notes](https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-100-alpha2-february-2015). -Thank you to all 205 contributors for this release: +Thank you to all 204 contributors for this release: * `Aaron Turon ` * `Adam Roben ` From 2adc5f6dcbb77b1115f15e164e4a6f146e69bdec Mon Sep 17 00:00:00 2001 From: Matt Brubeck Date: Tue, 31 Mar 2015 15:44:37 -0700 Subject: [PATCH 58/74] Correct the date for 1.0-beta --- _posts/2015-02-13-Final-1.0-timeline.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/_posts/2015-02-13-Final-1.0-timeline.md b/_posts/2015-02-13-Final-1.0-timeline.md index c7db38c59..2eb65f074 100644 --- a/_posts/2015-02-13-Final-1.0-timeline.md +++ b/_posts/2015-02-13-Final-1.0-timeline.md @@ -17,7 +17,7 @@ committing to a precise release schedule for 1.0: * Rust 1.0-alpha2 -- Feb 20 * All 1.0 modules stable on nightly -- around Mar 9 -* Rust 1.0-beta -- Mar 31 +* Rust 1.0-beta -- Apr 3 * Rust 1.0 -- May 15 This schedule differs from the @@ -30,6 +30,10 @@ is that new path and IO APIs have only recently landed, and we would like more time to collect feedback before marking them stable. More details are below. +**Update:** An earlier version of this post listed Mar 31 as the 1.0-beta +release date, due to a miscalculation. The correct date is Apr 3, exactly six +weeks after alpha2 and six weeks before 1.0. + ## What's shipping in alpha2? We've managed to land almost all of the features From 3691d4cb325f7c1f29073bf1d309a8e817a0c904 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 3 Apr 2015 13:02:48 -0400 Subject: [PATCH 59/74] Add beta post --- _posts/2015-04-03-Rust-1.0-beta.md | 244 +++++++++++++++++++++++++++++ 1 file changed, 244 insertions(+) create mode 100644 _posts/2015-04-03-Rust-1.0-beta.md diff --git a/_posts/2015-04-03-Rust-1.0-beta.md b/_posts/2015-04-03-Rust-1.0-beta.md new file mode 100644 index 000000000..f8ed6c51b --- /dev/null +++ b/_posts/2015-04-03-Rust-1.0-beta.md @@ -0,0 +1,244 @@ +--- +layout: post +title: "Announcing Rust 1.0 Beta" +author: The Rust Core Team +--- + +Today we are excited to announce the [release of Rust 1.0 beta][ru]! +The beta release marks a very significant "state transition" in the +move towards 1.0. In particular, with the beta release, **all +libraries and language features that are planned to be stable for 1.0 +have been marked as stable**. As such, the beta release represents an +accurate preview of what Rust 1.0 will include. + +The Beta release also marks a turning point in our +[approach to stability][as]. During the alpha cycle, the use of +unstable APIs and language features was permitted, but triggered a +warning. As of the Beta release, the use of unstable APIs will become +an error (unless you are using Nightly builds or building from +source). + +The Rust ecosystem continues to grow. The +[crates.io](https://crates.io/) repository just passed 1 million +downloads and has over 1,700 crates available. Many of the top crates +in [crates.io](https://crates.io/) can now be built using only stable +Rust, and efforts to port the remainder are underway. Therefore, we +are now recommending that new users start with the Beta release, +rather than the Nightly builds, and the [rustup script][ru] will be +modified to install Beta by default. (However, it is easy to switch to +the Nightly build if some of your dependencies aren't updated yet. See +the [install page][ru] for details.) + +[ru]: http://www.rust-lang.org/install.html +[as]: http://blog.rust-lang.org/2014/10/30/Stability.html + +### What happens during the beta cycle? + +**The final Rust 1.0 release is scheduled for May 15th -- exactly six +weeks from now.** In the interim, we expect to put most of our effort +into fixing bugs, improving documentation and error messages, and +otherwise improving the end-user experience. We don't plan on making +functional changes to stable content, though naturally we may make +minor corrections or additions to the library APIs if shortcomings or +problems are uncovered (but the bar for such changes is relatively +high). + +While we don't expect to add any new features (or major new APIs) for +the 1.0 release, that doesn't mean we're going to stop working on them +altogether. In fact, quite the opposite! Per [the train model][tm], +the plan is to continue development on new features on the master +branch, in parallel with the beta. And of course, we'll be issuing the +beta for 1.1 release at the same time as we issue the final 1.0 +release, so you shouldn't have to wait long to start putting that work +to use. + +To help ensure that we don't accidentally introduce breakage as we add +new features, we've also been working on an exciting new CI +infrastructure to allow us to monitor which packages are building with +the Nightly builds and detect regressions across the entire Rust +ecosystem, not just our own test base. This infrastructure is still in +the development phase, but you can see a [sample report][sr] here. + +[tm]: http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html +[sr]: https://gist.github.com/brson/a30a77836fbec057cbee + +### A community achievement + +As always, this Rust release is the achievement of the fantastic Rust +community at large. Thanks to everyone who has participated in the RFC +process, and a particular thank you to the 172 contributors for this +release: + +- `Aaron Turon ` +- `Aaron Weiss ` +- `Adam Jacob ` +- `Adenilson Cavalcanti ` +- `Adolfo Ochagavía ` +- `Ahmed Charles ` +- `Alan Cutter ` +- `Alex Crichton ` +- `Alexander Bliskovsky ` +- `Alexander Campbell ` +- `Alexander Chernyakhovsky ` +- `Alexis ` +- `Alexis Beingessner ` +- `Amol Mundayoor ` +- `Anders Kaseorg ` +- `Andrew Hobden ` +- `Andrew Paseltiner ` +- `Angus Lees ` +- `Barosl Lee ` +- `Björn Steinbrink ` +- `Brian Anderson ` +- `Brian Brooks ` +- `Brian Leibig ` +- `Camille Roussel ` +- `Camille TJHOA ` +- `Carol Nichols ` +- `Caspar Krieger ` +- `Ches Martin ` +- `Chloe <5paceToast@users.noreply.github.com>` +- `Chris Wong ` +- `Cody P Schafer ` +- `Corey Farwell ` +- `Corey Richardson ` +- `Dabo Ross ` +- `Dan Burkert ` +- `Dan Connolly ` +- `Dan W. <1danwade@gmail.com>` +- `Daniel Lobato García ` +- `Darin Morrison ` +- `Darrell Hamilton ` +- `Dave Huseby ` +- `David Creswick ` +- `David King ` +- `David Mally ` +- `Denis Defreyne ` +- `Drew Crawford ` +- `Dzmitry Malyshau ` +- `Eduard Bopp ` +- `Eduard Burtescu ` +- `Eduardo Bautista ` +- `Edward Wang ` +- `Emeliov Dmitrii ` +- `Eric Platon ` +- `Erick Tryzelaar ` +- `Eunji Jeong ` +- `Falco Hirschenberger ` +- `Felix S. Klock II ` +- `Fenhl ` +- `Flavio Percoco ` +- `Florian Hahn ` +- `Florian Hartwig ` +- `Florian Zeitz ` +- `FuGangqiang ` +- `Gary M. Josack ` +- `Germano Gabbianelli ` +- `GlacJAY ` +- `Gleb Kozyrev ` +- `Guillaume Gomez ` +- `GuillaumeGomez ` +- `Huachao Huang ` +- `Huon Wilson ` +- `Ivan Petkov ` +- `Ivan Radanov Ivanov ` +- `JP-Ellis ` +- `Jake Goulding ` +- `Jakub Bukaj ` +- `James Miller ` +- `Jessy Diamond Exum ` +- `Jihyun Yu ` +- `Johannes Oertel ` +- `John Hodge ` +- `John Zhang ` +- `Jonathan Reem ` +- `Jordan Woehr ` +- `Jorge Aparicio ` +- `Joseph Crail ` +- `Julian Orth ` +- `Julian Viereck ` +- `Junseok Lee ` +- `Kang Seonghoon ` +- `Keegan McAllister ` +- `Kevin Ballard ` +- `Kevin Butler ` +- `Kevin Yap ` +- `Lai Jiangshan ` +- `Leonids Maslovs ` +- `Liam Monahan ` +- `Liigo Zhuang ` +- `Manish Goregaokar ` +- `Markus Siemens ` +- `Markus Unterwaditzer ` +- `Marvin Löbel ` +- `Matt Brubeck ` +- `Matt Cox ` +- `Michael Woerister ` +- `Michał Krasnoborski ` +- `Mihnea Dobrescu-Balaur ` +- `Mikhail Zabaluev ` +- `Ms2ger ` +- `Murarth ` +- `Nicholas ` +- `Nicholas Bishop ` +- `Nicholas Mazzuca ` +- `Nick Cameron ` +- `Niko Matsakis ` +- `Oliver Schneider ` +- `Or Neeman ` +- `Pascal Hertleif ` +- `Patrick Walton ` +- `Paul ADENOT ` +- `Paul Osborne ` +- `Peter Elmers ` +- `Phil Dawes ` +- `Philip Munksgaard ` +- `Piotr Czarnecki ` +- `Pyry Kontio ` +- `Raphael Nestler ` +- `Ricardo Martins ` +- `Richard Diamond ` +- `Richo Healey ` +- `Ruud van Asseldonk ` +- `Ryan Prichard ` +- `Sae-bom Kim ` +- `Scott Olson ` +- `Sean McArthur ` +- `Seo Sanghyeon ` +- `Simonas Kazlauskas ` +- `Simonas Kazlauskas ` +- `Stepan Koltsov ` +- `Stepan Koltsov ` +- `Steve Klabnik ` +- `Steven Crockett ` +- `Steven Fackler ` +- `Sébastien Marie ` +- `Tamir Duberstein ` +- `Tero Hänninen ` +- `Tiago Nobrega ` +- `Tobias Bucher ` +- `Tom Jakubowski ` +- `Trent Nadeau ` +- `Tshepang Lekhonkhobe ` +- `Ulrik Sverdrup ` +- `Vadim Chugunov ` +- `Vadim Petrochenkov ` +- `Valerii Hiora ` +- `Vladimir Pouzanov ` +- `Vojtech Kral ` +- `Wangshan Lu ` +- `Wesley Wiser ` +- `York Xiang ` +- `awlnx ` +- `bcoopers ` +- `bombless ` +- `defuz ` +- `inrustwetrust ` +- `kgv ` +- `kjpgit ` +- `lummax ` +- `mdinger ` +- `nwin ` +- `ray glover ` +- `Łukasz Niemier ` + From 873dfc1f9e2899e58f05ce5601867eb0187b2fca Mon Sep 17 00:00:00 2001 From: Steve Klabnik Date: Fri, 3 Apr 2015 14:06:30 -0400 Subject: [PATCH 60/74] uhhh release notes --- _posts/2015-04-03-Rust-1.0-beta.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/_posts/2015-04-03-Rust-1.0-beta.md b/_posts/2015-04-03-Rust-1.0-beta.md index f8ed6c51b..a313e8694 100644 --- a/_posts/2015-04-03-Rust-1.0-beta.md +++ b/_posts/2015-04-03-Rust-1.0-beta.md @@ -11,6 +11,10 @@ libraries and language features that are planned to be stable for 1.0 have been marked as stable**. As such, the beta release represents an accurate preview of what Rust 1.0 will include. +To see what has changed since 1.0-alpha2, please see the [release notes][rn]. + +[rn]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-100-beta-april-2015 + The Beta release also marks a turning point in our [approach to stability][as]. During the alpha cycle, the use of unstable APIs and language features was permitted, but triggered a From ff8b73c5a3d29e9100b97a45691de2fcc1b93efe Mon Sep 17 00:00:00 2001 From: Steve Klabnik Date: Fri, 3 Apr 2015 14:48:17 -0400 Subject: [PATCH 61/74] remove incorrect link Fixes #36 --- _posts/2014-10-30-Stability.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/_posts/2014-10-30-Stability.md b/_posts/2014-10-30-Stability.md index 250b76fc2..cfc43a9ce 100644 --- a/_posts/2014-10-30-Stability.md +++ b/_posts/2014-10-30-Stability.md @@ -57,12 +57,9 @@ stable -- with regular, frequent promotions from one channel to the next. New features and new APIs will be flagged as unstable via feature gates -and -[stability attributes](http://doc.rust-lang.org/reference.html#stability), -respectively. -Unstable features and standard library APIs will only be available on -the nightly branch, and only if you explicitly "opt in" to the -instability. +and stability attributes respectively. Unstable features and standard +library APIs will only be available on the nightly branch, and only if you +explicitly "opt in" to the instability. The beta and stable releases, on the other hand, will only include features and APIs deemed *stable*, which represents a commitment to From c030c4c8d80d3ca8e2e6720c2fc3c75b1fc73399 Mon Sep 17 00:00:00 2001 From: Huon Wilson Date: Sun, 5 Apr 2015 23:34:51 +1000 Subject: [PATCH 62/74] Sort contributor list unicode-aware & folding case. --- _posts/2015-04-03-Rust-1.0-beta.md | 33 +++++++++++++++--------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/_posts/2015-04-03-Rust-1.0-beta.md b/_posts/2015-04-03-Rust-1.0-beta.md index a313e8694..867681c87 100644 --- a/_posts/2015-04-03-Rust-1.0-beta.md +++ b/_posts/2015-04-03-Rust-1.0-beta.md @@ -91,8 +91,11 @@ release: - `Andrew Hobden ` - `Andrew Paseltiner ` - `Angus Lees ` +- `awlnx ` - `Barosl Lee ` +- `bcoopers ` - `Björn Steinbrink ` +- `bombless ` - `Brian Anderson ` - `Brian Brooks ` - `Brian Leibig ` @@ -117,6 +120,7 @@ release: - `David Creswick ` - `David King ` - `David Mally ` +- `defuz ` - `Denis Defreyne ` - `Drew Crawford ` - `Dzmitry Malyshau ` @@ -144,9 +148,9 @@ release: - `GuillaumeGomez ` - `Huachao Huang ` - `Huon Wilson ` +- `inrustwetrust ` - `Ivan Petkov ` - `Ivan Radanov Ivanov ` -- `JP-Ellis ` - `Jake Goulding ` - `Jakub Bukaj ` - `James Miller ` @@ -159,6 +163,7 @@ release: - `Jordan Woehr ` - `Jorge Aparicio ` - `Joseph Crail ` +- `JP-Ellis ` - `Julian Orth ` - `Julian Viereck ` - `Junseok Lee ` @@ -167,27 +172,33 @@ release: - `Kevin Ballard ` - `Kevin Butler ` - `Kevin Yap ` +- `kgv ` +- `kjpgit ` - `Lai Jiangshan ` - `Leonids Maslovs ` - `Liam Monahan ` - `Liigo Zhuang ` +- `Łukasz Niemier ` +- `lummax ` - `Manish Goregaokar ` - `Markus Siemens ` - `Markus Unterwaditzer ` - `Marvin Löbel ` - `Matt Brubeck ` - `Matt Cox ` +- `mdinger ` - `Michael Woerister ` - `Michał Krasnoborski ` - `Mihnea Dobrescu-Balaur ` - `Mikhail Zabaluev ` - `Ms2ger ` - `Murarth ` -- `Nicholas ` - `Nicholas Bishop ` - `Nicholas Mazzuca ` +- `Nicholas ` - `Nick Cameron ` - `Niko Matsakis ` +- `nwin ` - `Oliver Schneider ` - `Or Neeman ` - `Pascal Hertleif ` @@ -200,6 +211,7 @@ release: - `Piotr Czarnecki ` - `Pyry Kontio ` - `Raphael Nestler ` +- `ray glover ` - `Ricardo Martins ` - `Richard Diamond ` - `Richo Healey ` @@ -208,15 +220,15 @@ release: - `Sae-bom Kim ` - `Scott Olson ` - `Sean McArthur ` +- `Sébastien Marie ` - `Seo Sanghyeon ` -- `Simonas Kazlauskas ` - `Simonas Kazlauskas ` +- `Simonas Kazlauskas ` - `Stepan Koltsov ` - `Stepan Koltsov ` - `Steve Klabnik ` - `Steven Crockett ` - `Steven Fackler ` -- `Sébastien Marie ` - `Tamir Duberstein ` - `Tero Hänninen ` - `Tiago Nobrega ` @@ -233,16 +245,3 @@ release: - `Wangshan Lu ` - `Wesley Wiser ` - `York Xiang ` -- `awlnx ` -- `bcoopers ` -- `bombless ` -- `defuz ` -- `inrustwetrust ` -- `kgv ` -- `kjpgit ` -- `lummax ` -- `mdinger ` -- `nwin ` -- `ray glover ` -- `Łukasz Niemier ` - From 411e7a690dd79defe40691e175c09d1043f3dbd9 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Thu, 9 Apr 2015 17:06:59 -0700 Subject: [PATCH 63/74] Add blog post: Fearless Concurrency with Rust --- _posts/2015-04-10-Fearless-Concurrency.md | 591 ++++++++++++++++++++++ 1 file changed, 591 insertions(+) create mode 100644 _posts/2015-04-10-Fearless-Concurrency.md diff --git a/_posts/2015-04-10-Fearless-Concurrency.md b/_posts/2015-04-10-Fearless-Concurrency.md new file mode 100644 index 000000000..cb8e5ef51 --- /dev/null +++ b/_posts/2015-04-10-Fearless-Concurrency.md @@ -0,0 +1,591 @@ +--- +layout: post +title: "Fearless Concurrency with Rust" +author: Aaron Turon +--- + +Rust solves an apparent contradiction: safe systems programming. Its +secret weapon is *ownership*, a concept ubiquitous in systems +programming that Rust's compiler statically checks for you. The +result: you can program without a garbage collector *and* without fear +of segfaults, because Rust will catch your mistakes. + +**The same tools that make Rust safe also help tackle concurrency +head-on.** After all, use-after-free bugs and synchronization bugs +both happen when code accesses data it shouldn't -- and as we'll +see, ownership is all about access control. + +Here's a taste of concurrency in Rust: + +* A [channel][mpsc] transfers ownership of the messages sent along it, + so you can send a pointer from one thread to another without fear of + the threads later racing for access through that pointer. + +* A [lock][mutex] knows what data it protects, and Rust guarantees + that the data can only be accessed when the lock is held. + +* Every data type knows whether it can safely be [sent][send] between + or [accessed][sync] by multiple threads, and Rust enforces this safe + usage; there are no data races. + +* You can even [share stack frames][scoped] between threads, and Rust + will statically ensure that the frames remain active while other + threads are using them. + +None of the above benefits require any special knowledge to be built +in to the compiler. Locks, channels, semaphores, atomic operations and +so on are all *libraries* that take advantage of Rust's existing +features to provide the static checking underlying these strong +guarantees. + +The goal of this post is to give you some idea of how that's done. + +### Background: ownership + +> We'll start with an overview of Rust's ownership and borrowing +systems. If you're already familiar with these, you can skip the two +"background" sections and jump straight into concurrency. If you want +a deeper introduction, I can't recommend +[Yehuda Katz's post](http://blog.skylight.io/rust-means-never-having-to-close-a-socket/) +highly enough. And +[the Rust book](http://doc.rust-lang.org/book/ownership.html) has all +the details. + +In Rust, every value has an "owning scope," and passing or returning a +value means transferring ownership ("moving" it) to a new +scope. Values that are still owned when a scope ends are automatically +destroyed at that point. + +Let's look at some simple examples. Suppose we create a vector and +push some elements onto it: + +```rust +fn make_vec() { + let mut vec = Vec::new(); // owned by make_vec's scope + vec.push(0); + vec.push(1); + // scope ends, `vec` is destroyed +} +``` + +The scope that creates a value also initially owns it. In this case, +the `make_vec` function's body (the part within `{` and `}`) is the +owning scope for `vec`. The owner can do anything it likes with `vec`, +including mutating it by pushing. At the end of the scope, `vec` is +still owned, so it is automatically deallocated. + +Things get more interesting if the vector is returned or passed around: + +```rust +fn make_vec() -> Vec { + let mut vec = Vec::new(); + vec.push(0); + vec.push(1); + vec // transfer ownership to the caller +} + +fn print_vec(vec: Vec) { + // the `vec` parameter is part of this scope, so it's owned by `print_vec` + + for i in vec.iter() { + println!("{}", i) + } + + // now, `vec` is deallocated +} + +fn use_vec() { + let vec = make_vec(); // take ownership of the vector + print_vec(vec); // pass ownership to `print_vec` +} +``` + +Now, just before `make_vec`'s scope ends, `vec` is moved out by +returning it; it is not destroyed. A caller like `use_vec` then +receives ownership of the vector. + +On the other hand, the `print_vec` function takes a `vec` parameter, +and ownership of the vector is transferred *to* it by its +caller. Since `print_vec` does not transfer the ownership any further, +at the end of its scope the vector is destroyed. + +Once ownership has been given away, a value can no longer be used. For +example, consider this variant of `use_vec`: + +```rust +fn use_vec() { + let vec = make_vec(); // take ownership of the vector + print_vec(vec); // pass ownership to `print_vec` + + for i in vec.iter() { // continue using `vec` + println!("{}", i * 2) + } +} +``` + +If you feed this version to the compiler, you'll get an error: + +``` +error: use of moved value: `vec` + +for i in vec.iter() { + ^~~ +``` + +The compiler is saying `vec` is no longer available; ownership has +been transferred elsewhere. And that's very good, because the vector +has already been deallocated at this point! + +Disaster averted. + +### Background: borrowing + +The story so far isn't very satisfying, because it's not our intent +for `print_vec` to destroy the vector it was given. What we really +want is to grant `print_vec` *temporary* access to the vector, and +then continue using the vector afterwards. + +This is where *borrowing* comes in. If you have access to a value in +Rust, you can lend out that access to the functions you call. **Rust +will check that these leases do not outlive the object being +borrowed**. + +To borrow a value, you make a *reference* to it (a kind of pointer), +using the `&` operator: + +```rust +fn print_vec(vec: &Vec) { + // the `vec` parameter is borrowed for this scope + + for i in vec.iter() { + println!("{}", i) + } + + // now, the borrow ends +} + +fn use_vec() { + let vec = make_vec(); // take ownership of the vector + print_vec(&vec); // lend access to `print_vec` + for i in vec.iter() { // continue using `vec` + println!("{}", i * 2) + } + // vec is destroyed here +} +``` + +Now `print_vec` takes a reference to a vector, and `use_vec` lends out +the vector by writing `&vec`. Since borrows are temporary, `use_vec` +retains ownership of the vector; it can continue using it after the +call to `print_vec` returns (and its lease on `vec` has expired). + +Each reference is valid for a limited scope, which the compiler will +automatically determine. References come in two flavors: + +* Immutable references `&T`, which allow aliasing but not mutation. + There can be multiple `&T` references to the same value + simultaneously, but the value cannot be mutated while those + references are active. + +* Mutable references `&mut T`, which allow mutation but not aliasing. + If there is an `&mut T` reference to a value, there can be no other + active references at that time, but the value can be mutated. + +Rust checks these rules at compile time; borrowing has no runtime +overhead. + +Why have two kinds of references? Consider a function like: + +```rust +fn push_all(from: &Vec, to: &mut Vec) { + for i in from.iter() { + to.push(*i); + } +} +``` + +This function iterates over each element of one vector, pushing it +onto another. The iterator keeps a pointer into the vector at the +current and final positions, stepping one toward the other. + +Suppose we called this function with the same vector for both arguments: + +```rust +push_all(&vec, &mut vec) +``` + +This would spell disaster! As we're pushing elements onto the vector, +it will occasionally need to resize, allocating a new hunk of memory +and copying its elements over to it. The iterator would be left with a +dangling pointer into the old memory, leading to memory unsafety (with +attendant segfaults and worse). + +Fortunately, Rust ensures that **whenever a mutable borrow is active, +no other borrows of the object are active**, producing the message: + +``` +error: cannot borrow `vec` as mutable because it is also borrowed as immutable +push_all(&vec, &mut vec); + ^~~ +``` + +Disaster averted. + +### Message passing + +Now that we've covered the basic ownership story in Rust, let's see +what it means for concurrency. + +Concurrent programming comes in many styles, but a particularly simple +one is message passing, where threads or actors communicate by sending +each other messages. Proponents of the style emphasize the way that +it ties together sharing and communication: + +> Do not communicate by sharing memory; instead, share memory by +> communicating. +> +> --[Effective Go](http://golang.org/doc/effective_go.html) + +**Rust's ownership makes it easy to turn that advice into a +compiler-checked rule**. Consider the following channel API +([channels in Rust's standard library][mpsc] are a bit different): + +```rust +fn send(chan: &Channel, t: T); +fn recv(chan: &Channel) -> T; +``` + +Channels are generic over the type of data they transmit (the `` part of the API). The `Send` part means that `T` must be +considered safe to send between threads; we'll come back to that later +in the post, but for now it's enough to know that `Vec` is +`Send`. + +As always in Rust, passing in a `T` to the `send` function means +transferring ownership of it. This fact has profound consequences: it +means that code like the following will generate a compiler error. + +```rust +// Suppose chan: Channel> + +let mut vec = Vec::new(); +// do some computation +send(&chan, vec); +print_vec(&vec); +``` + +Here, the thread creates a vector, sends it to another thread, and +then continues using it. The thread receiving the vector could mutate +it as this thread continues running, so the call to `print_vec` could +lead to race condition or, for that matter, a use-after-free bug. + +Instead, the Rust compiler will produce an error message on the call +to `print_vec`: + +``` +Error: use of moved value `vec` +``` + +Disaster averted. + +### Locks + +Another way to deal with concurrency is by having threads communicate +through passive, shared state. + +Shared-state concurrency has a bad rap. It's easy to forget to acquire +a lock, or otherwise mutate the wrong data at the wrong time, with +disastrous results -- so easy that many eschew the style altogether. + +Rust's take is that: + +1. Shared-state concurrency is a fundamental programming style, needed +for systems code, for maximal performance, and for implementing +other styles of concurrency. + +2. The problem is really about *accidentally* shared state. + +Rust aims to give you the tools to conquer shared-state concurrency +directly. + +In Rust, threads are "isolated" from each other automatically, due to +ownership. Writes can only happen when the thread has mutable access, +either by owning the data, or by having a mutable borrow of it. Either +way, **the thread is guaranteed to be the only one with access at the +time**. To see how this plays out, let's look at locks. + +Remember that mutable borrows cannot occur simultaneously with other +borrows. Locks provide the same guarantee ("mutual exclusion") through +synchronization at runtime. That leads to a locking API that hooks +directly into Rust's ownership system. + +Here is a simplified version (the [standard library's][mutex] +is more ergonomic): + +```rust +// create a new mutes +fn mutex(t: T) -> Mutex; + +// acquire the lock +fn lock(mutex: &Mutex) -> MutexGuard; + +// access the data protected by the lock +fn access(guard: &mut MutexGuard) -> &mut T; +``` + +This lock API is unusual in several respects. + +First, the `Mutex` type is generic over a type `T` of **the data +protected by the lock**. When you create a `Mutex`, you transfer +ownership of that data *into* the mutex, immediately giving up access +to it. (Locks are unlocked when they are first created.) + +Later, you can `lock` to block the thread until the lock is +acquired. This function, too, is unusual in providing a return value, +`MutexGuard`. The `MutexGuard` automatically releases the lock when +it is destroyed; there is no separate `unlock` function. + +The only way to access the lock is through the `access` function, +which turns a mutable borrow of the guard into a mutable borrow of the +data (with a shorter lease): + +```rust +fn use_lock(mutex: &Mutex>) { + // acquire the lock, taking ownership of a guard; + // the lock is held for the rest of the scope + let mut guard = lock(mutex); + + // access the data by mutably borrowing the guard + let vec = access(&mut guard); + + // vec has type `&mut Vec` + vec.push(3); + + // lock automatically released here, when `guard` is destroyed +} +``` + +There are two key ingredients here: + +* The mutable reference returned by `access` cannot outlive the + `MutexGuard` it is borrowing from. + +* The lock is only released when the `MutexGuard` is destroyed. + +The result is that **Rust will not let you access lock-protected data +except when holding the lock**. Any attempt to do otherwise will +generate a compiler error. For example, consider the following buggy +"refactoring": + +```rust +fn use_lock(mutex: &Mutex>) { + let vec = { + // acquire the lock + let mut guard = lock(mutex); + + // attempt to return a borrow of the data + access(&mut guard) + + // guard is destroyed here, releasing the lock + }; + + // attempt to access the data outside of the lock. + vec.push(3); +} +``` + +Rust will generate an error pinpointing the problem: + +``` +error: `guard` does not live long enough +access(&mut guard) + ^~~~~ +``` + +Disaster averted. + +### Thread safety and `Send` + +It's typical to distinguish some data types as "thread safe" and +others not. Thread safe data structures use enough internal +synchronization to be safely used by multiple threads concurrently. + +For example, Rust ships with two kinds of "smart pointers" for +reference counting: + +* `Rc` provides reference counting via normal reads/writes. It is + not thread safe. + +* `Arc` provides reference counting via *atomic* operations. It is + thread safe. + +The hardware atomic operations used by `Arc` are generally more +expensive than the vanilla operations used by `Rc`, so it's +advantageous to use `Rc` rather than `Arc` wherever possible. On the +other hand, it's critical that an `Rc` never migrate from one +thread to another, because that could lead to race conditions that +corrupt the count. + +Usually, the only recourse is careful documentation; most languages +make no *actual* distinction between thread-safe and thread-unsafe +types. + +In Rust, the world is divided into two kinds of data types: those that +are [`Send`][send], meaning they can be safely moved from one thread to +another, and those that are `!Send`, meaning that it may not be safe +to do so. If all of a type's components are `Send`, so is that type -- +which covers most types. Certain base types are not inherently +thread-safe, though, so it's also possible to explicitly mark a type +like `Arc` as `Send`, saying to the compiler: "Trust me; I've verified +the necessary synchronization here." + +Naturally, `Arc` is `Send`, and `Rc` is not. + +We already saw that the `Channel` and `Mutex` APIs work only with +`Send` data. since they are the point at which data crosses thread +boundaries, they are also the point of enforcement for `Send`. + +Putting this all together, Rust programmers can reap the benefits of +`Rc` and other thread-unsafe types with confidence, knowing that if +they ever do accidentally try to send one to another thread, the Rust +compiler will say: + +``` +`Rc>` cannot be sent between threads safely +``` + +Disaster averted. + +### Sharing the stack: `scoped` + +So far, all the patterns we've seen involve creating data structures +on the heap that get shared between threads. But what if we wanted to +start some threads that make use of data living in our stack frame? +That could be dangerous: + +```rust +fn parent() { + let mut vec = Vec::new(); + // fill the vector + thread::spawn(|| { + print_vec(&vec) + }) +} +``` + +The child thread take a reference to `vec`, which in turn resides in +the stack frame of `parent`. When `parent` exists, the stack frame is +popped, but the child thread is none the wiser. Oops! + +To rule out such memory unsafety, Rust's basic thread spawning API +looks a bit like this: + +```rust +fn spawn(f: F) where F: 'static, ... +``` + +The `'static` constraint is a way of saying, roughly, that no borrowed +data is permitted in the closure. It means that a function like +`parent` above will generate an error: + +``` +error: `vec` does not live long enough +``` + +essentially catching the possibility of `parent`'s stack frame +popping. Disaster averted. + +But there is another way to guarantee safety: ensure that the parent +stack frame stays put until the child thread is done. This is the +pattern of *fork-join* programming, often used for divide-and-conquer +parallel algorithms. Rust supports it by providing a +["scoped"][scoped] variant of thread spawning: + +```rust +fn scoped<'a, F>(f: F) -> JoinGuard<'a> where F: 'a, ... +``` + +There are two key differences from the `spawn` API above: + +* The use a parameter `'a`, rather than `'static`. This parameter + represents a scope that encompasses all the borrows within the + closure, `f`. + +* The return value, a `JoinGuard`. As its name suggests, `JoinGuard` + ensures that the parent thread joins (waits on) its child, by + performing an implicit join in its destructor (if one hasn't happened + explicitly already). + +Including `'a` in `JoinGuard` ensures that the `JoinGuard` **cannot +escape the scope of any data borrowed by the closure**. In other +words, Rust guarantees that the parent thread waits for the child to +finish before popping any stack frames the child might have access to. + +Thus by adjusting our previous example, we can fix the bug and satisfy +the compiler: + +```rust +fn parent() { + let mut vec = Vec::new(); + // fill the vector + let guard = thread::scoped(|| { + print_vec(&vec) + }) + // guard destroyed here, implicitly joining +} +``` + +So in Rust, you can freely borrow stack data into child threads, +confident that the compiler will check for sufficient synchronization. + +### Data races + +At this point, we've seen enough to venture a strong statement about +Rust's approach to concurrency: the compiler prevents all *data races*. + +> A data race is any unsynchronized, concurrent access to data +> involving a write. + +Synchronization here includes things as low-level as atomic +instructions. Essentially, this is a way of saying that you cannot +accidentally "share state" between threads; all (mutating) access to +state has to be mediated by *some* form of synchronization. + +Data races are just one (very important) kind of race condition, but +by preventing them, Rust often helps you prevent other, more subtle +races as well. For example, it's often important that updates to +different locations appear to take place *atomically*: other threads +see either all of the updates, or none of them. In Rust, having `&mut` +access to the relevant locations at the same time **guarantees +atomicity of updates to them**, since no other thread could possibly +have concurrent read access. + +In short, ownership and borrowing give rise to *two* key value +propositions for Rust: + +* Memory safety without garbage collection. +* Concurrency without data races. + +### The future + +When Rust first began, it baked channels directly into the language, +taking a very opinionated stance on concurrency. + +In today's Rust, concurrency is *entirely* a library affair; +everything described in this post, including `Send`, is defined in the +standard library, and could be defined in an external library instead. + +And that's very exciting, because it means that Rust's concurrency +story can endlessly evolve, growing to encompass new paradigms and +catch new classes of bugs. Libraries like [syncbox][syncbox] and +[simple_parallel][simple_parallel] are taking some of the first steps, +and we expect to invest heavily in this space in the next few +months. Stay tuned! + +[mpsc]: http://static.rust-lang.org/doc/master/std/sync/mpsc/index.html +[mutex]: http://static.rust-lang.org/doc/master/std/sync/struct.Mutex.html +[send]: http://static.rust-lang.org/doc/master/std/marker/trait.Send.html +[sync]: http://static.rust-lang.org/doc/master/std/marker/trait.Sync.html +[scoped]: http://static.rust-lang.org/doc/master/std/thread/fn.scoped.html +[syncbox]: https://github.com/carllerche/syncbox +[simple_parallel]: https://github.com/huonw/simple_parallel From 6eaf25bb0a5a4a0b1fdbae90ef4e7ccaa4c6d6c0 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 10 Apr 2015 01:13:50 -0700 Subject: [PATCH 64/74] Revisions to intro --- _posts/2015-04-10-Fearless-Concurrency.md | 56 +++++++++++++++-------- 1 file changed, 37 insertions(+), 19 deletions(-) diff --git a/_posts/2015-04-10-Fearless-Concurrency.md b/_posts/2015-04-10-Fearless-Concurrency.md index cb8e5ef51..243390f6e 100644 --- a/_posts/2015-04-10-Fearless-Concurrency.md +++ b/_posts/2015-04-10-Fearless-Concurrency.md @@ -4,39 +4,57 @@ title: "Fearless Concurrency with Rust" author: Aaron Turon --- -Rust solves an apparent contradiction: safe systems programming. Its -secret weapon is *ownership*, a concept ubiquitous in systems -programming that Rust's compiler statically checks for you. The -result: you can program without a garbage collector *and* without fear -of segfaults, because Rust will catch your mistakes. +The Rust project was initiated to solve two thorny problems: -**The same tools that make Rust safe also help tackle concurrency -head-on.** After all, use-after-free bugs and synchronization bugs -both happen when code accesses data it shouldn't -- and as we'll -see, ownership is all about access control. +* How do you do safe systems programming? +* How do you do make concurrency painless? + +Initially these problems seemed orthogonal, but to our amazement, they +turned out to really be the same: **the same tools that make Rust safe +also help you tackle concurrency head-on**. + +Memory safety bugs and concurrency bugs often come down to code +accessing data when it shouldn't. Rust's secret weapon is *ownership*, +a discipline for access control that systems programmers try to +follow, but that Rust's compiler checks statically for you. + +For memory safety, this means you can program without a garbage +collector *and* without fear of segfaults, because Rust will catch +your mistakes. + +For concurrency, this means you can choose from a wide variety of +paradigms (message passing, shared state, lock-free, purely +functional), and Rust's ownership will help you avoid the associated +pitfalls. Here's a taste of concurrency in Rust: * A [channel][mpsc] transfers ownership of the messages sent along it, so you can send a pointer from one thread to another without fear of - the threads later racing for access through that pointer. + the threads later racing for access through that pointer. **Channels + enforce thread isolation.** * A [lock][mutex] knows what data it protects, and Rust guarantees - that the data can only be accessed when the lock is held. + that the data can only be accessed when the lock is held. State is + never accidentally shared. **"Lock data, not code" is enforced in + Rust.** * Every data type knows whether it can safely be [sent][send] between or [accessed][sync] by multiple threads, and Rust enforces this safe - usage; there are no data races. + usage; there are no data races, even for lock-free data structures. + **Thread safety isn't just documentation; it's law.** * You can even [share stack frames][scoped] between threads, and Rust will statically ensure that the frames remain active while other - threads are using them. - -None of the above benefits require any special knowledge to be built -in to the compiler. Locks, channels, semaphores, atomic operations and -so on are all *libraries* that take advantage of Rust's existing -features to provide the static checking underlying these strong -guarantees. + threads are using them. **Even the most daring forms of sharing are + guaranteed safe in Rust**. + +All of these benefits come out of Rust's ownership model, and in fact +locks, channels, lock-fee data structures and so on are defined in +libraries, not the core language. That means that Rust's approach to +concurrency is *open ended*: new libraries can embrace new paradigms and +catch new bugs, just by adding APIs that take advantage of Rust's +general ownership features. The goal of this post is to give you some idea of how that's done. From 17c678d7fcfe11d41d1836fe4665a15c158f76d9 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 10 Apr 2015 01:53:26 -0700 Subject: [PATCH 65/74] Add description field --- _posts/2015-04-10-Fearless-Concurrency.md | 1 + 1 file changed, 1 insertion(+) diff --git a/_posts/2015-04-10-Fearless-Concurrency.md b/_posts/2015-04-10-Fearless-Concurrency.md index 243390f6e..c1670f30d 100644 --- a/_posts/2015-04-10-Fearless-Concurrency.md +++ b/_posts/2015-04-10-Fearless-Concurrency.md @@ -2,6 +2,7 @@ layout: post title: "Fearless Concurrency with Rust" author: Aaron Turon +description: "Rust's vision for concurrency" --- The Rust project was initiated to solve two thorny problems: From 64fbfd921d66d5b9525a7ebb09ae6fcd6d77a59c Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 10 Apr 2015 09:20:49 -0700 Subject: [PATCH 66/74] Final round of revisions --- _posts/2015-04-10-Fearless-Concurrency.md | 79 ++++++++++++----------- 1 file changed, 41 insertions(+), 38 deletions(-) diff --git a/_posts/2015-04-10-Fearless-Concurrency.md b/_posts/2015-04-10-Fearless-Concurrency.md index c1670f30d..e81c1f4d2 100644 --- a/_posts/2015-04-10-Fearless-Concurrency.md +++ b/_posts/2015-04-10-Fearless-Concurrency.md @@ -10,9 +10,9 @@ The Rust project was initiated to solve two thorny problems: * How do you do safe systems programming? * How do you do make concurrency painless? -Initially these problems seemed orthogonal, but to our amazement, they -turned out to really be the same: **the same tools that make Rust safe -also help you tackle concurrency head-on**. +Initially these problems seemed orthogonal, but to our amazement, the +solution turned out to be identical: **the same tools that make Rust +safe also help you tackle concurrency head-on**. Memory safety bugs and concurrency bugs often come down to code accessing data when it shouldn't. Rust's secret weapon is *ownership*, @@ -25,15 +25,14 @@ your mistakes. For concurrency, this means you can choose from a wide variety of paradigms (message passing, shared state, lock-free, purely -functional), and Rust's ownership will help you avoid the associated -pitfalls. +functional), and Rust will help you avoid common pitfalls. Here's a taste of concurrency in Rust: * A [channel][mpsc] transfers ownership of the messages sent along it, so you can send a pointer from one thread to another without fear of - the threads later racing for access through that pointer. **Channels - enforce thread isolation.** + the threads later racing for access through that pointer. **Rust's + channels enforce thread isolation.** * A [lock][mutex] knows what data it protects, and Rust guarantees that the data can only be accessed when the lock is held. State is @@ -53,9 +52,9 @@ Here's a taste of concurrency in Rust: All of these benefits come out of Rust's ownership model, and in fact locks, channels, lock-fee data structures and so on are defined in libraries, not the core language. That means that Rust's approach to -concurrency is *open ended*: new libraries can embrace new paradigms and -catch new bugs, just by adding APIs that take advantage of Rust's -general ownership features. +concurrency is *open ended*: new libraries can embrace new paradigms +and catch new bugs, just by adding APIs that use Rust's ownership +features. The goal of this post is to give you some idea of how that's done. @@ -88,10 +87,10 @@ fn make_vec() { ``` The scope that creates a value also initially owns it. In this case, -the `make_vec` function's body (the part within `{` and `}`) is the -owning scope for `vec`. The owner can do anything it likes with `vec`, -including mutating it by pushing. At the end of the scope, `vec` is -still owned, so it is automatically deallocated. +the body of `make_vec` is the owning scope for `vec`. The owner can do +anything it likes with `vec`, including mutating it by pushing. At the +end of the scope, `vec` is still owned, so it is automatically +deallocated. Things get more interesting if the vector is returned or passed around: @@ -159,7 +158,7 @@ Disaster averted. ### Background: borrowing -The story so far isn't very satisfying, because it's not our intent +The story so far isn't totally satisfying, because it's not our intent for `print_vec` to destroy the vector it was given. What we really want is to grant `print_vec` *temporary* access to the vector, and then continue using the vector afterwards. @@ -201,12 +200,12 @@ call to `print_vec` returns (and its lease on `vec` has expired). Each reference is valid for a limited scope, which the compiler will automatically determine. References come in two flavors: -* Immutable references `&T`, which allow aliasing but not mutation. +* Immutable references `&T`, which allow sharing but not mutation. There can be multiple `&T` references to the same value simultaneously, but the value cannot be mutated while those references are active. -* Mutable references `&mut T`, which allow mutation but not aliasing. +* Mutable references `&mut T`, which allow mutation but not sharing. If there is an `&mut T` reference to a value, there can be no other active references at that time, but the value can be mutated. @@ -227,7 +226,7 @@ This function iterates over each element of one vector, pushing it onto another. The iterator keeps a pointer into the vector at the current and final positions, stepping one toward the other. -Suppose we called this function with the same vector for both arguments: +What if we called this function with the same vector for both arguments? ```rust push_all(&vec, &mut vec) @@ -237,7 +236,7 @@ This would spell disaster! As we're pushing elements onto the vector, it will occasionally need to resize, allocating a new hunk of memory and copying its elements over to it. The iterator would be left with a dangling pointer into the old memory, leading to memory unsafety (with -attendant segfaults and worse). +attendant segfaults or worse). Fortunately, Rust ensures that **whenever a mutable borrow is active, no other borrows of the object are active**, producing the message: @@ -318,14 +317,14 @@ disastrous results -- so easy that many eschew the style altogether. Rust's take is that: -1. Shared-state concurrency is a fundamental programming style, needed -for systems code, for maximal performance, and for implementing -other styles of concurrency. +1. Shared-state concurrency is nevertheless a fundamental programming +style, needed for systems code, for maximal performance, and for +implementing other styles of concurrency. 2. The problem is really about *accidentally* shared state. Rust aims to give you the tools to conquer shared-state concurrency -directly. +directly, whether you're using locking or lock-free techniques. In Rust, threads are "isolated" from each other automatically, due to ownership. Writes can only happen when the thread has mutable access, @@ -391,10 +390,10 @@ There are two key ingredients here: * The lock is only released when the `MutexGuard` is destroyed. -The result is that **Rust will not let you access lock-protected data -except when holding the lock**. Any attempt to do otherwise will -generate a compiler error. For example, consider the following buggy -"refactoring": +The result is that **Rust enforces locking discipline: it will not let +you access lock-protected data except when holding the lock**. Any +attempt to do otherwise will generate a compiler error. For example, +consider the following buggy "refactoring": ```rust fn use_lock(mutex: &Mutex>) { @@ -438,15 +437,14 @@ reference counting: * `Arc` provides reference counting via *atomic* operations. It is thread safe. -The hardware atomic operations used by `Arc` are generally more -expensive than the vanilla operations used by `Rc`, so it's -advantageous to use `Rc` rather than `Arc` wherever possible. On the -other hand, it's critical that an `Rc` never migrate from one -thread to another, because that could lead to race conditions that -corrupt the count. +The hardware atomic operations used by `Arc` are more expensive than +the vanilla operations used by `Rc`, so it's advantageous to use `Rc` +rather than `Arc`. On the other hand, it's critical that an `Rc` +never migrate from one thread to another, because that could lead to +race conditions that corrupt the count. Usually, the only recourse is careful documentation; most languages -make no *actual* distinction between thread-safe and thread-unsafe +make no *semantic* distinction between thread-safe and thread-unsafe types. In Rust, the world is divided into two kinds of data types: those that @@ -465,7 +463,7 @@ We already saw that the `Channel` and `Mutex` APIs work only with boundaries, they are also the point of enforcement for `Send`. Putting this all together, Rust programmers can reap the benefits of -`Rc` and other thread-unsafe types with confidence, knowing that if +`Rc` and other thread-*unsafe* types with confidence, knowing that if they ever do accidentally try to send one to another thread, the Rust compiler will say: @@ -560,7 +558,7 @@ confident that the compiler will check for sufficient synchronization. ### Data races At this point, we've seen enough to venture a strong statement about -Rust's approach to concurrency: the compiler prevents all *data races*. +Rust's approach to concurrency: **the compiler prevents all *data races*.** > A data race is any unsynchronized, concurrent access to data > involving a write. @@ -579,8 +577,13 @@ access to the relevant locations at the same time **guarantees atomicity of updates to them**, since no other thread could possibly have concurrent read access. -In short, ownership and borrowing give rise to *two* key value -propositions for Rust: +It's worth pausing for a moment to think about this guarantee in the +broader landscape of languages. Many languages provide memory safety +through garbage collection. But garbage collection doesn't give you +any help in preventing data races. + +Rust instead uses ownership and borrowing to provide its two key value +propositions: * Memory safety without garbage collection. * Concurrency without data races. From b35727916027e99fc2f601ff7e9fc09fd8ef14a3 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 10 Apr 2015 09:31:15 -0700 Subject: [PATCH 67/74] Fix code fence problem --- _posts/2015-04-10-Fearless-Concurrency.md | 84 +++++++++++------------ 1 file changed, 42 insertions(+), 42 deletions(-) diff --git a/_posts/2015-04-10-Fearless-Concurrency.md b/_posts/2015-04-10-Fearless-Concurrency.md index e81c1f4d2..0808053e7 100644 --- a/_posts/2015-04-10-Fearless-Concurrency.md +++ b/_posts/2015-04-10-Fearless-Concurrency.md @@ -77,14 +77,14 @@ destroyed at that point. Let's look at some simple examples. Suppose we create a vector and push some elements onto it: -```rust +~~~~rust fn make_vec() { let mut vec = Vec::new(); // owned by make_vec's scope vec.push(0); vec.push(1); // scope ends, `vec` is destroyed } -``` +~~~~ The scope that creates a value also initially owns it. In this case, the body of `make_vec` is the owning scope for `vec`. The owner can do @@ -94,7 +94,7 @@ deallocated. Things get more interesting if the vector is returned or passed around: -```rust +~~~~rust fn make_vec() -> Vec { let mut vec = Vec::new(); vec.push(0); @@ -116,7 +116,7 @@ fn use_vec() { let vec = make_vec(); // take ownership of the vector print_vec(vec); // pass ownership to `print_vec` } -``` +~~~~ Now, just before `make_vec`'s scope ends, `vec` is moved out by returning it; it is not destroyed. A caller like `use_vec` then @@ -130,7 +130,7 @@ at the end of its scope the vector is destroyed. Once ownership has been given away, a value can no longer be used. For example, consider this variant of `use_vec`: -```rust +~~~~rust fn use_vec() { let vec = make_vec(); // take ownership of the vector print_vec(vec); // pass ownership to `print_vec` @@ -139,16 +139,16 @@ fn use_vec() { println!("{}", i * 2) } } -``` +~~~~ If you feed this version to the compiler, you'll get an error: -``` +~~~~ error: use of moved value: `vec` for i in vec.iter() { ^~~ -``` +~~~~ The compiler is saying `vec` is no longer available; ownership has been transferred elsewhere. And that's very good, because the vector @@ -171,7 +171,7 @@ borrowed**. To borrow a value, you make a *reference* to it (a kind of pointer), using the `&` operator: -```rust +~~~~rust fn print_vec(vec: &Vec) { // the `vec` parameter is borrowed for this scope @@ -190,7 +190,7 @@ fn use_vec() { } // vec is destroyed here } -``` +~~~~ Now `print_vec` takes a reference to a vector, and `use_vec` lends out the vector by writing `&vec`. Since borrows are temporary, `use_vec` @@ -214,13 +214,13 @@ overhead. Why have two kinds of references? Consider a function like: -```rust +~~~~rust fn push_all(from: &Vec, to: &mut Vec) { for i in from.iter() { to.push(*i); } } -``` +~~~~ This function iterates over each element of one vector, pushing it onto another. The iterator keeps a pointer into the vector at the @@ -228,9 +228,9 @@ current and final positions, stepping one toward the other. What if we called this function with the same vector for both arguments? -```rust +~~~~rust push_all(&vec, &mut vec) -``` +~~~~ This would spell disaster! As we're pushing elements onto the vector, it will occasionally need to resize, allocating a new hunk of memory @@ -241,11 +241,11 @@ attendant segfaults or worse). Fortunately, Rust ensures that **whenever a mutable borrow is active, no other borrows of the object are active**, producing the message: -``` +~~~~ error: cannot borrow `vec` as mutable because it is also borrowed as immutable push_all(&vec, &mut vec); ^~~ -``` +~~~~ Disaster averted. @@ -268,10 +268,10 @@ it ties together sharing and communication: compiler-checked rule**. Consider the following channel API ([channels in Rust's standard library][mpsc] are a bit different): -```rust +~~~~rust fn send(chan: &Channel, t: T); fn recv(chan: &Channel) -> T; -``` +~~~~ Channels are generic over the type of data they transmit (the `` part of the API). The `Send` part means that `T` must be @@ -283,14 +283,14 @@ As always in Rust, passing in a `T` to the `send` function means transferring ownership of it. This fact has profound consequences: it means that code like the following will generate a compiler error. -```rust +~~~~rust // Suppose chan: Channel> let mut vec = Vec::new(); // do some computation send(&chan, vec); print_vec(&vec); -``` +~~~~ Here, the thread creates a vector, sends it to another thread, and then continues using it. The thread receiving the vector could mutate @@ -300,9 +300,9 @@ lead to race condition or, for that matter, a use-after-free bug. Instead, the Rust compiler will produce an error message on the call to `print_vec`: -``` +~~~~ Error: use of moved value `vec` -``` +~~~~ Disaster averted. @@ -340,7 +340,7 @@ directly into Rust's ownership system. Here is a simplified version (the [standard library's][mutex] is more ergonomic): -```rust +~~~~rust // create a new mutes fn mutex(t: T) -> Mutex; @@ -349,7 +349,7 @@ fn lock(mutex: &Mutex) -> MutexGuard; // access the data protected by the lock fn access(guard: &mut MutexGuard) -> &mut T; -``` +~~~~ This lock API is unusual in several respects. @@ -367,7 +367,7 @@ The only way to access the lock is through the `access` function, which turns a mutable borrow of the guard into a mutable borrow of the data (with a shorter lease): -```rust +~~~~rust fn use_lock(mutex: &Mutex>) { // acquire the lock, taking ownership of a guard; // the lock is held for the rest of the scope @@ -381,7 +381,7 @@ fn use_lock(mutex: &Mutex>) { // lock automatically released here, when `guard` is destroyed } -``` +~~~~ There are two key ingredients here: @@ -395,7 +395,7 @@ you access lock-protected data except when holding the lock**. Any attempt to do otherwise will generate a compiler error. For example, consider the following buggy "refactoring": -```rust +~~~~rust fn use_lock(mutex: &Mutex>) { let vec = { // acquire the lock @@ -410,15 +410,15 @@ fn use_lock(mutex: &Mutex>) { // attempt to access the data outside of the lock. vec.push(3); } -``` +~~~~ Rust will generate an error pinpointing the problem: -``` +~~~~ error: `guard` does not live long enough access(&mut guard) ^~~~~ -``` +~~~~ Disaster averted. @@ -467,9 +467,9 @@ Putting this all together, Rust programmers can reap the benefits of they ever do accidentally try to send one to another thread, the Rust compiler will say: -``` +~~~~ `Rc>` cannot be sent between threads safely -``` +~~~~ Disaster averted. @@ -480,7 +480,7 @@ on the heap that get shared between threads. But what if we wanted to start some threads that make use of data living in our stack frame? That could be dangerous: -```rust +~~~~rust fn parent() { let mut vec = Vec::new(); // fill the vector @@ -488,7 +488,7 @@ fn parent() { print_vec(&vec) }) } -``` +~~~~ The child thread take a reference to `vec`, which in turn resides in the stack frame of `parent`. When `parent` exists, the stack frame is @@ -497,17 +497,17 @@ popped, but the child thread is none the wiser. Oops! To rule out such memory unsafety, Rust's basic thread spawning API looks a bit like this: -```rust +~~~~rust fn spawn(f: F) where F: 'static, ... -``` +~~~~ The `'static` constraint is a way of saying, roughly, that no borrowed data is permitted in the closure. It means that a function like `parent` above will generate an error: -``` +~~~~ error: `vec` does not live long enough -``` +~~~~ essentially catching the possibility of `parent`'s stack frame popping. Disaster averted. @@ -518,9 +518,9 @@ pattern of *fork-join* programming, often used for divide-and-conquer parallel algorithms. Rust supports it by providing a ["scoped"][scoped] variant of thread spawning: -```rust +~~~~rust fn scoped<'a, F>(f: F) -> JoinGuard<'a> where F: 'a, ... -``` +~~~~ There are two key differences from the `spawn` API above: @@ -541,7 +541,7 @@ finish before popping any stack frames the child might have access to. Thus by adjusting our previous example, we can fix the bug and satisfy the compiler: -```rust +~~~~rust fn parent() { let mut vec = Vec::new(); // fill the vector @@ -550,7 +550,7 @@ fn parent() { }) // guard destroyed here, implicitly joining } -``` +~~~~ So in Rust, you can freely borrow stack data into child threads, confident that the compiler will check for sufficient synchronization. From 467f5d7d2543d55031b599ee00e55b36192e3c26 Mon Sep 17 00:00:00 2001 From: Ricardo Mendes Date: Fri, 10 Apr 2015 17:40:44 +0100 Subject: [PATCH 68/74] Typo in code comment, mutes -> mutex --- _posts/2015-04-10-Fearless-Concurrency.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2015-04-10-Fearless-Concurrency.md b/_posts/2015-04-10-Fearless-Concurrency.md index 0808053e7..c3eb59c37 100644 --- a/_posts/2015-04-10-Fearless-Concurrency.md +++ b/_posts/2015-04-10-Fearless-Concurrency.md @@ -341,7 +341,7 @@ Here is a simplified version (the [standard library's][mutex] is more ergonomic): ~~~~rust -// create a new mutes +// create a new mutex fn mutex(t: T) -> Mutex; // acquire the lock From c21d868d58bf834a9d4ff5d06103263c89b07363 Mon Sep 17 00:00:00 2001 From: Brian Anderson Date: Fri, 10 Apr 2015 09:50:51 -0700 Subject: [PATCH 69/74] Set up highlighting --- _config.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/_config.yml b/_config.yml index 8f9f594d4..ece89c2c2 100644 --- a/_config.yml +++ b/_config.yml @@ -9,6 +9,7 @@ twitter_username: rustlang github_username: rust-lang # Build settings -markdown: kramdown +highlighter: pygments +markdown: redcarpet root: http://blog.rust-lang.org From 35a85407f1880cd99e3a4679f3bc353e57d0965e Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 10 Apr 2015 09:54:22 -0700 Subject: [PATCH 70/74] Adjust section headers to avoid code --- _posts/2015-04-10-Fearless-Concurrency.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/2015-04-10-Fearless-Concurrency.md b/_posts/2015-04-10-Fearless-Concurrency.md index c3eb59c37..29f180a3f 100644 --- a/_posts/2015-04-10-Fearless-Concurrency.md +++ b/_posts/2015-04-10-Fearless-Concurrency.md @@ -422,7 +422,7 @@ access(&mut guard) Disaster averted. -### Thread safety and `Send` +### Thread safety and "Send" It's typical to distinguish some data types as "thread safe" and others not. Thread safe data structures use enough internal @@ -473,7 +473,7 @@ compiler will say: Disaster averted. -### Sharing the stack: `scoped` +### Sharing the stack: "scoped" So far, all the patterns we've seen involve creating data structures on the heap that get shared between threads. But what if we wanted to From 2e1b32ae1e8a1a2a655e070d0164d59b56609f99 Mon Sep 17 00:00:00 2001 From: Chas Date: Fri, 10 Apr 2015 10:17:07 -0700 Subject: [PATCH 71/74] Fixed typo in 2015-04-10-Fearless-Concurrency.md lock-fee should be lock-free --- _posts/2015-04-10-Fearless-Concurrency.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2015-04-10-Fearless-Concurrency.md b/_posts/2015-04-10-Fearless-Concurrency.md index 29f180a3f..e0d089c0c 100644 --- a/_posts/2015-04-10-Fearless-Concurrency.md +++ b/_posts/2015-04-10-Fearless-Concurrency.md @@ -50,7 +50,7 @@ Here's a taste of concurrency in Rust: guaranteed safe in Rust**. All of these benefits come out of Rust's ownership model, and in fact -locks, channels, lock-fee data structures and so on are defined in +locks, channels, lock-free data structures and so on are defined in libraries, not the core language. That means that Rust's approach to concurrency is *open ended*: new libraries can embrace new paradigms and catch new bugs, just by adding APIs that use Rust's ownership From 3791406dda9ef9c0327ee8e35a0b54a4718850ed Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 10 Apr 2015 10:43:29 -0700 Subject: [PATCH 72/74] Fix uncapitalized letter --- _posts/2015-04-10-Fearless-Concurrency.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2015-04-10-Fearless-Concurrency.md b/_posts/2015-04-10-Fearless-Concurrency.md index c3eb59c37..ec5139013 100644 --- a/_posts/2015-04-10-Fearless-Concurrency.md +++ b/_posts/2015-04-10-Fearless-Concurrency.md @@ -459,7 +459,7 @@ the necessary synchronization here." Naturally, `Arc` is `Send`, and `Rc` is not. We already saw that the `Channel` and `Mutex` APIs work only with -`Send` data. since they are the point at which data crosses thread +`Send` data. Since they are the point at which data crosses thread boundaries, they are also the point of enforcement for `Send`. Putting this all together, Rust programmers can reap the benefits of From 92e8e6994fa8fdd95afac0c202c1de26f342340b Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 10 Apr 2015 10:54:16 -0700 Subject: [PATCH 73/74] Add missing semicolon --- _posts/2015-04-10-Fearless-Concurrency.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2015-04-10-Fearless-Concurrency.md b/_posts/2015-04-10-Fearless-Concurrency.md index c3eb59c37..8d7065c06 100644 --- a/_posts/2015-04-10-Fearless-Concurrency.md +++ b/_posts/2015-04-10-Fearless-Concurrency.md @@ -547,7 +547,7 @@ fn parent() { // fill the vector let guard = thread::scoped(|| { print_vec(&vec) - }) + }); // guard destroyed here, implicitly joining } ~~~~ From 55b7f97982c52369f8f04517959307409ff62aa6 Mon Sep 17 00:00:00 2001 From: Steve Klabnik Date: Fri, 10 Apr 2015 15:57:10 -0400 Subject: [PATCH 74/74] spelling fix --- _posts/2015-04-10-Fearless-Concurrency.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2015-04-10-Fearless-Concurrency.md b/_posts/2015-04-10-Fearless-Concurrency.md index b71001836..e9ce1aa3c 100644 --- a/_posts/2015-04-10-Fearless-Concurrency.md +++ b/_posts/2015-04-10-Fearless-Concurrency.md @@ -491,7 +491,7 @@ fn parent() { ~~~~ The child thread take a reference to `vec`, which in turn resides in -the stack frame of `parent`. When `parent` exists, the stack frame is +the stack frame of `parent`. When `parent` exits, the stack frame is popped, but the child thread is none the wiser. Oops! To rule out such memory unsafety, Rust's basic thread spawning API