4 ms·

This may be a problem with async generally unless the language is designed specifically around async like Go is, which some profound tradeoffs to make it happen

This may be a problem with async generally unless the language is designed specifically around async like Go is, which some profound tradeoffs to make it happen. (not criticizing that I think Go did a great job)

skohan 5y ago
I don't disagree. After working with Rust's model, which forces you to confront a lot of the tradeoffs and complexity, I'm more inclined to think async is a feature which should really be considered from the ground up when a language is being designed, to avoid painting oneself into a corner in the design space.
- gameswithgo 5y ago
  Rust could never have had easy async like Go, though, and maintain the control of performance that is the whole point of Rust.
  - skohan 5y ago
    Yeah maybe not like go, but it's not impossible to imagine that you could create a language from the ground up with a rust-like ownership model and some async model - maybe not async await precisely.
  - fulafel 5y ago
    Rust had GC in earlier versions, see eg http://web.archive.org/web/20130607161259/http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/ http://web.archive.org/web/20130607161259/http://pcwalton.gi...
    - kibwen 5y ago
      Yes, and (to be clear to people who don't click your link) it was removed for exactly the reason that the parent commenter mentioned. Rust's lack of a pervasive GC is not intended to suggest that GC is not generally useful (even in a systems context), only that it's too difficult to satisfy the sort of extreme control that people demand of a low-level language if they are forced to find ways to work around the pervasive GC. Which is to say, you need a way to turn off the GC, and if you can function with the GC off, then maybe you should push that as far as you can get away with, which is what Rust did.
      - skohan 5y ago
        Yeah I have done some work trying to optimize code written in GC'd runtimes, and eventually you will hit a wall. GC is great for a lot of use-cases: for instance if I am writing a server-less application with mostly lambdas/cloud functions which pull data from a database and serve it to an HTTP response, the productivity gains you get with a nice high-level language will more than make up for a few pennies you might pay for a tracing garbage collector to run, and it's going to be plenty fast enough. But when you have a case where every cycle/byte of memory counts, the GC is going to get in the way. Of course stop-the-world collectors are a catastrophe for performance, but even with modern generational GC it's essentially a part of your program's execution you didn't write and you have at best arms-reach control over which dictates hugely performance-impacting aspects of execution like memory layout. Some GC'd languages have escape hatches to manipulate the GC process directly, but even those feel a bit like trying to drive a nail by hammering it with the butt of a screwdriver.
logicchains 5y ago
>designed specifically around async like Go is, which some profound tradeoffs to make it happen. Go was not designed around the idea of "async". Its goroutine approach was inspired by https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce..., a nice theoretical model for concurrency.
dnautics 5y ago
Zig managed to get async correct, if you ask me, but it's because I would call it "the lowest-level primitive to do what you need it to do" (shift the function frame over to a place that "might not be the stack"). If you think of it as a sugared "async" you will probably do it wrong. After a lot of wrassling with it, once I realized that it was a very shallow abstraction over what the hardware is actually doing, everything clicked.
- skohan 5y ago
  Zig's approach is really nice here, but it's also a notably easier problem to solve than rust has, since it's not trying to solve for parallel/concurrent safety. Do you think Zig's approach would be feasible in Rust? I guess maybe you could do it, but the sync version would have to have the stricter constraints of the async version.
  - dnautics 5y ago
    I'm holding out for formal-methods based static analysis on lifetimes in zig.
    - pcwalton 5y ago
      Not possible for the same reasons why just adding a borrow checker to C++ isn't possible. Mostly this comes down to incompatibility with existing code. Zig is just not memory safe, and the only solution would be to add a GC.
      - surajrmal 5y ago
        If you don't consider Swift style Automatic Reference Counting a GC, then there is another option.
        pcwalton 5y ago
        That's a form of garbage collection. :)

skohan 5y ago

I don't disagree. After working with Rust's model, which forces you to confront a lot of the tradeoffs and complexity, I'm more inclined to think async is a feature which should really be considered from the ground up when a language is being designed, to avoid painting oneself into a corner in the design space.

gameswithgo 5y ago
Rust could never have had easy async like Go, though, and maintain the control of performance that is the whole point of Rust.
- skohan 5y ago
  Yeah maybe not like go, but it's not impossible to imagine that you could create a language from the ground up with a rust-like ownership model and some async model - maybe not async await precisely.
- fulafel 5y ago
  Rust had GC in earlier versions, see eg http://web.archive.org/web/20130607161259/http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/ http://web.archive.org/web/20130607161259/http://pcwalton.gi...
  - kibwen 5y ago
    Yes, and (to be clear to people who don't click your link) it was removed for exactly the reason that the parent commenter mentioned. Rust's lack of a pervasive GC is not intended to suggest that GC is not generally useful (even in a systems context), only that it's too difficult to satisfy the sort of extreme control that people demand of a low-level language if they are forced to find ways to work around the pervasive GC. Which is to say, you need a way to turn off the GC, and if you can function with the GC off, then maybe you should push that as far as you can get away with, which is what Rust did.
    - skohan 5y ago
      Yeah I have done some work trying to optimize code written in GC'd runtimes, and eventually you will hit a wall. GC is great for a lot of use-cases: for instance if I am writing a server-less application with mostly lambdas/cloud functions which pull data from a database and serve it to an HTTP response, the productivity gains you get with a nice high-level language will more than make up for a few pennies you might pay for a tracing garbage collector to run, and it's going to be plenty fast enough. But when you have a case where every cycle/byte of memory counts, the GC is going to get in the way. Of course stop-the-world collectors are a catastrophe for performance, but even with modern generational GC it's essentially a part of your program's execution you didn't write and you have at best arms-reach control over which dictates hugely performance-impacting aspects of execution like memory layout. Some GC'd languages have escape hatches to manipulate the GC process directly, but even those feel a bit like trying to drive a nail by hammering it with the butt of a screwdriver.

logicchains 5y ago

>designed specifically around async like Go is, which some profound tradeoffs to make it happen. Go was not designed around the idea of "async". Its goroutine approach was inspired by https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce..., a nice theoretical model for concurrency.

dnautics 5y ago

Zig managed to get async correct, if you ask me, but it's because I would call it "the lowest-level primitive to do what you need it to do" (shift the function frame over to a place that "might not be the stack"). If you think of it as a sugared "async" you will probably do it wrong. After a lot of wrassling with it, once I realized that it was a very shallow abstraction over what the hardware is actually doing, everything clicked.

skohan 5y ago
Zig's approach is really nice here, but it's also a notably easier problem to solve than rust has, since it's not trying to solve for parallel/concurrent safety. Do you think Zig's approach would be feasible in Rust? I guess maybe you could do it, but the sync version would have to have the stricter constraints of the async version.
- dnautics 5y ago
  I'm holding out for formal-methods based static analysis on lifetimes in zig.
  - pcwalton 5y ago
    Not possible for the same reasons why just adding a borrow checker to C++ isn't possible. Mostly this comes down to incompatibility with existing code. Zig is just not memory safe, and the only solution would be to add a GC.
    - surajrmal 5y ago
      If you don't consider Swift style Automatic Reference Counting a GC, then there is another option.
      - pcwalton 5y ago
        That's a form of garbage collection. :)