4 ms·

Can you elaborate a bit what it is that you find difficult or undesirable about Tokio? Or async/await + some runtime in general? So, I can relate to not wantin

Can you elaborate a bit what it is that you find difficult or undesirable about Tokio? Or async/await + some runtime in general? So, I can relate to not wanting to pull in the dependency. But otherwise it seems pretty straightforward to me. You just macro-decorate the main function, sprinkle some async/await around, maybe add a join or a mutex somewhere, and then pretty much forget all about event loops, messaging, threads and whatnot. I feel like I must be missing something important here.

ldng 6y ago
I also don't get the async hype. Maybe it is undesirable because that often times plain mono-thread synchronous is fast enough, easier to read, easier to debug and safe to handle to a junior ? Not everybody in a team has the same level of expertise. And Rust is not an interpreted language. IMHO, interpreted languages should just drop to a compiled one to keep it KISS. Instead of going the async road, just to discover in production, it is unstable because back-pressure was not taken into account. And, in Rust, it is probably not worth the effort and ultimately bloat most of the time.
- lmm 6y ago
  > Maybe it is undesirable because that often times plain mono-thread synchronous is fast enough, easier to read, easier to debug and safe to handle to a junior ? Not everybody in a team has the same level of expertise. Shared-memory concurrency is pretty much always buggy, IME, even if your team thinks they're experts. > And Rust is not an interpreted language. IMHO, interpreted languages should just drop to a compiled one to keep it KISS. Instead of going the async road, just to discover in production, it is unstable because back-pressure was not taken into account. WTF? Switching to a compiled language doesn't magically make your threads nonblocking. Maybe you can serve 10x more users with a compiled language, but if we're talking about slow network requests then async can make your throughput thousands of times higher.
  - ldng 6y ago
    Why WTF ? You are reading something I did not write. I am not obsessed with the nonblocking mantra. Blocking is not inherently bad. Multi-processus is also a perfectly valid concurrency model. Nor am I obsessing about being ultra performant to achieve the revered C10K when I don't need to or can get around it. That was my point. Not everybody is Facebook or Netflix. For the vast majority of small and medium enterprises, it faster, simpler, safer (and possibly cheaper) to quickly develop a blocking program without thread and spawn multiple processes.
    - lmm 6y ago
      > Why WTF ? Because WTF does using a compiled language have to do with anything? > Nor am I obsessing about being ultra performant to achieve the revered C10K when I don't need to or can get around it. That was my point. Then what is it that you imagine using a compiled language would help with?
      - deleted 6y ago
        [deleted]
  - sagichmal 6y ago
    > Shared-memory concurrency is pretty much always buggy, IME, even if your team thinks they're experts. Writing bug-free shared memory concurrency programs with Go is trivial. Your opinion is based on outdated information.
    - ragnese 6y ago
      I've definitely written buggy goroutine code before. AMA :p I vaguely remember expecting a reference and getting a copy or vice versa... I mean, I agree that Go is miles ahead of most other languages when it comes to helping prevent concurrency bugs, but it's sill tricky. Same with Rust.
      - sagichmal 6y ago
jstrong 6y ago
> just macro-decorate the main function, sprinkle some async/await around, maybe add a join or a mutex somewhere, and then pretty much forget all about event loops, messaging, threads and whatnot that is ... not how I have experienced it. I work on building highly concurrent systems every day but async drives me insane. to me the fundamental issue is that although the code now reads linearly, it no longer executes linearly (or reasonably close to linearly), which is 1000x more confusing. the other thing, when I'm using rust to build something high performance, part of the reason is it provides greater control. I just can't square that with macro-decorating my main function, and handing over the core control-flow to someone else's runtime.
- jgilias 6y ago
  Thank you for the perspective! This actually explains it very well. So, in a nutshell, it's the difference between apparent and actual complexity, as well as a trust issue. With async/await the apparent complexity gets reduced at the cost of vastly increased actual complexity. E.g., now instead of everything being your code that you can look at and reason about, all your concurrent workloads disappear in this void that promises to do the right thing with them. If it works the way you intended, great. If it doesn't, the rabbit hole can now be really deep. And then, it's also a trust issue. Now you have to trust other people to have done a good job. Ok, yes, this makes sense.
- simias 6y ago
  You answered jgilias better than I could, I feel exactly the same way. Async is deceptively simple in my opinion, because while it looks arguably even simpler than an explicit state machine, it makes your program flow nonlinear and I find that a lot harder to work with. With blocking code I can mentally step through the code follow causes and consequences easily, with async I feel like I'm watching a scifi movie involving time travel and parallel universes. And the loss of control is also an issue for me. I write code for memory-constrained environments, with blocking code and OS threads I can usually bound my memory consumption fairly easily. If I surrender the control to a scheduler runtime I feel like it becomes a lot harder, although here I'm willing to concede that it might have more to do with my lack of experience with Tokio than an objective issue.

ldng 6y ago

I also don't get the async hype. Maybe it is undesirable because that often times plain mono-thread synchronous is fast enough, easier to read, easier to debug and safe to handle to a junior ? Not everybody in a team has the same level of expertise. And Rust is not an interpreted language. IMHO, interpreted languages should just drop to a compiled one to keep it KISS. Instead of going the async road, just to discover in production, it is unstable because back-pressure was not taken into account. And, in Rust, it is probably not worth the effort and ultimately bloat most of the time.

lmm 6y ago
> Maybe it is undesirable because that often times plain mono-thread synchronous is fast enough, easier to read, easier to debug and safe to handle to a junior ? Not everybody in a team has the same level of expertise. Shared-memory concurrency is pretty much always buggy, IME, even if your team thinks they're experts. > And Rust is not an interpreted language. IMHO, interpreted languages should just drop to a compiled one to keep it KISS. Instead of going the async road, just to discover in production, it is unstable because back-pressure was not taken into account. WTF? Switching to a compiled language doesn't magically make your threads nonblocking. Maybe you can serve 10x more users with a compiled language, but if we're talking about slow network requests then async can make your throughput thousands of times higher.
- ldng 6y ago
  Why WTF ? You are reading something I did not write. I am not obsessed with the nonblocking mantra. Blocking is not inherently bad. Multi-processus is also a perfectly valid concurrency model. Nor am I obsessing about being ultra performant to achieve the revered C10K when I don't need to or can get around it. That was my point. Not everybody is Facebook or Netflix. For the vast majority of small and medium enterprises, it faster, simpler, safer (and possibly cheaper) to quickly develop a blocking program without thread and spawn multiple processes.
  - lmm 6y ago
    > Why WTF ? Because WTF does using a compiled language have to do with anything? > Nor am I obsessing about being ultra performant to achieve the revered C10K when I don't need to or can get around it. That was my point. Then what is it that you imagine using a compiled language would help with?
    - deleted 6y ago
      [deleted]
- sagichmal 6y ago
  > Shared-memory concurrency is pretty much always buggy, IME, even if your team thinks they're experts. Writing bug-free shared memory concurrency programs with Go is trivial. Your opinion is based on outdated information.
  - ragnese 6y ago
    I've definitely written buggy goroutine code before. AMA :p I vaguely remember expecting a reference and getting a copy or vice versa... I mean, I agree that Go is miles ahead of most other languages when it comes to helping prevent concurrency bugs, but it's sill tricky. Same with Rust.
    - sagichmal 6y ago

jstrong 6y ago

> just macro-decorate the main function, sprinkle some async/await around, maybe add a join or a mutex somewhere, and then pretty much forget all about event loops, messaging, threads and whatnot that is ... not how I have experienced it. I work on building highly concurrent systems every day but async drives me insane. to me the fundamental issue is that although the code now reads linearly, it no longer executes linearly (or reasonably close to linearly), which is 1000x more confusing. the other thing, when I'm using rust to build something high performance, part of the reason is it provides greater control. I just can't square that with macro-decorating my main function, and handing over the core control-flow to someone else's runtime.

jgilias 6y ago
Thank you for the perspective! This actually explains it very well. So, in a nutshell, it's the difference between apparent and actual complexity, as well as a trust issue. With async/await the apparent complexity gets reduced at the cost of vastly increased actual complexity. E.g., now instead of everything being your code that you can look at and reason about, all your concurrent workloads disappear in this void that promises to do the right thing with them. If it works the way you intended, great. If it doesn't, the rabbit hole can now be really deep. And then, it's also a trust issue. Now you have to trust other people to have done a good job. Ok, yes, this makes sense.
simias 6y ago
You answered jgilias better than I could, I feel exactly the same way. Async is deceptively simple in my opinion, because while it looks arguably even simpler than an explicit state machine, it makes your program flow nonlinear and I find that a lot harder to work with. With blocking code I can mentally step through the code follow causes and consequences easily, with async I feel like I'm watching a scifi movie involving time travel and parallel universes. And the loss of control is also an issue for me. I write code for memory-constrained environments, with blocking code and OS threads I can usually bound my memory consumption fairly easily. If I surrender the control to a scheduler runtime I feel like it becomes a lot harder, although here I'm willing to concede that it might have more to do with my lack of experience with Tokio than an objective issue.