brson

'lang item' does roughly mean symbol, but they have their own Rust syntax to communicate their existence to the compiler. Lang items are special functions / types that can only be defined once globally, must be defined for certain features to work. They are how the standard library hooks into the Rust language for a variety of purposes, and to a large extent what makes it possible for Rust to define much of its functionality in libraries instead of in the language.

The two lang items that are absolutely required but not defined in core are 'eh_personality' and 'panic_fmt'. Read more here: http://doc.rust-lang.org/nightly/book/no-stdlib.html

I will be amazed if true! Last time I looked at the emscripten-Rust stack it was a tower of hacks and required a custom-hacked standard library. If that's all abstracted behind cargo build scripts that's awesome, but we're still a ways from having this be elegantly integrated into the Rust system.

It's going to improve rapidly though.

In Servo, DOM nodes are Rust values managed entirely by the SpiderMonkey GC, and clever (and evolving) techniques are used to teach Rust to integrate reliably with SpiderMonkey. Rust has the flexibility (or will) to safely integrate external GC systems.

No, this isn't an implementation of Aaron's thesis (reagents [1]). It's an implementation of Keir Fraser's thesis :) [2]

[1]: http://www.mpi-sws.org/~turon/turon-thesis.pdf

[2]: https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf

OK, imagine...

You run a single command to instantiate a family of cross-platform Cargo projects, one your platform-agnostic backend, and one for each of your target platforms: Linux, Windows, Mac, Android, iOS, of course, but also the entire impending IoT down to the smallest real-time device. Your platform-specific projects come with safe Rust bindings to the system platform (ala Xamarin).

Another single command builds and tests this from a single host system on an armada of virtual machines, emulators and cloud systems. Your tests run on a wide variety of standardized machine images, including those used for upstream Rust's own integration testing.

Another single command packages this for various Linuxes and app stores, deploys to your devices and cloud services.

Three commands, total world domination :)

It's going to happen, and it's going to be glorious!

At the moment we are using 60 r3.xlarge spot instances each running a single build at a time, and as of a few weeks ago it took maybe two hours. It hasn't been optimized.

There is no web dashboard yet (the website[1] - which runs Rust! - is quite minimal), but it's coming.

[1]: https://crater.rust-lang.org/

I am serious, but as you observed I also did not quite address your specific use case. Rust as-is with it's LLVM backend and lack of runtime has a clear path forward for anything LLVM can target (which is a lot now, and will be more in the future). This should get us into many platforms.

The compile-to-C case is the most straightforward of the three you mention, but also the one I'm most skeptical of. I do understand that there are some venerable old and/or small platforms where C is the only option. I don't know any specific examples of what people want to do by transpiling to C though. The only thing I know with any certainty is '8-bit microcontrollers', and this is one case that Rust is likely to be a tough fit for (largely because it wants pointer-sized things to be 'big enough', as well as other reasons I've forgotten).

Still, if it's necessary, it can be done with great effort (see the perennially broken LLVM C backend), but it's very low priority as of now.

I'm not sure yet the role of a JVM/.NET backend for Rust (besides the coolness factor) and I don't think people have put a great deal of thought into it. What we will have though is easy ways to bridge between the managed runtimes and Rust for accelerating your managed code or binding to system APIs. This will be necessary for creating decent Android/Windows environments.

(On the .NET topic a MSIL backend would also get us non-asm.js JS via [JSIL](http://www.jsil.org/) which would give Rust access to the DOM. This is quite a flight of fancy though).

This will happen. Rust is going to be the language that runs everywhere, easily, and interops with everything. In the next year or two Rust devs will be able to easily build and test for Linux, Windows, Android, OS X, iOS, and asm.js/webasm from a single unified toolset.

I've heard progress on this front recently (it's mostly about the automation infrastructure), and I might expect official nightlies of both rustc and cargo for FreeBSD by the end of summer.

Don't hold me to that.

MSVC support primarily means that Rust programs link with the MSVC toolchain, and use structured exception handling for unwinding. There are no GNU components involved and no need to install MinGW.

This uses a pure-Rust regex engine[1] by Andrew Gallant.

[1]: https://github.com/rust-lang/regex

You are right that process sandboxing is not as important for Servo, but it is important: 1) more defenses are more better, 2) Servo contains considerable amounts of C and C++ code and will for some time, 3) Even safe Rust has failure modes that can abort the process (primarily out-of-stack), and multiprocess provides recovery for when they happen.

This comment inspired me to write this utility: https://github.com/brson/rustle

It installs Cargo applications without requiring an existing Rust install. Instructions for installing exa are on the README.

Since I wrote it in a few hours, using it may set your hard drive on fire.

> The claim about being able to do "so much more at a low level", like e.g. being able to switch out libc variants, which allegedly is not possible in Rust due to accidental coupling. Is this a temporary difference? If so, it may only be relevant in the short term. I can't answer this question, but it would be interesting if someone did.

It's definitely intended that the Rust standard library can compile against many libc's. I personally hope that it can eventually be completely self contained and not even link to libc in certain configurations.

You are right that there are risks in making big changes at this stage, but my understanding is that the I/O redesign is not as radical as it would seem, and it resolves long-standing issues.

There has been a lot of churn recently it's true - more than ever - but much of this activity is directly motivated by making these kinds of commitments. The changes you are seeing now are the culmination of years of iteration and we really do think we're on the home stretch. If we can live with these APIs for a release cycle or two we'll have a good deal of confidence.

Frankly it would be better not to cut it this close, but Rust 1.0 is going to be a great foundation that we can commit to. There will be mistakes and misdesigns that we will have to live with but that is true for all languages.

I too think that the culture and community of the Rust project is special and am always heartened to hear others agree. Whatever happens with Rust 1.0 it's going to be something for a lot of people to be proud of.

The Mozilla committer agreement is not a CLA as I understand the term - it does not assign copyright to Mozilla, copyright is retained by the original author. The purpose of the document is to assert that those contributing code have the legal authority to do so. In Rust's case, those with review power are the gatekeepers responsible for ensuring the provenance of the code.

Rust does not require a CLA.

And this patch fixes on mac: https://github.com/mozilla/servo/pull/2687

And, reverted: https://github.com/mozilla/servo/pull/2685. Broken on mac. Maybe next week...

The other replies explained the situation, but for the curious here's Rust's basic code for slice iteration: https://github.com/rust-lang/rust/blob/master/src/libcore/sl... (unfortunately buried in some macros). `if self.ptr == self.end` is where the guarantee is made, then the offsets are done unsafely. The other branch in that function is optimized away statically.

Not to dismiss the importance of language stability, but forward porting in Rust should be significantly easier than Ruby for a few reasons:

* Rust's strong type system means the pieces fit together only in specific ways - roughly, if you can get it to compile again it will work; in more dynamic languages you have little confidence that the code works until runtime.

* Co-evolving the language with the downstream community is such a critical issue that Rust is developing several tools and processes to help, and this should set it apart from other open source languages that have gone down this path:

The Rust process already attempts to tag all breaking changes in the commit log with `[breaking-change]` and we've heard anecdotally that this has made forward-porting Servo much easier. This log isn't published anywhere besides the commit log yet, but it will be.

Secondly, Rust has a [stability](http://doc.rust-lang.org/rust.html#stability) system that tracks API stability at a fine level. This is influenced by node.js, but in Rust stability is detected and use of unstable API's can be enforced by the tooling. This is still in development but you can see it in the [docs](http://doc.rust-lang.org/std/intrinsics/).

You don't gain much at that point, and that's the aim: a process that allows the best libraries to smoothly progress from community projects to official components, without any major disruptive events along the way.

In fairness though, it's very unlikely that Rust will be distributing an official HTTP library by 1.0 - it's a big, difficult, library, the type which deserves to prove itself in for awhile before settling on. For these types of libs my planned trajectory is to integrate with Servo, make them installable via the package manager, let them stew in the wild until we're confident, then 'flip a switch' and declare them official.

It depends on what your production needs are, and how much of the gaps are filled in by unofficial libraries in the meantime (e.g. there are Rust crypto libraries, but none that are officially endorsed). Production-readiness comes in degrees, especially for a community project like Rust that has a relatively small paid team.

Although the internationalization story looks pretty bad, I'm heartened by my firm impression that no language does it well, that serious apps (like Firefox) tend to roll their own. One of our driving philosophies in Rust is to get actual production quality subsystems into the standard library by proving them in applications like Servo.

And FWIW here's the research presentation Tucker gave while he was at Moco about his new language Parasail: https://air.mozilla.org/region-based-storage-management-para...

We've talked to Tucker Taft about Ada and Rust before, though it was a while ago and I mostly recall that we discussed aspects of Ada's standardization process (I think Graydon was a fan of Ada's spec). Niko would probably remember more.

John Regehr gave a presentation to the Bay Area Rust user's group recently about his work. Since then we've started applying C-Reduce to Rust bugs and it has been working surprisingly well. If you've got a curly-brace language then give it a try.

I could have put some more thought into this response.

As Rust becomes more popular while we try to bring home the last few major changes, we've had this problem a few times, where the broader community is surprised and partially shocked and disappointed at a change that has been brewing for a while.

Certainly, more effort could be put into messaging and explaining how big changes are going to effect users. Figuring out how much, and what sort of, messaging is sufficient is not easy, and somebody is always going to find something objectionable about nearly everything. Additionally, Rust is still in an alpha state, in heavy development. The project is not in production mode yet.

We're always learning from mistakes and evolving the process.

Finally, Rust is in the home stretch. In some sense, we're at a stage where we need to hurry up and just get it done, at the expense of some community fallout along the way. If Rust is good, the ill will from the churn will be forgotten in time; if Rust is bad it will die. With the attention Rust is attracting, community momentum wants Rust to stop changing, but Rust must change a bit more. Rust needs to get to a point where the design can be justified and maintained for years to come, before its own popularity forces it to slow down.

The OP is, in fact, that document. You'll notice this in a pull request to Rust's RFC repo. This change has been prominently brewing in the Rust community for a long time. The fact is that people have strong opinions about Rust and this is a critical time in its development - people are going to complain.