5 ms·

Announcing Rust 1.26.2

80 points by philonoist 8y ago

steveklabnik 8y 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 8y 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?
  - steveklabnik 8y ago
    That's the "Formal Verification Working Group" https://internals.rust-lang.org/t/announcing-the-formal-verification-working-group/7240 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 :)
    - eatbitseveryday 8y ago
      > 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 :) Steve - can you give me a source for the latter? I'd like to read more into that, specifically. edit: this? https://joinup.ec.europa.eu/news/eu-funds-open-source-programm https://joinup.ec.europa.eu/news/eu-funds-open-source-progra...
      - steveklabnik 8y ago
        https://plv.mpi-sws.org/rustbelt/ https://plv.mpi-sws.org/rustbelt/ is the project, https://cordis.europa.eu/project/rcn/200802_en.html https://cordis.europa.eu/project/rcn/200802_en.html is the citation for the currency figure. It's already borne some wonderful fruit. See https://www.ralfj.de/blog/2017/06/09/mutexguard-sync.html https://www.ralfj.de/blog/2017/06/09/mutexguard-sync.html for an area where we were unsound, and https://github.com/rust-lang/rust/pull/45267#issuecomment-339362393 https://github.com/rust-lang/rust/pull/45267#issuecomment-33... for an area where we were overly restrictive, and could remove some bounds without affecting soundness.
- zxcvhjkl 8y ago
  Any plans for “stack full” co-routine(go style). IMHO the current “Futures” monad style solution makes the code look a bit confusing.
  - deleted 8y ago
    [deleted]
  - steveklabnik 8y 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 8y 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.
- _yawn 8y 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.
  - steveklabnik 8y ago
    It was an explicit design choice. Keyword arguments are something that we haven’t totally rejected, but many are skeptical. We’ll see!
    - _yawn 8y ago
      Skepticism towards keyword arguments is something I have trouble understanding. Is it because of some performance consideration? Thanks for your answer!
      - Retra 8y ago
        Keyword arguments tend to lead to bloated functions that try to account for every possible situation. So they're unidiomatic when compared to C-style functions which tend to always do the same thing in the same way every time you call them. Of course, I'm assuming you're imagining an implementation where you are allowed to omit keywords to set default values. Naturally if every argument is always required, you don't have this problem.
        _yawn 8y ago
        I mostly miss them for constructing objects with default values, yes. The alternative is the builder pattern, which involves a lot of boilerplate.
        kjeetgill 8y ago
        Rust has macros. No such thing as boilerplate. Only libraries that havent been written yet. :D

80 points by philonoist 8y 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 8y 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?
- steveklabnik 8y ago
  That's the "Formal Verification Working Group" https://internals.rust-lang.org/t/announcing-the-formal-verification-working-group/7240 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 :)
  - eatbitseveryday 8y ago
    > 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 :) Steve - can you give me a source for the latter? I'd like to read more into that, specifically. edit: this? https://joinup.ec.europa.eu/news/eu-funds-open-source-programm https://joinup.ec.europa.eu/news/eu-funds-open-source-progra...
    - steveklabnik 8y ago
      https://plv.mpi-sws.org/rustbelt/ https://plv.mpi-sws.org/rustbelt/ is the project, https://cordis.europa.eu/project/rcn/200802_en.html https://cordis.europa.eu/project/rcn/200802_en.html is the citation for the currency figure. It's already borne some wonderful fruit. See https://www.ralfj.de/blog/2017/06/09/mutexguard-sync.html https://www.ralfj.de/blog/2017/06/09/mutexguard-sync.html for an area where we were unsound, and https://github.com/rust-lang/rust/pull/45267#issuecomment-339362393 https://github.com/rust-lang/rust/pull/45267#issuecomment-33... for an area where we were overly restrictive, and could remove some bounds without affecting soundness.
zxcvhjkl 8y ago
Any plans for “stack full” co-routine(go style). IMHO the current “Futures” monad style solution makes the code look a bit confusing.
- deleted 8y ago
  [deleted]
- steveklabnik 8y 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 8y 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.
_yawn 8y 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.
- steveklabnik 8y ago
  It was an explicit design choice. Keyword arguments are something that we haven’t totally rejected, but many are skeptical. We’ll see!
  - _yawn 8y ago
    Skepticism towards keyword arguments is something I have trouble understanding. Is it because of some performance consideration? Thanks for your answer!
    - Retra 8y ago
      Keyword arguments tend to lead to bloated functions that try to account for every possible situation. So they're unidiomatic when compared to C-style functions which tend to always do the same thing in the same way every time you call them. Of course, I'm assuming you're imagining an implementation where you are allowed to omit keywords to set default values. Naturally if every argument is always required, you don't have this problem.
      - _yawn 8y ago
        I mostly miss them for constructing objects with default values, yes. The alternative is the builder pattern, which involves a lot of boilerplate.
        kjeetgill 8y ago
        Rust has macros. No such thing as boilerplate. Only libraries that havent been written yet. :D