Sorry about the slow reply. We're using a mix of Precise/Trusty[1]; we're not (presently!) using Rust in a production setting, I'm only using it to experiment currently, but it's still something outside the package manager that _if_ I wanted[5] would apply (and it's tempting…), so I decided to mention it. I'm presently using it to parse an internal file format we have, mostly as a project (one of two) to teach me Rust. (I'm using Rust presently on Trusty & Gentoo presently, both using the binary downloads from the website. I tried brew-installing it on OS X, but that doesn't give me cargo; haven't tried again in a few weeks, and haven't filed an issue…)

While it isn't presently in a production setting, I would be completely willing to put it into production. There are some spots where we need more performance than Python can offer, and the memory safety and good static typing are very appealing (I'm vary wary of memory-unsafe languages anywhere near the path of user input…). (I personally use C++ presently here, but the included gcc in Precise/Trusty IIRC lacks some of the more modern C++11/14 stuff, so heavy use of Boost is needed. Also, some third party libs — mongo, to name one — have less than elegant C++ interfaces…) The Rust standard library has made great strides in the few months since I started using it (I started picking it up in December?), and since my normal work is in Python, the static typing is a very welcome change. I'm still wrapping my head around lifetimes[2][3], regex! tripped me up a bit[4]. I found some iterator based functions — such as zip — odd: it's a member function on the Iterator trait, and only allows two args. I find Python's free-standing zip function which takes any number of iterables much more natural. Compare Python:

zip(a, b, c, d)

to my understanding of Rust:

a.zip(b).zip(c).zip(d)

I also wonder (since I've not tried it) what effect this has on unpacking. Instead of (a_item, b_i, c_i, d_i) being the items of the iterable, I feel you'd end up with a (a_item, (b_i, (c_i, d_i))); I wonder if a destructuring let would be hard on that? (I've not actually gotten that to work…) Also, I wish enumerate had Python's start argument; I use enumerate a lot for doing numbered lists for humans, which start at 1.

Overall, it's shaping up to be quite a language. I sincerely hope it uproots C. (I'm a big proponent of modern C++, and so I'm still attached there. :D)

[1] I really wish upgrading happened faster; I tried to cull items that weren't relevant to Trusty because I do consider Precise out of date. We're limited to LTS simply because people aren't comfortable with non-LTS (and I don't know that we could upgrade quickly enough to stay on a supported OS…)

[2]: http://stackoverflow.com/questions/28956195/how-do-i-create-...

[3]: http://stackoverflow.com/questions/29001667/how-do-i-store-a...

[4]: https://github.com/rust-lang/rust/issues/23326 — (I had to follow up in the IRC room here, it's not quite as simple as the answer in the issue. Not only do you need to depend on the crate, you need the "#![feature(plugin)]" "#![plugin(regex_macros)]" as _crate_ attributes, and this can be confusing if your use of regex is in a module-in-a-modue-in-a-module; the use of regex in that module (foo/bar/baz.rs) causes you to need to edit a different file (lib.rs).

[5]: one of the things I miss about Gentoo's ebuilds in Ubuntu is that it's so darn easy to throw additional packages into the purview of the package manager. Building .deb files is vastly more complex than an ebuild.