Just wait until it's done. It will be a really great HTTP library.

For example, last week as a learning exercise I implemented an OAuth client, which involves adding a bunch of stuff to the "Authorization" header of an HTTP request, none of which was ever mentioned in the original HTTP RFCs, let alone specified. Likewise, the HTTP RFCs have a fixed and rather small set of verbs, but things like DAV add a bunch more.

How can you balance the reliability of strict typing with all the HTTP extensions that expect anyone can stick arbitrary strings anywhere?

Taking your example of the Authorization header: that uses the `credentials` type, defined in RFC 2617 (https://tools.ietf.org/html/rfc2617), which ends up thus:

      auth-scheme    = token
      auth-param     = token "=" ( token | quoted-string )
      credentials = auth-scheme #auth-param

    struct Credentials {
        scheme: ~str,
        parameters: ~[(~str, ~str)],
    }

    enum Credentials {
        BasicCredentials(BasicCredentials),  // A new struct
        DigestCredentials(DigestCredentials),  // Ditto
        ExtensionCredentials(ExtensionCredentials),
    }

In the end, it is all about balance, as you say, and I'm not sure precisely where the balance falls, yet. But I know it uses the type system a whole lot more than almost all of the code that's out there.

That follows through to many other aspects of e.g. web frameworks; there's a lot there where string typing is used. When rust-http is stable enough, I'll be getting on to my dream framework which will be astonishingly safe and bamboozlingly quick (to start and to run, if not quite to compile), incorporating and extending various ideas at present only present in Haskell frameworks and a couple of other similar language-frameworks (e.g. Ur/Web). It'll be fun!

I've been mostly a Python developer hitherto, but I'd never have tried something like this in Python—it simply wouldn't work. You need a type system like Rust's before it can work, but then it really works.

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.

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.

For example, https://github.com/spray/spray/blob/master/spray-http/src/ma...

My own header definitions are pretty clumsy at present; I'm just about up to the stage of improving that with macros now. (I didn't do that to start with so that I could write a few and get a feel for what it would need to be like.)

As I get further along, I intend to use the data from the Common Crawl, which fortuitously includes response headers, to see how my validation goes. Of course, that's only a small set of the real-world headers (cache ones in particular will be scarcely stressed by that at all). Validating request headers will be harder; I've still got to figure out what to do about that.

In the end, though, I'm determined that it will work and work well. Servo using it (and thus demanding robust HTTP support) will help with that goal.

Something I discovered a few hours ago, reading the specs: I believe this header should be valid, with the value being interpreted as the weak entity tag ``Super Encoding™``. I wonder how many clients or servers would support it? No idea yet.

    etag: w/"=?US-ASCII?B?U3VwZXIg?= =?UTF-8?Q?Encoding=E2=84=A2?="

Arbitrary string headers are essential. Conversion between the typed header and strings is part of the design (though only partially implemented at present). As for other extension-headers (as they are designated in RFC 2616), that's the header enum variant ExtensionHeader(~str, ~str).

It's been so long since I've played with netcat and HTTP that I can't remember if 'get' vs 'GET' "used to" work or not...

Still, might be something that should be possible to toggle with a flag (case insensitive parsing on/off or something like that).

Might also be useful to keep in mind that there are very real differences between HTTP/1.0 and HTTP/1.1. For browser-facing stuff, 1.1 should be fine these days(?) -- for apis etc, I don't know if "proper" 1.0 support makes sense or not.

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).

The extra parallelism we're after also enables new things too. For example, Servo runs cross-origin and sandboxed iframes in parallel.

And this: http://people.mozilla.org/~roc/Samsung/MozillaRustAndServo.p...

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.

What else did you have in mind?

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 )

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.

mmapping files without blowing out your address space works a lot better in a 64-bit process (and system libraries love to mmap things like fonts, which can quickly take up a bunch of address space).

I just took a look at the address space usage on my Mac, and the spotlight indexer seems to be using about 1.5GB of address space (and 350MB of actual RAM, for some reason?), and a number of other built-in things (WindowServer, Apple80211Agent, Dashboard) are all north of the 500MB address space mark.

But I think most stuff that runs off of soldered-on DDR3L and flash RAM (e.g., apps on phone and tablet OSes) may be better off sticking with 32 bit addresses for another generation.

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.

Specifically, maturity #5 - production ready: https://github.com/mozilla/rust/issues?milestone=16&state=op...

  > The purpose of this milestone is to represent a high degree of confidence the
  > language's suitability for industrial use due to a high level of measured
  > correctness and performance in the tests.
  
  > In other words, for each of the aspects described in the "well covered"
  > milestone, and for each supported target platform, test success and benchmark
  > performance has reached a level deemed suitable for production use in
  > environments with substantial business consequences for major defects or low
  > performance. Where possible, performance benchmarks are linked to equivalent
  > benchmarks in competitive languages, and rust is sufficiently close to
  > equivalent in performance.

    > maturity #2 - backwards compatible
    > we are comfortable making a long-term support commitment to downstream
    > users (servo in particular) to keep the set of symbols, definitions
    > and passing-tests from contracting

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.

In this regard it couldn't be a better time to try it out.

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.

Yeah, only the entire for loop syntax changed. ;)

I wouldn't devote a crucial project, school assignment, or startup to rust. But for some toy side projects, or small programs, it's not so bad right now.

It is of course not mandatory, and won't really be used to distribute binary versions of Rust programs, just the source.

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

Any suggestions welcome, here or via email.

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 };

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

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).

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 });

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());
        }
    }

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

I would say to follow a Lisp rule, I like to follow in all languages that have macro support, "only implement a macro if it cannot be done with a function".

Would be great if the docs just linked straight to the function/crate in github.

(That feature has yet to be ported to the Rust port of the HTML generator though.)

Example: http://www.contrib.andrew.cmu.edu/~acrichto/doc/std/from_str...

- https://github.com/Florob/RustyXML

- http://fantom.org/doc/xml/index.html

Once that is finished, I might come and help on the Core/Servo. I just don't think I'd be much of a help if I don't use/know Rust/C++ very well.

Yeah it's been very smooth sailing :) Only pain point was @ pointers in BytesReader interface, but aside from that it's way less bumpy than anticipated.

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

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

Of course, if someone wants, they can totally do something via FastCGI too.

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!

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.

If you want to try working on it yourself, come join the community! You'll get lots of help with it when you need it.

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

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. :(