5 ms·

This is the crux of the issue but it's not explained further: > I wanted to be able to use asynchronous programming because for the type of work I do (a lot of

This is the crux of the issue but it's not explained further: > I wanted to be able to use asynchronous programming because for the type of work I do (a lot of making APIs that talk to other services with very little CPU work) it’s hard to get much more performant. Presumably the author of Turtl hit (or predicted) a scaling bottleneck with synchronous CL? Does CL not perform very well with tons of threads doing synchronous i/o (compared to other languages)? I also don't see a lot of upsides here for CL. The pros given are: * You can modify code while it's running so it's useful for debugging. Is this so much more useful to warrant switching languages from a language where I just re-run my whole unit test after modifying the implementation? They tend to be imperceptibly quick. * It's elegant, fast, and stable. Compared to NodeJS I guess I'm willing to just accept these :P

mikelevins 5y ago
If you gain nothing from livecoding, then no, Common Lisp's pros are not going to be compelling. If you gain something significant from livecoding, then Common Lisp offers a good deal more than just quick turnaround time. I listed some of what it offers in another comment here.
Jtsummers 5y ago
CL doesn't have a truly standard way of writing async/multi-threaded code. Every (practical) implementation supports native OS threads, and Bordeaux threads supports every reasonable implementation while providing a uniform way to access their lower level (and implementation specific) versions. You can get good async/multithread performance out of Common Lisp. But it's, by definition, non-standard. Node at least made asyncio a part of its standard implementation, so you're not having to pick and choose or construct it from lower level primitives. There are other higher level concurrency libraries for CL that build on BT and the lower level primitives to remove the need for you to think about it, but they're still non-standard. That's all missing from CL as a part of the standard, if CL were to get a second standard something like that would almost certainly make it into the revision. But it's not getting another standard any time soon.
- bestcoder69 5y ago
  > if CL were to get a second standard Huh, TIL. Checking wiki, the final/current version is from 1994[0]. Welp, that explains it for me. Thanks! 0: https://en.wikipedia.org/wiki/Common_Lisp#History https://en.wikipedia.org/wiki/Common_Lisp#History
- gibsonf1 5y ago
  We simply use lparallel with incredible results. We combine that with using a thread-safe version of cl-containers, such that we save futures in a container, and then when needed, force the futures in the entire container. https://lparallel.org/ https://lparallel.org/ https://github.com/gwkkwg/cl-containers https://github.com/gwkkwg/cl-containers
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).

mikelevins 5y ago

If you gain nothing from livecoding, then no, Common Lisp's pros are not going to be compelling. If you gain something significant from livecoding, then Common Lisp offers a good deal more than just quick turnaround time. I listed some of what it offers in another comment here.

Jtsummers 5y ago

CL doesn't have a truly standard way of writing async/multi-threaded code. Every (practical) implementation supports native OS threads, and Bordeaux threads supports every reasonable implementation while providing a uniform way to access their lower level (and implementation specific) versions. You can get good async/multithread performance out of Common Lisp. But it's, by definition, non-standard. Node at least made asyncio a part of its standard implementation, so you're not having to pick and choose or construct it from lower level primitives. There are other higher level concurrency libraries for CL that build on BT and the lower level primitives to remove the need for you to think about it, but they're still non-standard. That's all missing from CL as a part of the standard, if CL were to get a second standard something like that would almost certainly make it into the revision. But it's not getting another standard any time soon.

bestcoder69 5y ago
> if CL were to get a second standard Huh, TIL. Checking wiki, the final/current version is from 1994[0]. Welp, that explains it for me. Thanks! 0: https://en.wikipedia.org/wiki/Common_Lisp#History https://en.wikipedia.org/wiki/Common_Lisp#History
gibsonf1 5y ago
We simply use lparallel with incredible results. We combine that with using a thread-safe version of cl-containers, such that we save futures in a container, and then when needed, force the futures in the entire container. https://lparallel.org/ https://lparallel.org/ https://github.com/gwkkwg/cl-containers https://github.com/gwkkwg/cl-containers

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).