3 ms·

> 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 jo

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

pdimitar 4y ago
I mean, high-quality work should be paid. Obviously. But now we're making a full U-turn to my initial argument: LISP doesn't have features that I find are (or should be) basic building blocks so I am just taking my business elsewhere.
- lisper 4y ago
  But it does. Allegro CL has it. Other implementation might have it too. It's hard to say because you've been very vague about exactly what it is that you want.
  - pdimitar 4y ago
    Was I vague? Or were you being overly pedant about Wikipedia-sourced definitions that, as another commenter pointed out, are kind of outdated? And now trying to frame me as not knowing what I want? And pretending that the examples I gave about three other languages don't paint the picture well enough? You seem to be arguing in bad faith from where I am standing. ...And okay -- I'd like a M:N green threads runtime (or library if you prefer) with preemptive scheduling or at least not a completely manual cooperative scheduling. And yes, we're talking full 100% CPU usage on all cores when needed. Not single-thread. And to repeat, since you kind of pretended I never said anything about what other languages do, and if you are indeed aware of how Erlang's BEAM VM is doing it -- that is what should be present in more than one language / runtime IMO. Failing that, Golang's goroutines and Rust's async workers+channels are quite fine too. To me, in 2023, no language has an excuse for not having something like that. Modern example: OCaml team worked on it for years and recently delivered it.
    - lisper 4y ago
      > Was I vague? Well, here's what you originally wrote: > Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, and OCaml 5.0's recent multicore runtime (and the emerging libraries around it)? > I want the higher-level stuff. I want to solve problems and not invent a new async orchestration runtime for every project I work on. That seems pretty vague to me. You mentioned four different languages (Erland, Go, Rust, OCaml). Do you want the intersection of the features of all those languages? The union? Some subset? > You seem to be arguing in bad faith I didn't even realize this was an argument, so I guess the problem must be that I'm just too dim to glean the correct meaning of your words. Sorry about that.
      - pdimitar 4y ago
        Well it is an argument insofar as you keep insisting that the LISP ecosystem has what I want, and I keep disagreeing with that claim. But yep, I want Erlang-style concurrency / parallelism and, failing that, something like Golang builtins or Rust's libraries. So not a subset or intersection, more like a priority-ordered wish-list: I want what I perceive as an ideal model (Erlang) but if that's not available, there is stuff 1-2 floors below that are good enough (Golang, Rust). But native threads or fully cooperative opt-in parallelism are practically a drag (or were in the projects I used them) and aren't cutting it for the work I do. I'll grant you that the building blocks for something like what I need are there but I am not willing to put the work to create the runtime / the library, nor pay anyone to do it for me. Hence my original post: I am commenting on the status quo, not on how it could theoretically change at any time. I find the latter of no consequence.
        lisper 4y ago
        > I want Erlang-style concurrency OK, but you must want something besides that because... > an ideal model (Erlang) but if that's not available It is available. In Erlang. So if that's what you want, why are you not just using Erlang? Why even bother with the contingency of "if that's available"? Why are we having this discussion at all? This is the reason that Erlang-style concurrency is not available off-the-shelf in Lisp. There's no market for it. The people who really want Erlang-style concurrency just use Erlang. No language will ever do Erlang-style concurrency better than Erlang. Erlang-style concurrency is Erlang's defining feature. The whole point of Erlang is to do Erlang-style concurrency. You can't do better than Erlang at "Erlang-style concurrency" by definition. The point of Lisp is not do X-style-anything better than X. The main benefit of Lisp is that it allows you to explore a much larger space of possible solutions in a much shorter time, which is a big win when you don't know what you want, which, I submit, is most of the time.
- sulam 4y ago
  I think you are being willfully disagreeable here. There is a Lisp with the style of threads you claimed doesn’t exist. So you’re simply wrong with your claim. Also even if that didn’t exist, no one can say that a day’s worth of work is a prohibitive barrier to getting things done.
  - pdimitar 4y ago
    I suppose part of the context got lost here but no, I haven't gotten out of my way to disagree specifically; more like I got frustrated because the other guy seemed to purposefully miss the point from where I was standing. I don't want just a best-effort-with-what-we-have-in-our-runtime-that-was-not-ever-designed-for-it implementation however, I want proper preemptive scheduling and a transparent M:N threading model, very akin to what Erlang/Elixir have. I was made aware of Clojure's core.async but after reviewing it, it's IMO not good enough. Though as others have said it can be used as a building block for something better. That seems to be true as well.

by lisper 4y ago

pdimitar 4y ago

I mean, high-quality work should be paid. Obviously. But now we're making a full U-turn to my initial argument: LISP doesn't have features that I find are (or should be) basic building blocks so I am just taking my business elsewhere.

lisper 4y ago
But it does. Allegro CL has it. Other implementation might have it too. It's hard to say because you've been very vague about exactly what it is that you want.
- pdimitar 4y ago
  Was I vague? Or were you being overly pedant about Wikipedia-sourced definitions that, as another commenter pointed out, are kind of outdated? And now trying to frame me as not knowing what I want? And pretending that the examples I gave about three other languages don't paint the picture well enough? You seem to be arguing in bad faith from where I am standing. ...And okay -- I'd like a M:N green threads runtime (or library if you prefer) with preemptive scheduling or at least not a completely manual cooperative scheduling. And yes, we're talking full 100% CPU usage on all cores when needed. Not single-thread. And to repeat, since you kind of pretended I never said anything about what other languages do, and if you are indeed aware of how Erlang's BEAM VM is doing it -- that is what should be present in more than one language / runtime IMO. Failing that, Golang's goroutines and Rust's async workers+channels are quite fine too. To me, in 2023, no language has an excuse for not having something like that. Modern example: OCaml team worked on it for years and recently delivered it.
  - lisper 4y ago
    > Was I vague? Well, here's what you originally wrote: > Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, and OCaml 5.0's recent multicore runtime (and the emerging libraries around it)? > I want the higher-level stuff. I want to solve problems and not invent a new async orchestration runtime for every project I work on. That seems pretty vague to me. You mentioned four different languages (Erland, Go, Rust, OCaml). Do you want the intersection of the features of all those languages? The union? Some subset? > You seem to be arguing in bad faith I didn't even realize this was an argument, so I guess the problem must be that I'm just too dim to glean the correct meaning of your words. Sorry about that.
    - pdimitar 4y ago
      Well it is an argument insofar as you keep insisting that the LISP ecosystem has what I want, and I keep disagreeing with that claim. But yep, I want Erlang-style concurrency / parallelism and, failing that, something like Golang builtins or Rust's libraries. So not a subset or intersection, more like a priority-ordered wish-list: I want what I perceive as an ideal model (Erlang) but if that's not available, there is stuff 1-2 floors below that are good enough (Golang, Rust). But native threads or fully cooperative opt-in parallelism are practically a drag (or were in the projects I used them) and aren't cutting it for the work I do. I'll grant you that the building blocks for something like what I need are there but I am not willing to put the work to create the runtime / the library, nor pay anyone to do it for me. Hence my original post: I am commenting on the status quo, not on how it could theoretically change at any time. I find the latter of no consequence.
      - lisper 4y ago
        > I want Erlang-style concurrency OK, but you must want something besides that because... > an ideal model (Erlang) but if that's not available It is available. In Erlang. So if that's what you want, why are you not just using Erlang? Why even bother with the contingency of "if that's available"? Why are we having this discussion at all? This is the reason that Erlang-style concurrency is not available off-the-shelf in Lisp. There's no market for it. The people who really want Erlang-style concurrency just use Erlang. No language will ever do Erlang-style concurrency better than Erlang. Erlang-style concurrency is Erlang's defining feature. The whole point of Erlang is to do Erlang-style concurrency. You can't do better than Erlang at "Erlang-style concurrency" by definition. The point of Lisp is not do X-style-anything better than X. The main benefit of Lisp is that it allows you to explore a much larger space of possible solutions in a much shorter time, which is a big win when you don't know what you want, which, I submit, is most of the time.
sulam 4y ago
I think you are being willfully disagreeable here. There is a Lisp with the style of threads you claimed doesn’t exist. So you’re simply wrong with your claim. Also even if that didn’t exist, no one can say that a day’s worth of work is a prohibitive barrier to getting things done.
- pdimitar 4y ago
  I suppose part of the context got lost here but no, I haven't gotten out of my way to disagree specifically; more like I got frustrated because the other guy seemed to purposefully miss the point from where I was standing. I don't want just a best-effort-with-what-we-have-in-our-runtime-that-was-not-ever-designed-for-it implementation however, I want proper preemptive scheduling and a transparent M:N threading model, very akin to what Erlang/Elixir have. I was made aware of Clojure's core.async but after reviewing it, it's IMO not good enough. Though as others have said it can be used as a building block for something better. That seems to be true as well.