5 ms·

I hope that someday, we can have a Rust-like language without async. Bonus points if it has the ability for users to define static analysis a la borrow checkin

I hope that someday, we can have a Rust-like language without async. Bonus points if it has the ability for users to define static analysis a la borrow checking.

andrewstuart 3y ago
Async programming is beautiful. It’s the easiest and most natural way to do multiple things at the same time in single threaded code. Async makes things possible that are hard or impossible to do with synch programming. It’s a real game changer for python especially. Cant comment on rust, hopefully its implementation is smooth.
- nsm 3y ago
  Async/await is a _concurrency_ mechanism, and concurrency is certainly naturally useful. However async/await is certainly not the best implementation of concurrency, except in the narrow design space Rust has chosen. If you have a language with a runtime, green threads/fibers/coroutines, along with a choice mechanism is really the way to go. It trades off some performance for much better ergonomics. Go, Java, Racket all use this. It is unfortunate that Python picked async/await.
  - WaxProlix 3y ago
    I mostly agree, but I think you can still just pip install gevent and have greenlets as you always did - just not as language 'primitives'. Personally I've never liked the syntactic sugar on top of function calls very much. If something is a promise or whatever, return me the promise and I can choose what to do with it.
- TwentyPosts 3y ago
  Is it really though? All I personally care for when it comes to "doing multiple things at the same time" is frankly Rust's scoped threads API: Create N threads, have them perform some computations, then join them at the end of the scope. How is this not more natural than creating various state machines and passing around all sorts of weird highly abstract Future-objects?
  - andrewstuart 3y ago
    Threads are far more heavy than async. Async code maximizes the potential of the thread it’s running in.
    - TwentyPosts 3y ago
      > Threads are far more heavy than async This sounds like an issue with the implementation of threads and scheduling in common operating systems, and I don't see how replicating all that functionality inside of each sufficiently large programming language is remotely taken seriously. But also, you didn't respond to what I even said. You claimed that async is 'beautiful and natural'. I disagreed. You...fell back to a performance claim that's uncontroversially true, but irrelevant to what I said.
      - coffeemug 3y ago
        When you're reading code, it's really really nice to be able to tell if a line of code blocks. Other than that `Thread.new(_ => doIO()).join()` is pretty much the same as `await doIO()`.
      - andrewstuart 3y ago
        There's no concurrency issues with async programming. No race conditions, no inter thread coordination, no concerns about all the weird shit that happens when doing multi threading.
        dannymi 3y ago
        One of the main reasons to use async in the first place is to distribute the work to all the cpu cores that you have. So you will still have all the concurrency issues with async in that case. Only if you limited async to only one thread on one core (why would you do that?) you could avoid that.
        andrewstuart 3y ago
- bvrmn 3y ago
  > It’s a real game changer for python especially Python is so slow you gain nothing with async. I have a plenty of cool stories how I've fixed crumbled products because they were async and all connection load instead of nginx/backend goes directly into db. You rarely need long connections and if you choose async for python because it's fast then it's a wrong choice because it's not. BTW asyncio is awful bloated implementation with huge overhead around task management.
  - andrewstuart 3y ago
    >> Python is so slow you gain nothing with async. It’s not necessarily about speed, though this statement above is flat out wrong. async in Python allows you to build different types of applications. For example you can attach a task to stdout of another process and read and process it.
    - bvrmn 3y ago
      > For example you can attach a task to stdout of another process and read and process it. How max many processes you handled in this fashion? The catch is: if you need thousands than asyncio has too much overhead and you need manual epoll. If less threads are much easier to use and acceptable performance wise.
nemothekid 3y ago
>I hope that someday, we can have a Rust-like language without async. That exists today, it's called Rust. You don't have to use async.
- kelseyfrog 3y ago
  Until you want to use a library that requires async. Now you do.
  - nemothekid 3y ago
    Which part of the standard library forces me to use async? Or is the complaint that you can't force other random developers to program in the way you prefer?
    - kelseyfrog 3y ago
      Can you try steel manning?
      - filleduchaos 3y ago
        I'm not them, but I don't think there's any general-purpose programming language in existence that prevents developers from implementing async runtimes and using them in their libraries. So yes, if your whole reasoning is "other people might use async and then I won't be able to use their code", then you'll be waiting indefinitely for the magical programming language that's both fully featured for your work and does not have any portion of the ecosystem implemented in async code.
  - sgbeal 3y ago
    > Until you want to use a library that requires async. Now you do. Now you do... have an incentive to write your own which is not async.
    - kelseyfrog 3y ago
      That's fair. The Rust community does love a rewrite.

I hope that someday, we can have a Rust-like language without async. Bonus points if it has the ability for users to define static analysis a la borrow checking.

andrewstuart 3y ago

Async programming is beautiful. It’s the easiest and most natural way to do multiple things at the same time in single threaded code. Async makes things possible that are hard or impossible to do with synch programming. It’s a real game changer for python especially. Cant comment on rust, hopefully its implementation is smooth.

nsm 3y ago
Async/await is a _concurrency_ mechanism, and concurrency is certainly naturally useful. However async/await is certainly not the best implementation of concurrency, except in the narrow design space Rust has chosen. If you have a language with a runtime, green threads/fibers/coroutines, along with a choice mechanism is really the way to go. It trades off some performance for much better ergonomics. Go, Java, Racket all use this. It is unfortunate that Python picked async/await.
- WaxProlix 3y ago
  I mostly agree, but I think you can still just pip install gevent and have greenlets as you always did - just not as language 'primitives'. Personally I've never liked the syntactic sugar on top of function calls very much. If something is a promise or whatever, return me the promise and I can choose what to do with it.
TwentyPosts 3y ago
Is it really though? All I personally care for when it comes to "doing multiple things at the same time" is frankly Rust's scoped threads API: Create N threads, have them perform some computations, then join them at the end of the scope. How is this not more natural than creating various state machines and passing around all sorts of weird highly abstract Future-objects?
- andrewstuart 3y ago
  Threads are far more heavy than async. Async code maximizes the potential of the thread it’s running in.
  - TwentyPosts 3y ago
    > Threads are far more heavy than async This sounds like an issue with the implementation of threads and scheduling in common operating systems, and I don't see how replicating all that functionality inside of each sufficiently large programming language is remotely taken seriously. But also, you didn't respond to what I even said. You claimed that async is 'beautiful and natural'. I disagreed. You...fell back to a performance claim that's uncontroversially true, but irrelevant to what I said.
    - coffeemug 3y ago
      When you're reading code, it's really really nice to be able to tell if a line of code blocks. Other than that `Thread.new(_ => doIO()).join()` is pretty much the same as `await doIO()`.
    - andrewstuart 3y ago
      There's no concurrency issues with async programming. No race conditions, no inter thread coordination, no concerns about all the weird shit that happens when doing multi threading.
      - dannymi 3y ago
        One of the main reasons to use async in the first place is to distribute the work to all the cpu cores that you have. So you will still have all the concurrency issues with async in that case. Only if you limited async to only one thread on one core (why would you do that?) you could avoid that.
        andrewstuart 3y ago
bvrmn 3y ago
> It’s a real game changer for python especially Python is so slow you gain nothing with async. I have a plenty of cool stories how I've fixed crumbled products because they were async and all connection load instead of nginx/backend goes directly into db. You rarely need long connections and if you choose async for python because it's fast then it's a wrong choice because it's not. BTW asyncio is awful bloated implementation with huge overhead around task management.
- andrewstuart 3y ago
  >> Python is so slow you gain nothing with async. It’s not necessarily about speed, though this statement above is flat out wrong. async in Python allows you to build different types of applications. For example you can attach a task to stdout of another process and read and process it.
  - bvrmn 3y ago
    > For example you can attach a task to stdout of another process and read and process it. How max many processes you handled in this fashion? The catch is: if you need thousands than asyncio has too much overhead and you need manual epoll. If less threads are much easier to use and acceptable performance wise.

nemothekid 3y ago

>I hope that someday, we can have a Rust-like language without async. That exists today, it's called Rust. You don't have to use async.

kelseyfrog 3y ago
Until you want to use a library that requires async. Now you do.
- nemothekid 3y ago
  Which part of the standard library forces me to use async? Or is the complaint that you can't force other random developers to program in the way you prefer?
  - kelseyfrog 3y ago
    Can you try steel manning?
    - filleduchaos 3y ago
      I'm not them, but I don't think there's any general-purpose programming language in existence that prevents developers from implementing async runtimes and using them in their libraries. So yes, if your whole reasoning is "other people might use async and then I won't be able to use their code", then you'll be waiting indefinitely for the magical programming language that's both fully featured for your work and does not have any portion of the ecosystem implemented in async code.
- sgbeal 3y ago
  > Until you want to use a library that requires async. Now you do. Now you do... have an incentive to write your own which is not async.
  - kelseyfrog 3y ago
    That's fair. The Rust community does love a rewrite.