Why I think Rust is the "language of the future" for systems programming

The same way you expose them in C. Rust and C are compatible at the binary level.

"How will Rust Tasks play with Python threads?"

More or less the same way C setcontext()/swapcontext() workalikes play with Python threads. We probably want a runtime-less Rust to allow users who aren't using tasks at all to just omit the whole system, though. The language itself knows nothing about tasks; they're purely part of the runtime library.

"What if I use a Rust Pipe to send a Python value between tasks?"

Should work as you expect. In Servo we're already sending Objective-C values (which require special APIs to perform the memory management) from task to task over pipes.

"How do I keep Rust from doing a GC pass while I'm holding the Python GIL?"

By not using the GC. It's easy to tell when you aren't using the GC; you can just avoid @ types, and there is a warning you can turn on to enforce no GC use. This sort of thing is the reason why we support manual memory management.

"If you're only writing an application (ie. not a library) and never want to embed other languages into your application, then this might be ok. But I'm more interested in writing shared functionality that is useful across languages."

We're already successfully embedding a JavaScript engine into a pure Rust program for Servo. JavaScript can access Rust types and vice versa.

"Why should the whole stack of parsers, crypto, compression, etc. have to be written separately in each language?"

I agree completely that this is undesirable. That's why Rust doesn't do this. For your three examples, Rust and Servo link to C libraries: Hubbub for HTML parsing, NSS for crypto, and zlib for compression.

"today's server programs comprise tens of millions of lines of code, are worked on by hundreds or even thousands of programmers, and are updated literally every day. To make matters worse, build times, even on large compilation clusters, have stretched to many minutes, even hours."

http://splashcon.org/2012/program/404

> We probably want a runtime-less Rust to allow users who aren't using tasks at all to just omit the whole system, though.

I'd be really interested in reading more about this if/when it is available. I'm also interested in whether you'd ever ship the tasks library standalone, such that you can interoperate with Rust tasks from C (obviously you'd have to follow certain rules to maintain the integrity/safety of the runtime).

> I agree completely that this is undesirable. That's why Rust doesn't do this. For your three examples, Rust and Servo link to C libraries: Hubbub for HTML parsing, NSS for crypto, and zlib for compression.

Understood, but I'm interested in the story for the guy who is writing those libraries.

At these Go meetups, companies are presenting what they're using Go for in production already, with great success. Go is not difficult to program in, Go is functional, Go is performant, Go is developer friendly.

That is not to say that Go doesn't have warts, it does (32-bit garbage collecting anyone? or the slow regular expression engine?), but people from Ruby, people from Python, and people from JavaScript are gravitating toward Go and _enjoying_ it.

Go also has excellent stewardship in the form of Pike et al.

In my mind, at least, the gap between Rust and Go is pretty big at this point. This is why Rust feels like vaporware (especially compared to Go).

People like to compare Go and Rust, and I think the comparison is pretty natural. The difference is that Go already has "boots on the ground."

If Rust releases something awesome in the next few months, the gap between Go and Rust could rapidly close (depending on developer adoption). But, in my mind, the longer Rust takes to iron out the quirks of it's syntax (not implementation, syntax!), the wider that gap will get.