Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Lisp?

nyxt.atlas.engineer

Post reply on HN
Print view View original

131–140 of 339 posts

Re: Why Lisp?

#131

Post by Blackthorn »

medo-bear wrote: post #125
pdimitar wrote: post #122

Earlier quoted context omitted.

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…

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

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.

Re: Why Lisp?

#132

Post by lispm »

pdimitar wrote: post #97

I can gloss over LISP's lack of static strong typing and if I force myself a bit, I can also ignore it not producing small efficient native binaries... but the lack of (semi-)transparent concurrency / parallelism is my deal-breaker. Multicore CPUs are a fact for life for a long time now. Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, a…

Many Lisps (and Common Lisp) had 'green threads' decades ago. Green threads are not preemptively scheduled by the OS/hardware. Multi-Processor Lisps were new and very rare (like the Lisp&Scheme for BBN Butterfly https://en.wikipedia.org/wiki/BBN_Butterfly or the Lisp for massive parallel Connection Machine). So the green threads then were mostly on a single core.

Many Common Lisps moved to native threads in the last two decades because that provided preemptively scheduled threads on multi-core machines. Early examples were Corman Lisp (on Windows) and Scieneer CL (a commercial fork of CMUCL). Native threads have also advantages when interfacing to the OS.

Implementations like SBCL, LispWorks, Allegro CL and others provide native threads and support multi-core machines. In the LispWorks development environment I use, every IDE tool runs in its own thread on a multicore CPU.

The big problem most implementations face is getting a parallel and/or concurrent garbage collector. For the JVM such things exist in various forms. Allegro CL has something like a parallel GC.

I would maybe use something like lparallel. https://lparallel.org/overview/ Other libs are listed here: https://cliki.net/concurrency

Re: Why Lisp?

#133

Post by pgwhalen »

lisper wrote: post #118
pdimitar wrote: post #108

Earlier quoted context omitted.

Well, that's exactly what I don't care about. Most languages have native threads. I want an actor runtime with transparent green threads, for example. Like Erlang/Elixir.

I don't think you understand what green threads are. Green threads are simulated threads that run on a single core. https://en.wikipedia.org/wiki/Green_thread But you wrote: Multicore CPUs are a fact for life for a long time now. So I assumed that you didn't really want green threads and were just using the wrong terminology. In any case, you can get a Lisp with green threads too, though as you yourself point out tha…

> I don't think you understand what green threads are. Green threads are simulated threads that run on a single core.

I guess this is just semantics, but it seems to be that this is an overly narrow and stale definition of green threads. The wikipedia article is not even internally consistent in its definition of green threads necessarily being scheduled only onto a single core (it includes goroutines as an example). The only reference to such a definition cites two sources from the very early 2000's.

I think it's safe to say that in 2023 "green threads" simply refers to user space threads rather than kernel threads, and that may include threads scheduled onto multiple cores.

Re: Why Lisp?

#134

Post by pdimitar »

vindarel wrote: post #130
pdimitar wrote: post #97

I can gloss over LISP's lack of static strong typing and if I force myself a bit, I can also ignore it not producing small efficient native binaries... but the lack of (semi-)transparent concurrency / parallelism is my deal-breaker. Multicore CPUs are a fact for life for a long time now. Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, a…

> static strong typing Alright, here is it: https://github.com/coalton-lang/coalton/ > small efficient native binaries The numbers are: with SBCL's core-compression, a web app with dozens on dependencies will weight ±30 to 40MB. This includes the compiler, the debugger, etc. Without core compression, we reach ±150MB. > The actor runtime? the actor library : https://github.com/mdbergmann/cl-gserver > couldn't find a w…

Thanks.

Re: Why Lisp?

#135

Post by Blackthorn »

varjag wrote: post #124
Blackthorn wrote: post #103

Earlier quoted context omitted.

I'd kill for common lisp with transparent green threads. It would be so great. As you noted once you use them you can never really go back. Of course, it will never happen because it can only be done in the compiler/runtime, not in a library, and the standard is frozen in stone, so that's that. I've got some hope for clojure with that at least, thanks to it being jvm hosted.

Back in the 1990s the usual in CL implementations was green threads. Everyone kinda wished for POSIX threads support instead, which was eventually gained on most runtimes. You can still see the glimpse of them as atavisms in old code and documentation.

I indeed saw this years ago mentioned in clozurecl's documentation. I was very upset that all the support for it got ripped out of the language, because as shown with https://blog.linuxplumbersconf.org/2013/ocw/proposals/1653 (which inspired what is now making its way into Java) this is the way to go for performant solutions with very very high thread counts.

Re: Why Lisp?

#136

Post by varjag »

dehrmann wrote: post #61

> The developers of Lisp give you the full powers that they had to develop the language. So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? > Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation You could say the same about Java and 2…

> You could say the same about Java and 20 years.

Really doubt you'll get your EJB project from the day going now without major rework.

Re: Why Lisp?

#137

Post by armitron »

eterevsky wrote: post #126
armitron wrote: post #119

Earlier quoted context omitted.

You are mistaken, CL is strongly typed.

Wikipedia says that it is optionally typed. Is it not so?

I don't see "optionally typed" anywhere in here: https://en.wikipedia.org/wiki/Common_Lisp

I do see "Typing Discipline: Dynamic, strong"

Re: Why Lisp?

#138

Post by packetlost »

pdimitar wrote: post #97

I can gloss over LISP's lack of static strong typing and if I force myself a bit, I can also ignore it not producing small efficient native binaries... but the lack of (semi-)transparent concurrency / parallelism is my deal-breaker. Multicore CPUs are a fact for life for a long time now. Where is the stuff like Erlang/Elixir's green threads or Golang's goroutines/channels and Rust's async runtimes workers/channels, a…

Gerbil Scheme has some of these: https://cons.io/

Re: Why Lisp?

#139

Post by vindarel »

7thaccount wrote: post #59
linguae wrote: post #50

Earlier quoted context omitted.

As a Lisp fan who sometimes codes in Scheme and Common Lisp whenever I get the chance, I agree with you. The gap has certainly narrowed in the past 20 or so years between Lisp and widely-used programming languages. In addition, the rise of statically-typed functional programming languages like OCaml and Haskell provide another alternative for those who love functional programming but want Hindley-Milner types. I stil…

I feel exactly the same. I wish I did something cool enough to require the full power of lisp, but generally speaking...I just need to glue some stuff together. Other people will have different needs though. I can still appreciate the beauty of lisp and I'm glad its out there in case I ever need it!

You don't need to do something super cool to use CL. Boring stuff works too. I use a small program in production© that reads a DB, formats data and sends it to FTP servers. Was a breeze to develop, is a breeze to deploy. It's a better experience overall for me than doing it in Python.

Oh, and I do use CL's super powers during development: interactive debugger, restarting a point in the stackframe, fast and incremental compilation, good type checks by SBCL… and I get a fast binary.

Learning didn't come without a few gotchas, but they're all better documented out there now.

Re: Why Lisp?

#140

Post by varjag »

Blackthorn wrote: post #135
varjag wrote: post #124

Earlier quoted context omitted.

Back in the 1990s the usual in CL implementations was green threads. Everyone kinda wished for POSIX threads support instead, which was eventually gained on most runtimes. You can still see the glimpse of them as atavisms in old code and documentation.

I indeed saw this years ago mentioned in clozurecl's documentation. I was very upset that all the support for it got ripped out of the language, because as shown with https://blog.linuxplumbersconf.org/2013/ocw/proposals/1653 (which inspired what is now making its way into Java) this is the way to go for performant solutions with very very high thread counts.

shrug I personally hate cooperative multitasking, and so far never ran into a problem that couldn't be scaled with system threads and use of select/poll. But am sure Google sees its uses.
Post reply on HN