3 ms·

If you want to be a pedant ¯\_(ツ)_/¯ then OK (and I am not sure how "native threads" == "green threads" but I won't argue) -- look up Erlang/Elixir's model, or

If you want to be a pedant ¯\_(ツ)_/¯ then OK (and I am not sure how "native threads" == "green threads" but I won't argue) -- look up Erlang/Elixir's model, or Golang's, or Rust's async workers. That's what I am looking for; basically M:N parallel execution model where M can be 50_000 and N (the number of CPU cores/threads) is no more than 32-64. The rest is a suboptimal mess and, as already mentioned above, I am not looking to invent my own async [task] orchestration runtime for every project I participate in.

medo-bear 4y ago
https://github.com/CodyReichert/awesome-cl#parallelism-and-concurrency https://github.com/CodyReichert/awesome-cl#parallelism-and-c... https://github.com/thezerobit/green-threads https://github.com/thezerobit/green-threads edit: static typing https://github.com/coalton-lang/coalton https://github.com/coalton-lang/coalton
- pdimitar 4y ago
  Thanks, that looks promising. Will check out some of the links.
- Blackthorn 4y ago
  The first two links, when it comes to green threads, have nothing that fit the bill. They are not transparent. They have all the problems of clojure's core.async. What you need is to be able to call existing blocking code and have the runtime take care of it. A macro based solution cannot do this, because macros are purely source to source transforms. If it can't access the source, it can't modify it. It must be done by the runtime.
  - medo-bear 4y ago
    > They are not transparent what does this mean?
    - Blackthorn 4y ago
      I mean "can it call blocking code without bringing everything to a screeching halt".
      - medo-bear 4y ago
        honnest question, can rust? i very much doubt that there is anything in lisp that can prevent that from being implemented at a library level (library because lisp is ANSI standardized). if you can prove that lisp is inherently unable to do what you call transparent threads im pretty sure it would be a significant cs journal paper anyway it seems to me that this discussion evolved from lisp doesnt support multicore/ concurrency/parallelism (false) to "lisp aint erlang" (truism) if you want erlang just use erlang, or a lisp version of it https://lfe.io/ https://lfe.io/
lisper 4y ago
> I am not sure how "native threads" == "green threads" You are still confused. Green threads and native threads are mutually exclusive implementation strategies for threads. Native threads are provided by the O/S. Green threads are implemented at the user level without relying on any O/S capabilities. Green threads, by definition, run in a single O/S process and can therefore only use one core. > look up Erlang/Elixir's model, or Golang's, or Rust's async workers I'm familiar with those. Those are not "green threads". But whatever you call them, you can do those things in Lisp too.
- pdimitar 4y ago
  > you can do those things in Lisp too Well if you can that would be a huge step. Gotta check again it seems.
  - lisper 4y ago
    The only implementation I know of that offers these features built-in is Allegro. But the cool thing about Lisp is that it's easy to add features like this at the user level even if they are not a native part of the implementation.
    - pdimitar 4y ago
      Not convinced. If it's so easy why hasn't anyone done it yet and made it easy to consume for everyone else? To me this is a red flag. "Just roll it yourself" is not a constructive response in the eyes of a commercial programmer. We come to an ecosystem expecting certain basic building blocks. I am not paid to evolve LISP's ecosystem. Not to mention nobody will give me the time in a world where deadlines and milestones are a fact of life. If I was doing programming purely as a hobby -- sure! But I don't. And I'd bet most commercial programmers don't as well.
      - lisper 4y ago
        > why hasn't anyone done it yet and made it easy to consume for everyone else? Dunno. No demand? No standard? I recently wrote a library like this for my job. It took me about a day. I haven't published it because it was a work for hire and so it's not mine to publish. But it's the basis for my confidence that it's not hard to do. If you want to write up a spec, I'm available for contract work (and I'm sure you would have people lining up if you actually were willing to pay someone to do this work). But I suspect you would find that writing the spec is the hard part, and if you actually did it you would find that it's easier to implement yourself than to try to hire someone.

medo-bear 4y ago

https://github.com/CodyReichert/awesome-cl#parallelism-and-concurrency https://github.com/CodyReichert/awesome-cl#parallelism-and-c... https://github.com/thezerobit/green-threads https://github.com/thezerobit/green-threads edit: static typing https://github.com/coalton-lang/coalton https://github.com/coalton-lang/coalton

pdimitar 4y ago
Thanks, that looks promising. Will check out some of the links.
Blackthorn 4y ago
The first two links, when it comes to green threads, have nothing that fit the bill. They are not transparent. They have all the problems of clojure's core.async. What you need is to be able to call existing blocking code and have the runtime take care of it. A macro based solution cannot do this, because macros are purely source to source transforms. If it can't access the source, it can't modify it. It must be done by the runtime.
- medo-bear 4y ago
  > They are not transparent what does this mean?
  - Blackthorn 4y ago
    I mean "can it call blocking code without bringing everything to a screeching halt".
    - medo-bear 4y ago
      honnest question, can rust? i very much doubt that there is anything in lisp that can prevent that from being implemented at a library level (library because lisp is ANSI standardized). if you can prove that lisp is inherently unable to do what you call transparent threads im pretty sure it would be a significant cs journal paper anyway it seems to me that this discussion evolved from lisp doesnt support multicore/ concurrency/parallelism (false) to "lisp aint erlang" (truism) if you want erlang just use erlang, or a lisp version of it https://lfe.io/ https://lfe.io/

lisper 4y ago

> I am not sure how "native threads" == "green threads" You are still confused. Green threads and native threads are mutually exclusive implementation strategies for threads. Native threads are provided by the O/S. Green threads are implemented at the user level without relying on any O/S capabilities. Green threads, by definition, run in a single O/S process and can therefore only use one core. > look up Erlang/Elixir's model, or Golang's, or Rust's async workers I'm familiar with those. Those are not "green threads". But whatever you call them, you can do those things in Lisp too.

pdimitar 4y ago
> you can do those things in Lisp too Well if you can that would be a huge step. Gotta check again it seems.
- lisper 4y ago
  The only implementation I know of that offers these features built-in is Allegro. But the cool thing about Lisp is that it's easy to add features like this at the user level even if they are not a native part of the implementation.
  - pdimitar 4y ago
    Not convinced. If it's so easy why hasn't anyone done it yet and made it easy to consume for everyone else? To me this is a red flag. "Just roll it yourself" is not a constructive response in the eyes of a commercial programmer. We come to an ecosystem expecting certain basic building blocks. I am not paid to evolve LISP's ecosystem. Not to mention nobody will give me the time in a world where deadlines and milestones are a fact of life. If I was doing programming purely as a hobby -- sure! But I don't. And I'd bet most commercial programmers don't as well.
    - lisper 4y ago
      > why hasn't anyone done it yet and made it easy to consume for everyone else? Dunno. No demand? No standard? I recently wrote a library like this for my job. It took me about a day. I haven't published it because it was a work for hire and so it's not mine to publish. But it's the basis for my confidence that it's not hard to do. If you want to write up a spec, I'm available for contract work (and I'm sure you would have people lining up if you actually were willing to pay someone to do this work). But I suspect you would find that writing the spec is the hard part, and if you actually did it you would find that it's easier to implement yourself than to try to hire someone.