
Rust 0.9 released - kibwen
https://mail.mozilla.org/pipermail/rust-dev/2014-January/007753.html
======
copx
Wasn't this release supposed to finally offer a Windows package which works
out-of-the-box?

I just tried it. Only got an error message about a missing GCC component.
Seriously, a ~90MB download and that still does not include all the GCC
dependencies?

We still have to somehow manually setup a version of MinGW compatible with
this particular build? Who is in charge of the Windows port? A Linux user who
cross-compiles from an Arch box? No way a Windows user would think that
Windows package is acceptable.

I mean, I am not paying anything for it so it is not that I think I have the
right to demand better packages but you are losing out on a massive amount of
feedback from the Windows world by only offering such downloads.

You are largely limiting yourself to determined people who are already
familiar with MinGW-based C/C++ development on Windows (that is a _small_
subset of Windows devs). What about people coming from - say C#? You expect
them to fiddle with a MinGW setup just to build "Hello World"?

Sorry, but for me this experiment with Rust ended just like the 0.8 one.
Downloaded Windows installer, ran Windows installer, tried to compile Hello
World, got error message about missing components, uninstall, delete.

~~~
kibwen

      > Wasn't this release supposed to finally offer a Windows 
      > package which works out-of-the-box?
    

Nope! No idea where you got that impression.

    
    
      > Who is in charge of the Windows port?
    

We keep asking for people knowledgeable about Windows to step forward and lead
the effort to port us off MinGW and onto MSVC, and none ever have. Would you
like to volunteer? :)

To clarify, the _goal_ is to be using the native Windows toolchain by 1.0, if
at all feasible. Servo has to work on Windows, after all.

~~~
st2p
I just started looking at Rust and like what I see so far. I may be able to
help; I worked on the Windows port of Go and put together the MinGW build
environments as well as the binary installers.

If someone can point me to a list of outstanding issues/requirements and a
contact person it'd be much appreciated. Note, I've already found this
[https://github.com/mozilla/rust/issues/8996](https://github.com/mozilla/rust/issues/8996)
and this
[https://github.com/mozilla/rust/issues/1237](https://github.com/mozilla/rust/issues/1237).

I'm assuming the workflow notes at
[https://github.com/mozilla/rust/wiki/Notes](https://github.com/mozilla/rust/wiki/Notes)
are up to date?

~~~
dbaupp
I personally don't know what's necessary now, but if you feel like joining
#rust or #rust-internals on irc.mozilla.org (which I recommend :) ), then
vadimcn and klutzy are the people to talk to. (IRC handles match their GitHub
names.)

~~~
st2p
...doing it now.

------
kibwen
A selection of some of my favorite aspects of this release:

1\. The (yet-ongoing) removal of managed pointers, leaving us with one fewer
pointer type. Final tally of built-in pointer types: unique pointers, mutable
references, and immutable references.

2\. The dead code detection pass
([https://github.com/mozilla/rust/pull/10477](https://github.com/mozilla/rust/pull/10477)),
contributed by a student of the University of Virginia's Rust-based systems
programming class ([http://rust-class.org/pages/using-rust-for-an-
undergraduate-...](http://rust-class.org/pages/using-rust-for-an-
undergraduate-os-course.html)).

3\. The `Any` trait, giving us on-demand dynamic typing
([https://github.com/mozilla/rust/pull/9967](https://github.com/mozilla/rust/pull/9967)).

4\. The clean abstraction of green threads and native threads out into their
own libraries ([https://mail.mozilla.org/pipermail/rust-
dev/2013-December/00...](https://mail.mozilla.org/pipermail/rust-
dev/2013-December/007565.html)) such that any library that makes use of the
stdlib will work regardless of which strategy the user selects.

We're not quite in the home stretch yet, but there are very few hard blockers
left on 1.0. Here's the list that I can think of:

1\. Dynamically-sized types
([http://smallcultfollowing.com/babysteps/blog/2014/01/05/dst-...](http://smallcultfollowing.com/babysteps/blog/2014/01/05/dst-
take-5/))

2\. The extension of rvalue lifetimes
([http://smallcultfollowing.com/babysteps/blog/2014/01/09/rval...](http://smallcultfollowing.com/babysteps/blog/2014/01/09/rvalue-
lifetimes-in-rust/))

3\. Struct single (note that's _single_ ) inheritance
([http://smallcultfollowing.com/babysteps/blog/2013/10/24/sing...](http://smallcultfollowing.com/babysteps/blog/2013/10/24/single-
inheritance/))

4\. Niceties and sugar to support custom smart pointer types to complete the
excision of managed pointers

As far as I know, the devs are still aiming for a 1.0 release in 2014. The 1.0
release will _not_ necessarily mean that the language is done evolving or
ready for production use, but it _will_ mean that the developers will begin
honoring language-level and library-level backwards compatibility. I would
expect _at least_ two more unstable point releases (i.e. 0.10 and 0.11) before
a 1.0 release occurs.

~~~
pcwalton
Inheritance may not make 1.0.

~~~
Ycros
I'm finding that my OO code style these days is very composition heavy with
pretty much no inheritance use. I think given Rust's type system, I'm not
going to miss inheritance much.

~~~
eridius
I believe Rust wants inheritance primarily for Servo, because the DOM is
defined in terms of inheritance.

~~~
jeltz
If that is the only use case I would rather want another solution to keep the
language minimal. Just like the garbage collection was moved to a library.

~~~
pcwalton
Can't really do it. I tried. The type checker just plain has to know about
inheritance for it to work and be safe.

The good news is that's an extremely constrained sort of inheritance, very
unlike traditional OO in that it doesn't have base classes--it's just a
special extension to the trait (typeclass) system that allows you to require
that structs begin with a certain set of fields. In fact, I don't even call it
inheritance these days--I prefer the name "structural constraints".

~~~
carterschonwald
ooh, is this like record subtyping? Have you seen ermine
[https://github.com/ermine-language](https://github.com/ermine-language) or
Ur/web? [http://www.impredicative.com/ur/](http://www.impredicative.com/ur/)

[edit, on #rust it was explained to me that its only for pointers to structs,
but thats fine by me]

~~~
dbaupp
If anyone is interested, the proposal for Rust is detailed in
[http://smallcultfollowing.com/babysteps/blog/2013/10/24/sing...](http://smallcultfollowing.com/babysteps/blog/2013/10/24/single-
inheritance/)

------
bjz_
As always, drop by irc.mozilla.org #rust if you'd like to chat or ask
questions. We're a friendly bunch!

[http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23ru...](http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23rust)

------
rybosome
I really want Rust to succeed, but I'm not a systems programmer. Do people
feel that there is still a place for Rust among those who typically work with
higher-level languages? The functional aspects and type system of Rust look
really appealing, and I'd love to do my part to help it do well by actually
using it.

~~~
kibwen
I was exclusively a Javascript/Python/Java programmer before jumping into
Rust. If you're looking to learn a systems language with real bare-metal
capabilities, Rust's safety features will go a long way towards keeping you on
the straight and narrow as you figure out the concepts essential to low-level
programming.

And because Steve seems reluctant to plug his own book, here's Rust for
Rubyists, which is an introduction to Rust geared towards users of higher-
level programming languages:
[http://www.rustforrubyists.com/](http://www.rustforrubyists.com/)

~~~
steveklabnik
This reminded me that I needed to actually release the 0.9 update I wrote over
the weekend! Thanks :)

~~~
arms
Thanks kibwen for the link, and thanks steveklabnik for writing this. I've
been interested in Rust and this looks like a nice way to get my feet wet.

~~~
steveklabnik
You're welcome! Feedback appreciated.

------
saurabhnanda
I'vr been 'stalking' Rust for quite some time, but never got around to diving
in. I'm essentially a web programer who's been building fairly large web based
systems. I'm sick of dealing with programming languages that consume shitloads
of resources (CPU, memory, whatever) for doing essentially trivial stuff
(compared to the amount of resources they use).

Will Rust be able to help me write super-efficient web programs, than run
blazingly fast and dont gobble-up RAM?

Besides, how painful/easy is string manipulation in Rust?

~~~
kibwen
Yes, Rust will super-efficient, blazingly-fast, and memory-lean. But it's not
nearly as good at rapid prototyping as, say, Ruby, so you'll have to temper
your expectations.

String manipulation in Rust is currently lacking while we work on the API. We
also strictly enforce that all strings are UTF-8, so while this gives us great
confidence that we're future-proof it adds a whole lot of difficulty in
implementing a fast and correct means to work with strings.

~~~
saurabhnanda
Can you elaborate why UTF-8 makes things harder? Is it because 1-byte no
longer means one character? So, something like calculating a string's length
is also tricky. Is that it?

Also, where can I read about the general direction the string manipulation API
is going to take?

~~~
kibwen
The bigger problem is that Unicode is immense and complex, and trying to
implement the full specification is rather daunting.

There's no real documents concerning the future of the string API, right now
people are just implementing things as they need them.

------
saosebastiao
So is the next milestone 1.0 or 0.10?

~~~
steveklabnik
0.10

~~~
babo
with finalized pointers?

~~~
steveklabnik
What do you mean?

~~~
babo
These deep changes with pointers holds me back to try out rust. Last I checked
rust was a week ago, none of the pointer related documentation or examples
were compatible with the head revision. Putting energy of the released version
felt bad as that will break soon but head is not that useful without
documentation. The same goes since summer, I'm looking for a stable codebase
with documentation and base libraries.

~~~
jvns
If you're looking for a stable language you shouldn't use Rust right now. The
language is still changing every few days.

If you have a bit more time to spend it's fun, though -- I spent a lot of time
in the IRC channel. The people in #rust are really helpful and will answer all
your pointer questions.

------
vorg
> normalized to Unicode normalization form NFKC

I'm wondering why they chose NFKC (compatibility composed from) instead of NFC
(canonically composed form).

`ª` would become `a`, losing its _super_ type. `ᵤ` becomes `u`, losing its
_sub_ type? `Ⓐ` becomes `A`, losing its _circle_ type. As for multi-codepoint
mappings, `¼` would become three tokens `1⁄4`, where `⁄` (U+2044) _doesn 't_
map to `/` (U+002F).

~~~
lifthrasiir
Maybe you are referring the reference [1], which indeed mentions NFKC. As far
as I know there is no consensus of the normalization form [2] and the current
implementation is not guaranteed to stay, which is why Unicode identifiers are
gated behind a `#[feature]` flag.

[1] [http://static.rust-lang.org/doc/0.9/rust.html#input-
format](http://static.rust-lang.org/doc/0.9/rust.html#input-format)

[2]
[https://github.com/mozilla/rust/issues/2253](https://github.com/mozilla/rust/issues/2253)

~~~
vorg
Yes, I started reading the reference. The normalization form issue is
different to the #[non_ascii_idents] feature, though.

The issue 2253 does mention address it, but all the comments mention the issue
of NFC/NFKC normalization specifically for filesystem lookup and for program
identifiers, but not for the lexing stage. That issue is obviously the best
place to continue any conversation about it.

------
bencollier49
Rust does seem to do lots of good and interesting stuff. I was trying to find
a small number of languages covering all paradigms, and Rust featured on the
final list:

[https://news.ycombinator.com/item?id=7026970](https://news.ycombinator.com/item?id=7026970)

------
eonil
Of course I welcome removal of GC syntax, but I am getting in doubt on when
Rust language specification can be stabilized. Version 0.9 seems it must be
stable now, but they're still putting big changes on the language.

~~~
panzi
In general: One cannot expect a 0.x version to be stable/won't be followed by
a incompatible version. A 1.x version is a different story.

~~~
Pacabel
Well, it's understandable where the concern is coming from. We've seen 0.x
releases of Rust for nearly two full years now, and even the most recent ones
have had significant changes. While we've heard that a 1.0 release is planned
for sometime during 2014, there's little to suggest that things are actually
stabilizing. It isn't Perl 6 yet, but the ongoing lack of stability is making
some potential Rust users become skeptical.

~~~
pcwalton
There have been fewer and fewer breaking language changes over time. The
migration from 0.8 to 0.9 was less of a burden than the migration from 0.7 to
0.8, and so on. There is also a lot of progress on making a list of blocking
issues, and at this point if anything can be added backwards compatibly it is
almost always not a priority for 1.0.

Making a safe programming language that doesn't require GC or a runtime (while
allowing allocation) has literally never been done before in industry. It has
taken time to get something usable. The current overall design seems pretty
workable now, as evidenced by all the projects people are starting to write,
so I think it's basically just a matter of finishing off rough edges at this
point.

~~~
steveklabnik
If anyone's curious, here's all it took me to update Rust for Rubyists from
0.8 to 0.9:
[https://github.com/steveklabnik/rust_for_rubyists/commit/ae2...](https://github.com/steveklabnik/rust_for_rubyists/commit/ae27bcfc349450e3491e420c71f93357fb4c0f6d)

~~~
mitchty
Thats actually a lot less than i'd expect.

Kinda curious on the do N.times -> for foo in range(0, N) changes. I thought I
remember a recent post from you about that. Any reason for the switch? (I ask
as someone thats used ruby too much myself and is currently switching cold
turkey to plain old C while rust gets a bit more mature)

~~~
lifthrasiir
It's since `do` now does not apply to stack closures [1]. `Do` still supports
owned closures (that's what used to be called `~once fn()` in 0.8 and renamed
to `proc()`) but they can be called only once which defeats the whole point of
`times` (unless you are fine with `N.times(|| { ... })` syntax).

[1]
[https://github.com/mozilla/rust/issues/10815](https://github.com/mozilla/rust/issues/10815)

~~~
mitchty
Very interesting thanks!

------
tarpden
Are there any plans to further simplify and/or pare down the language?

~~~
dbaupp
Yes, the @ built-in pointer is being removed as special, replaced by library
types like Rc and Gc (for reference counting and garbage collection
respectively). There's a vague suggestion for ~ to become a library pointer
too, but I don't think this has been totally accepted by the core team. (This
would leave only raw pointers and references actually defined in the
language.)

There are some plans related to simplifying how vectors and trait objects
("dynamically sized types" or DST) interact but I don't understand them well
enough to be able to explain. :)

------
Dewie
OT: Is Rust using operator overloading? Is user-defined operators a
possibility in the future? I googled it and the most I could find was this:

[http://www.reddit.com/r/rust/comments/1le6vu/i_wrote_a_proto...](http://www.reddit.com/r/rust/comments/1le6vu/i_wrote_a_prototype_parser_combinator_in_rust_and/cbyh50y)

~~~
kibwen
Operator overloading, yes. But we place some restrictions on which types you
can overload in order to keep things sane (oversimplified explanation: you
must have declared the types yourself in order to overload operators on them).
We also discourage the wanton overloading of operators to mean completely
random things, as you might have encountered in C++.

As for user-defined operators, if you mean something like Haskell's custom
infix operators then no, I don't believe there are any plans for those.

~~~
JoshTriplett
> As for user-defined operators, if you mean something like Haskell's custom
> infix operators then no, I don't believe there are any plans for those.

Do the Rust designers actively oppose having them, or just not have any
concrete plans to add them?

~~~
kibwen
Merely lukewarm, I think. There are simply much higher priorities to focus on
at the moment. Who knows what Rust 2.0 might hold!

~~~
pnathan
I've always found the profusion of infix operators in Haskell to be heinously
confusing, and seriously degrades readability and usability of
libraries.limits on the o

~~~
Dewie
The problems I see with infix operators are:

\- It's not necessarily obvious what is an infix operator

\- Precedence and associativity

I think Haskell has solved the first one: with all non-alphanumeric symbols in
expressions being infix operators, and likewise for alphanumeric functions
written with backticks.

But precedence and associativity is not obvious, since that is something that
you can customize. I think that user-defined infix operators with some severe
limits on choosing precedence and associativity is a good compromise (many use
backticks on functions in Haskell, and that has a default precedence).

