
Rust 0.8 released - steveklabnik
https://mail.mozilla.org/pipermail/rust-dev/2013-September/005804.html
======
chrismorgan
If you were wanting to use Rust but also wanted to use HTTP (client _or_
server), I've got [https://github.com/chris-morgan/rust-
http](https://github.com/chris-morgan/rust-http) which has rapidly become the
_de facto_ HTTP library (although it started after Rust 0.7 was released).
It's far from complete—but that's an opportunity for you to join in, if you
want.

~~~
erkose
"far from complete" and "de facto HTTP library" doesn't say much for rust.

~~~
chrismorgan
It's good enough that the Servo team decided to use its client (and now do),
but the approach I've taken (implementing the HTTP spec thoroughly, putting
Rust's type system to good use) will take quite a long time before it's
_really_ polished (e.g. we must implement types for every type of header,
rather than just using strings and leaving it to users to interpret them
[often incorrectly]). It's still a little experimental, but it's the only
really serious HTTP library there is for Rust out there.

Just wait until it's done. It will be a _really great_ HTTP library.

~~~
chamakits
I haven't taken a look at your library, but as a developer that has always
wondered "Why use strings for these things that could be enums, contants, or
types?" in API's, I appreciate your effort and your thoroughness.

~~~
mbreese
The answer is because that's what's in the spec. For HTTP, it's probably a
mistake to hardcode header types. They are defined as key/value pairs of
strings in the spec. There are a few keys that are specified, but how they
actually work in practice (upper? lower? quoted?) is difficult to predict.
There are just too many variations. So you end up with proper types for the
most common ones, and then throw the extras into a separate "others" type.
Which is great, except that now you have two places to check for things.

In this case (HTTP), it's easier (and more correct) to just leave them as
stings. The general principle with network protocols is to be strict in what
you send, and forgiving in what you receive.

~~~
chrismorgan
The headers are data, not text. Somewhere along the way you'll need to
interpret them; doing a good job of that at the system boundary is the only
_sensible_ approach. (It's not the approach the majority of tools have taken,
but it _is_ the only sensible approach). If it gets into the system as text,
people will start pulling it apart in even worse and less consistent ways.

I agree with you that the parse behaviour for HTTP headers is poorly defined.
That's something I'll be wrestling with all the time.

Supported headers will be in one place and uncommon extension headers in
another. Such, alas, is life. But really, the only time when I would expect
this to cause any trouble at all is when new headers are added. Compare it
with things like the CGI standard and how it handles headers and you'll
realise it's not such a bad system.

I should make it quite clear that the specs are (unfortunately) only a
starting point for rust-http. Where there are deviations, more leniency may be
added. But it'll be added thoroughly and properly.

------
devx
If they make their next-gen browser using Rust, I hope they make it 64-bit-
_only_ , and optimize it as much as possible for x64 and ARMv8. None of that
"support back to Windows XP!" stuff. It wouldn't be necessary (will still have
Firefox a few years longer for that), and it would just hold them back in
terms development time, maintenance, performance and security.

Then it would be not just great PR for their "highly-optimized no legacy cruft
64-bit browser", but would also give people a reason to switch from _Firefox_
to it. It would also give Mozilla an excuse to not make a 64-bit Firefox
anymore.

I assume it's going to take them at least 2-3 years to do it (if they ever
plan to release it), and by then Microsoft will probably release a 64-bit only
Windows 9, iOS will be 64-only, too (probably not relevant to Mozilla, but
could be in the future), and at least half of all Android smartphone users
will have ARMv8-based devices.

Mozilla should take full advantage of this, and really push for performance
(and security), and they should only make it available from Android 5.0
(probably the first 64-bit Android version) and Windows 7 x64. Support for
Linux kernel should probably start with no lower than 3.10 LTS (contains all
the ARMv8 support).

~~~
marshray
Note that Windows XP 64 bit was a thing. :-)

Very few of today's apps actually benefit from having more than 3GB of address
space. Nothing on my desktop PC is using more than 300MB at the moment. All
else being equal, 32 bits will be more efficient, particularly on portable
devices which tend to have far less memory bandwidth.

~~~
jfb
All other things are not equal, however.

~~~
marshray
True, there can be address space fragmentation issues on large 32-bit
processes.

What else did you have in mind?

~~~
Tuna-Fish
The extra registers and other advancements in instruction sets help a lot.

x86 has some enchancements, but if you think that 64-bit is bad for mobile, I
strongly suggest looking at the A7 32 vs 64 benchmarks. (
[http://anandtech.com/show/7335/the-
iphone-5s-review/4](http://anandtech.com/show/7335/the-iphone-5s-review/4) )

Of course, the performance gains have really nothing to do with 64-bit
addressing alone, but ARM took the opportunity to almost completely redesign
the ISA, and A64 is in general a better and faster ISA than A32. So all else
is not equal.

~~~
sanxiyn
I actually find this 64-bit-has-better-ISA-than-32-bit situation annoying. I
would like to have better ISA, without making pointers larger. There is
x32([https://sites.google.com/site/x32abi/](https://sites.google.com/site/x32abi/)),
will there be something similar for ARM?

------
mcpherrinm
Remember that Rust is still a rapidly changing language, and releases have
very little connotation of stability, support, or any other guarantees.

They're released on a schedule, not by features. They're useful to be able to
refer to periods of time in Rust's rapidly changing lifetime, but not much
beyond that.

~~~
ternaryoperator
This! I so want to play with Rust. I want to explore it over programs that are
several thousand lines long, so I can get a real flavor for it. But the rate
of change especially to important elements of the language is still too great.
I don't want to rewrite the code to stay abreast of revs.

Not a critique by any means--I admire the language and the work being done.
More of a wish that the core language syntax would settle down soon.

~~~
steveklabnik
To be clear, the syntax changes in this release were very minor. It's mostly
the standard library and runtime that are changing at this time.

That doesn't mean that your sentiment is wrong; if you don't want to be
keeping up with the langauge's changes, certainly don't write projects in
Rust. That said, there are more libraries than you'd expect, including a few
that are several thousands of lines.

~~~
dbaupp
_> To be clear, the syntax changes in this release were very minor_

Yeah, _only_ the _entire_ for loop syntax changed. ;)

~~~
steveklabnik
And it was fixable with a regular expression. :)

------
ww520
Rust is pretty good as a language but things are still changing a lot,
especially on the library side.

I did a project in Rust as a learning exercise. The language is easy to pick
and I was able to hit the ground running from the start. The major learning
hurdle I think is the memory model, which is different from most languages out
there.

Here's my first Rust project after two weeks of on and off hacking. It's a
Memcached client library implementing the Memcached protocols in pure Rust.
[https://github.com/williamw520/rustymem](https://github.com/williamw520/rustymem)

------
calinet6
I just want to note, if you ever release something (anything, be it a version
or a whole startup), copy their first paragraph intro! I didn't know what Rust
was, but after just 8 seconds I did. Fantastic and all too rare.

------
metajack
Release notes are here: [https://github.com/mozilla/rust/wiki/Doc-detailed-
release-no...](https://github.com/mozilla/rust/wiki/Doc-detailed-release-
notes)

------
glesica
I've messed around with Rust a little and I love what I see! The documentation
is still poor (understandable given how quickly the target is moving) but that
seems to be changing. This is a really exciting, multi-paradigm language and I
wish Mozilla all the best in developing it further!

~~~
steveklabnik
Ive been making it my mission to improve the docs, especially as the language
settles down.

Any suggestions welcome, here or via email.

~~~
saosebastiao
1) I think I've had 4 different people try to explain lifetimes to me and I
still don't think I understand.

2) The use of pointer dereferencing in closures is still quite confusing to
me. For example, from the tutorial:

    
    
      let square = |x: int| -> uint { (x * x) as uint };
    

no pointer dereferencing, yet:

    
    
      [1, 2, 3].map(|x| if *x > max { max = *x });
    

uses pointer dereferencing. I can't figure out any rhyme or reason behind it.

3) How do you create traits that can be automatically derived? How do you
implement a default method?

4) How do you create and use macros, and in what situations are they the
appropriate solution over other forms? (I'm used to using macros in lispy
languages, but using them as pervasively in other languages seems to be a form
of code smell).

~~~
pitterpatter
Maybe this will be useful to understanding lifetimes: [http://static.rust-
lang.org/doc/0.8/tutorial-borrowed-ptr.ht...](http://static.rust-
lang.org/doc/0.8/tutorial-borrowed-ptr.html)

As for the pointer dereferencing, perhaps putting the type there will make it
clearer:

    
    
        [1, 2, 3].map(|x: &int| if *x > max { max = *x });
    

Now you can see that x isn't actually an int but a reference to one.

As for automatically derived traits, those are actually slightly more powerful
macros implemented in the compiler itself. You can see it at
rust/src/libsyntax/ext/*.

For default methods, you just put the code you want in the trait itself. Like
so:

    
    
        trait Animal {
            fn sound(&self) -> ~str;
            fn make_sound(&self) {
                println(self.sound());
            }
        }
    

The make_sound method is what's called a default method. If you implemented
that trait, at the very least you would have to define the sound method and if
you wanted to, you could override the default make_sound method.

Macros are actually created with another macro called macro_rules. I'll defer
to the tutorial for them: [http://static.rust-lang.org/doc/0.8/tutorial-
macros.html](http://static.rust-lang.org/doc/0.8/tutorial-macros.html)

------
bjz_
Those interested in using Rust for game development can check out our list of
resources: [https://github.com/mozilla/rust/wiki/Computer-Graphics-
and-G...](https://github.com/mozilla/rust/wiki/Computer-Graphics-and-Game-
Development)

If you want to chat feel free to stop by `#rust-gamedev` on irc.mozilla.org.
We're very nice!

~~~
dbaupp
There's also #rust and #servo on the same server. _We_ 're very _very_ nice!

------
continuations
Is there an actively developed web framework for Rust, kind of like Revel for
Go?

I have a toy web project I'm starting. Would love to play with Rust.

~~~
steveklabnik
Not yet. As chrismorgan points out above, the http library is still being
developed, once it's more stable, web frameworks can be built on top of that.

~~~
zokier
Wouldn't web frameworks be using something like fastcgi rather than raw http?

~~~
chrismorgan
Why? FastCGI is slow. Controlling the entire HTTP stack is fast, and makes
deployment much easier (only one piece of software to configure, not two or
three).

------
portmanteaufu
Congrats on all the progress, guys! I'm really looking forward to getting to
work with Rust. I have a couple of questions:

Is the new fixed-stack FFI arrangement the end goal, or is it a stepping stone
to a different system? It seems as though always using a big, fixed stack
would cause performance/memory issues. Could the compiler detect which Rust
fn's call extern "C" functions so I don't have to write annotations? Thanks!

~~~
kibwen
Fixed-stack is not the end goal. The intent is to migrate back towards small,
growable stacks.

There were long discussions over how "smart" the extern stack-size strategy
should be. The current arrangement is, as ever, a compromise. In practice,
most people writing bindings to C from Rust will wrap the C call into a very
thin wrapper function whose job is to handle type conversions and managing the
necessary `unsafe` bits. The hope is that putting the annotation on these
wrapper functions won't be very onerous, with the result that any Rust code
that calls the wrapper functions won't ever have to bothered with remembering
the annotations.

~~~
portmanteaufu
Makes sense, thanks! As an outsider it can be tricky to know which things in
the release notes are "This feature is ready" vs "This is simply the present
state of things."

~~~
steveklabnik
Rust is basically entirely 'this is simply the present state of things.' :)

~~~
chrismorgan
Plus there's also rather a lot of non-codified knowledge about what's
happening and going to happen. But if you pay much attention to the mailing
list and stay in #rust you'll pick up an awful lot of it.

~~~
dbaupp
(Also, TWiR: [http://cmr.github.io/blog/categories/this-week-in-
rust/](http://cmr.github.io/blog/categories/this-week-in-rust/))

------
saosebastiao
Anybody know when there will be a regex library?

~~~
zokier
rust has relatively nice FFI, so I suspect using PCRE shouldn't be too
difficult.

~~~
skorgu
Or re2 [0]

[0] [https://code.google.com/p/re2/](https://code.google.com/p/re2/)

------
pjmlp
Congratulations!

When will we be able to compile Rust using a standard LLVM instalation,
instead of compiling LLVM with it?

My poor netbook takes almost 3 hours to compile it. :(

------
dodyg
What do people use for editing Rust source code?

~~~
steveklabnik
We have syntax files for vim, emacs, kate, gedit.
[https://github.com/mozilla/rust/tree/929b75e220f6fced42dcfe2...](https://github.com/mozilla/rust/tree/929b75e220f6fced42dcfe2146700ceba1e2cebe/src/etc)

