3 ms·
> obstacles add up I actually agree. It wasn't smooth for me to ship my first CL app. It's all better now (more tools, more documentation, more blog posts from
by vindarel 3y ago
> obstacles add up
I actually agree. It wasn't smooth for me to ship my first CL app. It's all better now (more tools, more documentation, more blog posts from several people, more SO questions and answers!).
> performant
SBCL is in the same ballpack of C, Rust or Java in many benchmarks.
In this article series, the author writes the same program in CL, Rust and Java. In fact, he copy-pastes a PG snippet from 30 years ago. This snippet beats Rust and Java in LOC and speed. But, yeah, he wasn't writing super efficient Rust code, so after many discussions, pull requests and sweating, the Rust code became the most performant. https://renato.athaydes.com/posts/revisiting-prechelt-paper-comparing-languages.html https://renato.athaydes.com/posts/revisiting-prechelt-paper-... It didn't take work to make the CL code performant, more so for the Rust one ;)
a benchmark after sb-simd vectorization: https://preview.redd.it/vn5juu36v2681.png?width=715&format=png&auto=webp&s=266dde2daf33c6767531fa635d436ac9657d63c8 https://preview.redd.it/vn5juu36v2681.png?width=715&format=p... (https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_amazing_sbcl_benchmark_speed_with_sbsimd/ https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_a...)
> good tools for networking, for writing concurrent or asynchronous code, for graphics,
I refer the reader to https://github.com/CodyReichert/awesome-cl https://github.com/CodyReichert/awesome-cl but yes, CL won't have the best libraries in some scenarii (GUI? Tk libs are good, we have Gtk4, a Qt5 library used in production© by a big player but difficult to install etc)
> it doesn't give you a good package manager or means of distributing code
Quicklisp is neat, with limitations, that can be addressed with Qlot, ql-https, or CLPM or the newest ocicl.
- the-alchemist 3y agoThese types of comparisons aren't "fair". As in most fields of engineering, programming languages/databases/etc. are about tradeoffs, and benchmarks aren't even more tricky. From the blog: > If you don’t have time: Rust can run much faster, but so can the other languages, and it turns out that the Java implementation might run faster than the Rust fastest implementation, according to the new benchmarks I’ve run after many Rust developers came to assist in making Rust faster. Common Lisp may have fallen behind, but that’s likely just because it was not nearly as optimized as the Java and Rust implementations were. The reason PHP, Ruby, Python, bash, etc. are popular are because of developer productivity, not performance. Also, it's a false dichotomy. Java uses `zlib` for its GZIP*Streams for performance reasons, and if there was a nice Rust library I wanted to use, I would just build a shared library and call it from Java, just like Java internally uses for `zlib`. Additionally, there's a fairly large difference in performance between C compilers. See clang, gcc, icc, etc., and the 100+ different options you can use when compiling something. It's not even close to "apples vs oranges", it's like more "apples vs fire trucks". :-P
- vindarel 3y agoHere's the follow-up with an optimized CL version: https://renato.athaydes.com/posts/revenge_of_lisp-part-2.html https://renato.athaydes.com/posts/revenge_of_lisp-part-2.htm... See the conclusion: - the CL version is the fastest of ALL… in certain conditions ;)