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

141–150 of 339 posts

Re: Why Lisp?

#141

Post by vindarel »

eterevsky wrote: post #101

Isn't Lisp 5-20 times slower than C/C++/Rust ( https://benchmarksgame-team.pages.debian.net/benchmarksgame/... )? Performance is important for a browser.

(they are using Webkit for the browser)

funny story on Lisp's performance (compared to Java and Rust): https://renato.athaydes.com/posts/revisiting-prechelt-paper-... CL was beating Rust out of the water (in speed) with its un-optimized algorithm, that the post author copied from a Lisp manual. After much sweating, Rust eventually beat CL's version.

Re: Why Lisp?

#142

Post by hajile »

leethomas wrote: post #91

I like lisps syntactically. The only thing stopping me from using it more frequently is the lack of static typing. I wasn't always a stickler for static typing, but I've spent a lot of time working with Scala and TS and the main advantage for me is ease of refactoring and avoiding NPEs. EDIT: What I'm continuously evaluating for myself is Clojure specifically

Check out Coalton.

Re: Why Lisp?

#143

Post by vindarel »

eterevsky wrote: post #111
lisper wrote: post #104

Earlier quoted context omitted.

It depends on how you write the code and the compiler you use, but Lisp can be as fast as if not faster than C. But the main thing is that in Lisp it's easy to turn the dial between speed and other things you might want to optimize for like safety and debugability. Making C code memory safe is a lot of work at best, and actually impossible at worst.

You could write safe-ish C++ and Rust that is both readable and fast. Could you point me to some benchmarks of Lisp being comparable to C? Also, unless I am mistaken, Common Lisp doesn't have strong types. How can you make either fast or safe language without compiler knowing the types?

SBCL (the implementation) gives us pretty useful type errors and warnings. It is not "fully typed" (see Coalton for a Haskell-in-Lisp) but very useful anyways: it warns on a function arguments not having the right types, stuff like this. The nice part is that we get these warnings instantly, since we compile the code function by function. We can add type declarations, that help the compiler further infer types, throw more warnings, and optimize code.

Re: Why Lisp?

#144

Post by lisper »

pdimitar wrote: post #122
lisper wrote: post #118

Earlier quoted context omitted.

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…

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…

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

Re: Why Lisp?

#145

Post by erik_seaberg »

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…

We should be optimizing for committed experts to work and communicate concisely, not occasional drive-by contributors.

Re: Why Lisp?

#146

Post by pdimitar »

lisper wrote: post #144
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…

> 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/Elix…

> you can do those things in Lisp too

Well if you can that would be a huge step. Gotta check again it seems.

Re: Why Lisp?

#148

Post by Paul-Craft »

lispm wrote: post #132
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…

It's funny, even Emacs lisp has threads now: https://www.gnu.org/software/emacs/manual/html_node/elisp/Th...

Re: Why Lisp?

#149

Post by pdimitar »

varjag wrote: post #140
Blackthorn wrote: post #135

Earlier quoted context omitted.

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.

Web backends. BEAM VM's green threads work excellently for it, you can handle bursty workloads transparently and all you will pay for it is slightly increased latency (and I really mean slightly).

I know, many people claim Ruby [on Rails] and Python [Django] do the same but I've seen APM dashboards of such projects and those of Elixir [Phoenix] and Golang [various, most recently GoFiber] apps and the difference is pretty stark.

But if you mean the golden path of select/poll then yeah, hard to beat those on their own turf of course.

Re: Why Lisp?

#150

Post by lisper »

pdimitar wrote: post #146
lisper wrote: post #144

Earlier quoted context omitted.

> 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/Elix…

> you can do those things in Lisp too Well if you can that would be a huge step. Gotta check again it seems.

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.
Post reply on HN