Isn't Lisp 5-20 times slower than C/C++/Rust (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...)? Performance is important for a browser.
Why Lisp?
101–110 of 339 posts
Re: Why Lisp?
#102I 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…
There are staticly typed and gradually typed lisps. Clojure also has a similar concurrency to go with channels.
Re: Why Lisp?
#103I 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…
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.
Re: Why Lisp?
#104Isn't Lisp 5-20 times slower than C/C++/Rust ( https://benchmarksgame-team.pages.debian.net/benchmarksgame/... )? Performance is important for a browser.
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.
Re: Why Lisp?
#105I 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…
There are staticly typed and gradually typed lisps. Clojure also has a similar concurrency to go with channels.
Clojure's core.async channel concurrency is nothing like go's. You need to wrap your concurrent block in a macro so it can code walk to find explicit blocking points. That means these points need to be marked, and can't be in already compiled functions. That's an enormous limitation. Compare to go's which just works, no caveat.
Re: Why Lisp?
#106the fact that there are repeated statements like "why X" where X = some language, points to rationalization more than reality; if the language is really so good, there won't be any need for a "why" articles on it. I haven't seen a repeated series of "Why C#" or "Why Go" or "Why Swift" articles. I also think Lisp is way overrated. Swift is based on Miranda which is based on Hope which borrows heavily from SML...There'…
I have seen those articles, also note, each of those languages is the product of and has the backing of giant corporations.
Re: Why Lisp?
#107I 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…
Clozure CL and Allegro CL have native threads. I think SBCL and Wraith Scheme do as well, but I'm not sure.
Re: Why Lisp?
#108I 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…
Clozure CL and Allegro CL have native threads. I think SBCL and Wraith Scheme do as well, but I'm not sure.
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.
Re: Why Lisp?
#109Earlier quoted context omitted.
Comparing it to C++ compilers... does Lisp have zero-cost abstractions?
It does, in form of a sane macro system with the full language available for use at compilation time - something that C++ never had and still doesn't have. No, consteval and constexpr aren't equivalent. No, CPP is not a sane macro system. No, don't even get me started about templates.
Portable CL is missing some key features for making zero cost abstractions such as unboxed arrays of structs.
Re: Why Lisp?
#110Earlier quoted context omitted.
It does, in form of a sane macro system with the full language available for use at compilation time - something that C++ never had and still doesn't have. No, consteval and constexpr aren't equivalent. No, CPP is not a sane macro system. No, don't even get me started about templates.
Portable CL is missing some key features for making zero cost abstractions such as unboxed arrays of structs.
Yes. That's a consequence of language design - unboxed arrays of structs mean no object identity, which means that operators like SETF and EQ no longer have their invariants satisfied when performing assignment to such arrays.