aturon

> Trying to change it's role into "marketing/communication/project management tool" out of a sudden

FWIW, this was part of the story from the beginning (https://github.com/rust-lang/rfcs/pull/2052)

> Firefox Quantum doesn't involve much of breaking changes (if you don't consider deprecating the old plugins one, that is).

They weren't just deprecated; they stopped working.

> I don't see Q3 2018 as any sort of "quantum leap"

For people following Rust closely, the Rust 2018 release won't be so special. But most people aren't keeping up with the details of new releases every six weeks; for them, we have an opportunity to take stock of what's changed over the last couple of years, explain the impact on idioms and how to transition code.

Remember that Rust is fairly unique in having a six week release cycle. Most other languages have a much slower release cycle, where every release is "major". Editions give us a way to pull together the rapid work we're doing into a coherent story.

From a management perspective, it's also a very useful way of focusing our effort as a community, to make sure all the pieces we've been working on are coming together into a polished whole on a clear timeline.

Yes, it could! There aren't plans to do so yet, but it'd be worth spinning up a thread on internals about this.

I think the domains of use will be quite different. Since Rust doesn't require a GC or other runtime support, we envision it being used in specific modules to provide a boost to code otherwise written in JS. See https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with... for example.

By contrast, for a language like Go, it's probably more practical to ship entire apps, rather than embedding in libraries, because there's significantly more overhead in terms of runtime system support.

There are changes that require a new edition, particularly around new keywords.

However, to be clear, editions are primarily a marketing/communication/project management tool. They give us a way to try to bring together a number of threads of work into a coherent whole, with a high level of polish across the board (including docs and tooling), and then to present that work to the world with a clear story.

It's worth comparing this to the recent Firefox Quantum release, which was likewise a singled out release on the normal train process that brought together a number of important changes, marketing/communication, and a high level of polish.

Yeah, it's really hard to strike the right balance here, and we're constantly learning from experience. Sorry for the pain! I'll put a note on the core team agenda to undergo a round of public discussion around policies here, which is overdue at this point.

You can track the full status here: https://github.com/rust-lang/rust-roadmap/issues/17

Yes, and that's definitely something we hope to address with the Blitz, both by beefing up top-level library docs, and through the Cookbook.

Rust's goal is to make it easier to write fast, reliable software.

It's not just targeted at C/C++ folks. The Rust team often hears from people who have been pulling their hair out trying to get a particular component written in a scripting language (Ruby, Python, JS) to go fast enough, which entails getting very intimate with the runtime systems for those languages. They're often surprised that they can instead write that core component in Rust, without giving up any developer productivity (or sometimes gaining it, compared to hand-optimizing their code), and get something much faster than what they were able to achieve in a scripting language.

There was a post just the other day on the Rust reddit telling this story: https://www.reddit.com/r/rust/comments/67m4eh/rust_day_two_a..., with a choice quote: "I feel like I discovered a programming super power or something. I mean I did expect it to be faster, but not this much faster this easily!" You can also check out the videos here: http://usehelix.com/resources

Rust also makes it much easier to write reliable software. The best example of this is with multithreaded programming (which is something you might reach for for speed), where Rust gives you guarantees not found in any other major language: you can know for sure that data is owned by one thread and not accessible by others, and the compiler will check this for you. You can know for sure that you only access lock-protected data while holding the lock. Rust will check thread safety for you, and more. You can read more about the concurrency benefits here: http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht...

Relative to Go specifically, in addition to the reliability improvements, Rust supports a wider range of "systems" use cases. Unlike Go, it does not require a garbage collector or other runtime system, which makes it very easy to write small Rust components that can be used with a large script, or to write extremely performance-sensitive or low-level code like a browser or game engine, an operating system, or a bare-metal web server. One reason that Dropbox switched to Rust from Go for one of their core components is greater control over memory footprint, which allowed them to reduce their server memory needs by 4x, leading to significant financial savings.

The slogan I've been using for Rust personally is: Confident, Productive Systems Programming. You can write fast code. You can write low-level code. You can do it with high productivity, thanks to the work on modern tooling and ergonomics. But most importantly, you can do all of this fearlessly, because the Rust compiler has your back.

The new book will be published by NoStarch press!

The key problem: in-memory data structures can embed ownership of system resources.

The intent wasn't to say that we should be seeing big production use right this second, but rather to set out an overall "north star" for work on Rust. The investments in Rust today should be made with an eye toward driving or enabling production use in the future.

I've updated the RFC to clarify this; thanks for the comment!

Thanks for this comment! I actually totally agree with this perspective, and wish I'd used your suggested scale in the post.

Panics are caught at the "task" level -- and there's usually one task per connection. They don't take down the entire server (since tasks are isolation boundaries).

Right now, nothing happens with the panic after it's caught, but we want to add hooks for doing something with it. Coming soon!

Yep, same here -- at least for fasthttp. This is pretty far into microbenchmarking territory, so the differences among the top libraries likely don't matter much in practice. But I think the main point is pretty clear -- even with an extreme microbenchmark, futures don't seem to be imposing notable cost.

No, it's more related to the fact that Rust allows you to use traits in both a statically- and dynamically-dispatched way. You can read some more on the topic here: http://aturon.github.io/blog/2015/09/28/impl-trait/

Thanks for the thoughtful reply!

I'm a little confused about the snippet you're pointing out. It's not actually using futures at all! In fact, that code is just part of setting up threads for the server. The reason it's more complicated than the version in Tokio is that minihttp supports multiple event loop threads (which gives some performance benefits), and this code is handling that setup.

At a broader level, Tokio's services -- the main thing users write -- are based on futures, in exactly the same way as minihttp. So for people writing actual servers, the ergonomics should be the same.

Now, stepping back, it's definitely true that ergonomics are a cost to be aware of, and it's one we've thought carefully about in the design of futures. We've had a lot of experience and success in Rust with iterators, which share a lot of the same API design philosophy.

That said, I do anticipate that over time we'll want to layer sugar on top of futures. As I mention a couple times in the blog post, async/await (or something like it) is the obvious way to do it, and there's plenty of prior art. But I think we should walk before we run -- let's make sure we've got the core abstraction right, and then we can sprinkle some sugar where it's needed.

This is an exciting upcoming feature in Rust, which you can read more about in a couple places:

- http://aturon.github.io/blog/2015/09/28/impl-trait/ - https://github.com/rust-lang/rfcs/pull/1522

This feature allows you to return any struct that implements the trait, without having to type the name of the struct (which can sometimes be quite big). It also means that clients only know what traits are implemented; the concrete type is invisible to them. The above links have a bunch more detail.

(And this feature is set to land in nightly Rust very soon! Shoutout to eddyb :)

To be clear, the issue here isn't so much stack vs heap, as much as how many heap allocations are happening.

In practice, you build up a really big combined future on the stack, which has all of the space needed for any state in its state machine, and then when the future is fired off (in a task -- one per connection), that entire thing is moved into the heap in one shot. Thus, generally, you do one big allocation up front per connection -- exactly the same as you'd do when writing state machines by hand.

The follow up posts will go into much more detail on this point :)

Yes -- the blog post didn't go into details about this, but Futures in general have an error type as well, and all the combinators know how to propagate errors correctly. (There's also a notion of "cancellation" for a future -- we'll get into this with later posts).

In terms of debugging, there's not infrastructure currently, but the kind of thing you're talking about should be easy to add!

Regarding performance, one thing to keep in mind is that all of the languages you mention use GC, which can help with cache locality issues. In Rust, of course, the situation is different. Gankro also addresses the common and useful idioms you see in most functional languages through corresponding vector-centric functions on the Rust side. (Scala is perhaps a reasonable midpoint.)

That all said, I too would love to see some substantiation of the performance intuitions here.

He does say "There are usually escape hatches, but at some limit you're just writing procedural code again."

Academic. The Mozilla supervisors (i.e. me) were very enthusiastic about the Rustonomicon being the thesis. But I think that what Gankro's working on now is even more exciting!

But I'll let him talk about that...

There's been a lot of work on integrating with Windows's native MSVC toolchain. In 1.4 (which is in beta today) this is fully supported for 64-bit. You can get it here:

https://static.rust-lang.org/dist/rust-beta-x86_64-pc-window...

Note, this requires Visual Studio 2013 or 2015.

"According to the paper, it simply makes everywhere outside of data structure code a quiescent state" -- yes, from a per-thread point of view, but of course all the hard work is in detecting global quiescence.