Announcing Rust 1.26.2

https://blog.rust-lang.org/2018/06/05/Rust-1.26.2.html

by philonoist • 8 years ago

80 27 8 years ago

This is our first-ever z=2 release. Even though it's only 16 days until 1.27.0, we decided to go ahead and issue it, given the unsoundness. Happy as always to answer questions.

codefined• 8 years ago

I remember reading a few weeks ago on Hacker News about a team of people who were working to mathematically prove that some of these issues are impossible in existing programming constructs. I can't entirely remember whether it was a thing people wanted to do or a thing that people were already doing, would you happen to know?

steveklabnik8• 8 years ago

That's the "Formal Verification Working Group" https://internals.rust-lang.org/t/announcing-the-formal-veri...

Participants range from "I'm interested in formal methods" to "my company uses formal methods and we're starting to apply them to Rust" to "The EU has given almost two million Euro for a university grant to prove Rust code" and everywhere in between :)

zxcvhjkl3• 8 years ago

Any plans for “stack full” co-routine(go style).

IMHO the current “Futures” monad style solution makes the code look a bit confusing.

steveklabnik8• 8 years ago

So, yes and no. Let me lay out the bits for you.

The language currently knows nothing of coroutines. So, as you say, you chain Futures together, which is basically a monad. You submit that futures chain to an executor, like Tokio, and it basically moves the chain's stack to the heap, and then executes it. So, in some sense, Tokio is a stack-ful co-routine. It just so happens we know the stack's exact size at compile time, which has some nice properties compared to other stack-ful implementations.

Additionally, we have, in nightly, "generators." These are stack-less coroutines. On top of that, we have accepted (and there's a PR open in the compiler to implement) async/await. Async/await de-sugars to the whole Futures-chain shenanigans, but does it via generators. You then take that chain, and submit it to something like Tokio, making it stack-ful. Writing code with async/await is significantly more ergonomic than chaining futures together by hand, and feels more like goroutines, though suspension points are explicit rather than implicit.

Generators are likely to eventually be stable as well, so you can also write your own stack-less stuff if you want. But for now, they're an implementation detail of async/await, which has much less of a design surface area, and is what most people will want to do with this stuff, and so has priority.

Make sense?

woah• 8 years ago

I disagree. For the use case of single thread concurrency, async/await is easier to reason about, since you don't have the added abstraction of a separate execution thread (that isn't even actually a different thread). With coroutines comes the added work of deciding when to "fork", and the added work of stringing everything together with channels and mutuxes.

I myself learned to program on node.js 6 years ago, when everything required piles of callbacks (the least ergonomic form of async/await style concurrency). It's strange to see a bunch of experienced programmers saying that nobody could possibly use this style, as it is too hard, while millions of beginning programmers master it easily. In fact I remember that the people who usually had a problem with callbacks were those who had prior experience with synchronous languages.

Async/await reveals the beauty of this pattern of async, by getting rid of the syntactical cruft of promises and callbacks. It's already awesome in C# and JS, and will be landing in Rust this year.

IMO using "thread" patterns should only be done when you actually have something to gain, with real multi core parallelism. The big advantage of coroutines is that they scale seamlessly across cores. By putting the bad ergonomics of threads everywhere, you make your code ready to scale onto actual threads.

_yawn4• 8 years ago

This is unrelated, but do you know if Rust's omission of exceptions is a consequence of the borrow checker, or an explicit design choice? I get that most people come to Rust from C++, but as someone coming from a higher level down to Rust, things like the complicated error handling and lack of keyword arguments bother me.

steveklabnik8• 8 years ago

It was an explicit design choice.

Keyword arguments are something that we haven’t totally rejected, but many are skeptical. We’ll see!

algesten• 8 years ago

Treating errors as values might be the best shift I've done as a programmer in later years. In fact, after learning it in rust, I took it with me back to typescript.

I can only recommend trying it. It's magical!

Announcing Rust 1.26.2

Related Stories