4 ms·

> With CL, it felt like I was constantly fighting the tide.... just to get basic things working that are already solved problems in other languages (Node).... I

by gknoy 5y ago

> With CL, it felt like I was constantly fighting the tide.... just to get basic things working that are already solved problems in other languages (Node).... I was mostly fighting it alone. Based on the author's comments in the article, I didn't get the impression that he hit any performance bottlenecks -- rather, it was an emotionally draining experience to be on the hook for everything. Similar to how some open source authors walk away from things because it's "Too Much".

bestcoder69 5y ago
Yep that part makes sense to me. But I meant: if there's no perf bottleneck why care about async i/o at all? Since that's the impetus for async i/o usually. A sibling comment to yours answered that part for me. My understanding now is that concurrent code in any paradigm is going off the beaten path, i.e. away from standardized CL, so at the very least you aren't going to be able to write concurrent code portable across different CLs.
- Jtsummers 5y ago
  Async IO is not chosen because a language isn't fast enough, it's because IO isn't fast enough. Async IO would be useful even if you handwrite everything in the best and fastest assembler possible because in the time it takes to go out and read some data (even on an SSD) you can compute many, many more things. The purpose of async IO is to permit the interleaving of fast and slow activities. If I were still doing scientific computing (it's been a while) I'd want async IO (some implementation of it) even if I had the best GPU for my number crunching bits. Loading the model takes a lot of time and there are other activities the program can engage in during that delay. CL's lack of a standard way to do async IO (in this particular instance) means that even if you have a very fast program, you end up with either a bottleneck waiting for IO or you've recreated the async IO model from other languages (or their standard libraries or their de facto standard libraries) and are now responsible for it.
  - brazzy 5y ago
    > The purpose of async IO is to permit the interleaving of fast and slow activities. You absolutely do not need async IO for that. You can do that with a synchronous programming model just fine, using threads and letting the OS do its thing. Async is an absolutely horrible programming model. There are really only two advantages is brings: It lets you avoid the memory and context switching overhead of threads if you need to handle a very large number of requests concurrently, and it lets you do concurrency without worrying about synchronizing access to shared resources (but there are much better ways to do that).
    - Jtsummers 5y ago
      If you use threads to cordon off the slow IO code, you're doing async IO, just without core language or library support for it.
      - brazzy 5y ago
        I was referring to using blocking IO, one thread per request. You know, the much simpler way that was the norm before async became fashionable.
    - Karrot_Kream 5y ago
      > You absolutely do not need async IO for that. You can do that with a synchronous programming model just fine, using threads and letting the OS do its thing. "just fine" is highly relative here and is doing most of the work in your statement. Do you have any conditions under which this is "just fine"? Any more detail? Or else it's just a personal preference.
      - brazzy 5y ago
        A preference? The term was mostly meant to convey that it can be done without problems, contradicting the assertion that async IO "permits" the interleaving of fast and slow activities. Synchronous models have been used for that far longer and more often than asynchronous ones. CGI scripts, Perl, Java servlets all did synchronous IO while also interleaving slow and fast activities for decades before Node made async IO fashionable. An in my second paragraph, I specifically mentioned the specific conditions where async has advantages.
- orthecreedence 5y ago
  Yeah, admittedly I could have gone with threading/hunchentoot and been much better off. It was probably stupid to forge the entire async path the way I did. To be fair, Turtl these days gets enough traffic where async does probably make sense for us, and nodejs is serving us well.

by gknoy 5y ago

bestcoder69 5y ago

Yep that part makes sense to me. But I meant: if there's no perf bottleneck why care about async i/o at all? Since that's the impetus for async i/o usually. A sibling comment to yours answered that part for me. My understanding now is that concurrent code in any paradigm is going off the beaten path, i.e. away from standardized CL, so at the very least you aren't going to be able to write concurrent code portable across different CLs.

Jtsummers 5y ago
Async IO is not chosen because a language isn't fast enough, it's because IO isn't fast enough. Async IO would be useful even if you handwrite everything in the best and fastest assembler possible because in the time it takes to go out and read some data (even on an SSD) you can compute many, many more things. The purpose of async IO is to permit the interleaving of fast and slow activities. If I were still doing scientific computing (it's been a while) I'd want async IO (some implementation of it) even if I had the best GPU for my number crunching bits. Loading the model takes a lot of time and there are other activities the program can engage in during that delay. CL's lack of a standard way to do async IO (in this particular instance) means that even if you have a very fast program, you end up with either a bottleneck waiting for IO or you've recreated the async IO model from other languages (or their standard libraries or their de facto standard libraries) and are now responsible for it.
- brazzy 5y ago
  > The purpose of async IO is to permit the interleaving of fast and slow activities. You absolutely do not need async IO for that. You can do that with a synchronous programming model just fine, using threads and letting the OS do its thing. Async is an absolutely horrible programming model. There are really only two advantages is brings: It lets you avoid the memory and context switching overhead of threads if you need to handle a very large number of requests concurrently, and it lets you do concurrency without worrying about synchronizing access to shared resources (but there are much better ways to do that).
  - Jtsummers 5y ago
    If you use threads to cordon off the slow IO code, you're doing async IO, just without core language or library support for it.
    - brazzy 5y ago
      I was referring to using blocking IO, one thread per request. You know, the much simpler way that was the norm before async became fashionable.
  - Karrot_Kream 5y ago
    > You absolutely do not need async IO for that. You can do that with a synchronous programming model just fine, using threads and letting the OS do its thing. "just fine" is highly relative here and is doing most of the work in your statement. Do you have any conditions under which this is "just fine"? Any more detail? Or else it's just a personal preference.
    - brazzy 5y ago
      A preference? The term was mostly meant to convey that it can be done without problems, contradicting the assertion that async IO "permits" the interleaving of fast and slow activities. Synchronous models have been used for that far longer and more often than asynchronous ones. CGI scripts, Perl, Java servlets all did synchronous IO while also interleaving slow and fast activities for decades before Node made async IO fashionable. An in my second paragraph, I specifically mentioned the specific conditions where async has advantages.
orthecreedence 5y ago
Yeah, admittedly I could have gone with threading/hunchentoot and been much better off. It was probably stupid to forge the entire async path the way I did. To be fair, Turtl these days gets enough traffic where async does probably make sense for us, and nodejs is serving us well.