Why asynchronous Rust doesn't work

Post by thinkharderdev » Sat, Nov 13, 2021, 3:29 PM UTC

throwaway894345 wrote: post #80

mrfox321 wrote: post #27

Earlier quoted context omitted.

If you are going to wrap everything in Rc, just use kotlin or c-sharp or python?

While I understand that with Graal and .Net you can ostensibly make native, static binaries for Kotlin or C#, I'm very skeptical that it works well in practice. In particular, I'm guessing it will feel like swimming upstream, fighting an ecosystem and build tooling which mostly assume you're running on a VM. And then there's the question of performance... And of course, with Python your code will run 100x slower than…

Post by md8z » Sat, Nov 13, 2021, 3:33 PM UTC

convolvatron wrote: post #134

Fiahil wrote: post #73

Earlier quoted context omitted.

The article is also conflating synchronous single-threaded, synchronous multi-threaded and asynchronous programming. Each have their own usage, and no, a multi-threaded program is not the same as an asynchronous one. For example, using threads and channels instead of async/await is not a design flaw if your workload is mostly about large, blocking computations on a read-only shared state with no I/O. In that situatio…

its really strange that there are two languages running around together. one which is very opinionated in how to manage memory in a stack discipline and another which just uses reference counts. they don't quite mix. so you need to be aware of which one you're (implicitly using), and you may need library functions for both colors. you have to admit this adds some additional mental overhead. but what got me when tryin…

Post by pjmlp » Sat, Nov 13, 2021, 3:35 PM UTC

pitaj wrote: post #160

pjmlp wrote: post #155

Earlier quoted context omitted.

C++ lambdas are much better than Rust ones, because you can explicitly decide what to copy inside of the closure. As for the author being happier writing in a higher level language, it kind of proves the point that Rust's main target is the domain where any sort of automatic memory management aren't a viable option. Pushing Rust outside of this domain is only trying to fit a square peg into a round hole.

C++ lambdas need that feature because they don't have lifetimes or a borrow checker. Rust closures don't need that feature because rust has a borrow checker that ensures you aren't referencing something you shouldn't be. You can explicitly decide what to copy inside a Rust closure as well, you just use a `move` closure and create references for anything you need referenced outside the closure instead.

Post by kortex » Sat, Nov 13, 2021, 3:49 PM UTC

CodesInChaos wrote: post #47

mrfox321 wrote: post #27

Earlier quoted context omitted.

If you are going to wrap everything in Rc, just use kotlin or c-sharp or python?

Rust has advantages over C#, even for high level programming: * Rust traits are more flexible than C# interfaces, especially when combined with generics (implementing traits for foreign types, associated types, each method can have its own constraints, conditional trait implementation, #derive) * Rust has much stronger thread safety guarantees (absence of data races, preventing access to a mutex's data without lockin…

Post by e12e » Sat, Nov 13, 2021, 3:55 PM UTC

gerbilly wrote: post #173

jffry wrote: post #166

Earlier quoted context omitted.

I can't speak authoritatively, but I can think of some good reasons you might not want to automatically and implicitly await every invocation of an async function. As designed, calling an async function just returns a Promise, and any Promise can be awaited. This means that I can pass that Promise around, and it also means I can use a Promise-based library (of which there are many) easily from within my async code. A…

All right more flexibility, good point. However what languages are you thinking of when talking about this? I've done a lot of Java programming where we commonly use threads and thread pools, although there are non blocking libraries out there too. Is it common these days to mix promises and threads (waiting on a promise in a thread), or is what I just said nonsense?

  require "async"
  require "open-uri"

  Async do |task|
    task.async do
      URI.open("https://httpbin.org/delay/1.6")
    end

    task.async do
      URI.open("https://httpbin.org/delay/1.6")
    end
  end