8000 Initial post · kstep/blog.rust-lang.org@49e2d55 · GitHub
[go: up one dir, main page]
Skip to content

Commit 49e2d55

Browse files
nikomatsakisnikomatsakis
committed
Initial post
1 parent 420589d commit 49e2d55

File tree

2 files changed

+172
-6
lines changed

2 files changed

+172
-6
lines changed

‎_posts/2014-09-08-welcome-to-the-rust-blog.md

Lines changed: 0 additions & 6 deletions
This file was deleted.

‎_posts/2014-09-15-Rust-1.0.md

Lines changed: 172 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,172 @@
1+
---
2+
layout: post
3+
title: "Road to Rust 1.0"
4+
---
5+
6+
Rust 1.0 is on its way! We have nailed down a concrete list of
7+
features and are hard at work on implementing them. We plan to ship
8+
the 1.0 beta around the end of the year. If all goes well, this will
9+
go on to become the 1.0 release after the beta period. After
10+
1.0 is released, future 1.x releases will be backwards compatible,
11+
meaning that existing code will continue to compile unmodified (modulo
12+
compiler bugs, of course).
13+
14+
Of course, a Rust 1.0 release means something more than "your code
15+
will continue to compile". Basically, it means that we think the
16+
design of Rust finally feels right. More specifically, it feels
17+
*minimal*. The language itself is now focused on a simple core
18+
concept, which we call ownership and borrowing (more on this
19+
later). Leveraging ownership and borrowing, we are been able to build
20+
up everything else that we have needed in libraries. This is very
21+
exciting, because any library we can write, you can write too. This
22+
really gives us confidence that Rust will not only achieve its
23+
original goals but also go beyond and be used for all kinds of things
24+
that we haven't even envisioned.
25+
26+
### The road to Rust 1.0
27+
28+
Rust has gone through a long evolution. If you haven't looked at Rust
29+
in a while, you may be surprised at what you see: over the last year,
30+
we've been radically simplifying the design. As a prominent example,
31+
Rust once featured several pointer types, indicated by various sigils:
32+
these are gone, and only the reference types (`&T`, `&mut T`)
33+
remain. We have also been able to consolidate and simplify a number of
34+
other language features, such as closures, that once sported a wide
35+
variety of options. (Some of these changes are still in progress.)
36+
37+
The key to all these changes has been a focus on the core concepts of
38+
*ownership and borrowing*. Initially, we introduced ownership as a
39+
means of transferring data safely and efficiently between tasks, but
40+
over time we have realized that the same mechanism allows us to move
41+
all sorts of things out of the language and into libraries. The
42+
resulting design is not only simpler to learn, but it is also much
43+
"closer to the metal" than we ever thought possible before. All Rust
44+
language constructs have a very direct mapping to machine operations,
45+
and Rust has no required runtime or external dependencies. When used
46+
in its own most minimal configuration, it is even possible to write an
47+
[operating][k1] [systems][k4] [kernel][k2] in Rust.
48+
49+
Throughout these changes, though, Rust has remained true to its goal
50+
of providing the **safety** and **convenience** of modern programming
51+
languages, while still offering the **efficiency** and **low-level
52+
control** that C and C++ offer. Basically, if you want to get your
53+
hands dirty with the bare metal machine, but you don't want to spend
54+
hours tracking down segfaults and data races, Rust is the language for
55+
you.
56+
57+
If you're not already familiar with Rust, don't worry. Over the next
58+
few months, we plan on issuing a regular series of blog posts
59+
exploring the language. The first few will focus on different aspects
60+
of ownership and how it can be used to achieve safe manual memory
61+
management, concurrency, and more. After that, we'll turn to other
62+
aspects of the Rust language and ecosystem.
63+
64+
### What is left to do
65+
66+
We've made great progress, but there is still a lot to do before the
67+
release. Here is a list of the big-ticket changes we are currently
68+
working on:
69+
70+
- *Dynamically sized types:* This extension to the type system allows
71+
us to uniformly handle types where the size is not known at compile
72+
time, such as an array type. This enables us to support
73+
user-designed smart pointers that contain arrays or
74+
objects. Nicholas Cameron [recently landed][dst] a heroic commit
75+
implementing the bulk of the work.
76+
- *Unboxed closures:* Our new [closure design][cd] unifies closures
77+
and object types. Much of the spec has been implemented.
78+
- *Associated types:* We are moving our trait system to use
79+
[associated types][at], which really help to cut down on the level
80+
of generic annotations required to write advanced generic
81+
libraries. Patrick Walton has done an initial implementation.
82+
- *Where clauses:* We are adding a flexible new form of constraints
83+
called [where clauses][wc]. Patrick Walton already landed support
84+
for the basic syntax, and I have implemented the remaining
85+
functionality on a branch that should be landing soon.
86+
- *Multidispatch traits:* We are extending traits so that they
87+
can [match on more than one type at a time][at], which opens up a lot of
88+
new opportunities for more ergonomic APIs. I have
89+
prototyped this work on a branch.
90+
- *Destructors:* We are improving our destructor semantics to not
91+
require zeroing of memory, which should improve compilation and
92+
execution times. Felix Klock has implemented the requisite analysis
93+
and is in the process of landing it.
94+
- *Green threading:* We are removing support from green threading from
95+
the standard library and moving it out into an external
96+
package. This allows for a closer match between the Rust model and
97+
the underlying operating system, which makes for more efficient
98+
programs. Aaron Turon has [written the RFC][gt] and is getting
99+
started on that work now.
100+
101+
At the library level, we are currently engaged in a sweep over libstd
102+
to decide what portions are stable and which are not. You can
103+
[monitor the progress][stability] here. (Note though that many of the
104+
'unstable' items are simply things whose name will be changed slightly
105+
to conform to conventions or other minor tweaks.)
106+
107+
### Cargo and the library ecosystem
108+
109+
Earlier I wrote that Rust 1.0 is not so much an endpoint as it is a
110+
starting point. This is very true. The goal for Rust 1.0 is to be an
111+
flexible substrate for building efficient libraries -- but libraries
112+
aren't any good if nobody can find them or they are difficult to install.
113+
114+
Enter [Cargo, the Rust package manager](http://crates.io). Cargo has
115+
been undergoing rapid development lately and is already quite
116+
functional. By the time
117+
1.0 is released, we plan to also have a central repository up and
118+
wunning, meaning that it will be simple to create and distribute Rust
119+
libraries (which we call "crates"). Oh, and of course Cargo and its
120+
associated server are both written in Rust.
121+
122+
### Release process
123+
124+
Rust releases have been following a train schedule for a long time and
125+
we don't plan on changing that. Once we start having stable releases,
126+
however, we'll also build up a bit more infrastructure. Our plan is to
127+
adopt the "channel" system used by many other projects such as
128+
[Firefox](https://www.mozilla.org/en-US/firefox/channel/),
129+
[Chrome](http://www.chromium.org/getting-involved/dev-channel), and
130+
[Ember.js](http://emberjs.com/builds/).
131+
132+
The idea is that there are three channels: Nighly, Beta, and
133+
Release. The Nightly channel is what you use if you want the latest
134+
and greatest: it includes unstable features and libraries that may
135+
still change in backwards incompatible ways. Every six weeks, we cut a
136+
new branch and call it Beta. This branch excludes all the unstable
137+
bits, so you know that if you are using Beta or Release, your code
138+
will continue to compile. At the same time, the existing Beta branch
139+
is promoted to the Stable release. We expect that production users
140+
will prefer to test on the Beta branch and ship with the Stable
141+
branch. Testing on Beta ensures that we get some advanced notice if we
142+
accidentally break anything you are relying on.
143+
144+
With regard to the 1.0 release specifically, the plan is to release
145+
the 1.0 beta and then follow this same process to transition to the
146+
official 1.0 release. However, if we find a serious flaw in the
147+
1.0 beta, we may defer and run an additional beta period or two. After
148+
all, it's better to wait a bit longer than wind up committed to
149+
something broken.
150+
151+
### Looking forward
152+
153+
In many ways, Rust 1.0 is not so much an endpoint as it is a starting
154+
point. Naturally, we plan on continuing to develop Rust: we have a lot
155+
of features we want to add, many of which are already in the pipeline.
156+
But the work that's most exciting to me is not the work that will be
157+
done by the Rust team. Rather, I expect that having a stable base will
158+
allow the Rust community and ecosystem to grow much more rapidly than
159+
it already has. I can't wait to see what comes out of it.
160+
161+
[f]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0
162+
[k1]: https://github.com/charliesome/rustboot
163+
[k2]: https://github.com/jvns/puddle
164+
[k3]: https://github.com/pczarn/rustboot
165+
[k4]: https://github.com/ryanra/RustOS
166+
[stability]: http://doc.rust-lang.org/std/stability.html
167+
[dst]: https://github.com/rust-lang/rust/commit/7932b719ec2b65acfa8c3e74aad29346d47ee992
168+
[cd]: https://github.com/rust-lang/rfcs/blob/master/active/0044-closures.md
169+
[wc]: https://github.com/rust-lang/rfcs/pull/135
170+
[at]: https://github.com/rust-lang/rfcs/pull/195
171+
[gt]: https://github.com/rust-lang/rfcs/pull/230
172+

0 commit comments

Comments
 (0)
0