-
-
pil21
PicoLisp is an open source Lisp dialect. It is based on LLVM and compiles and runs on any 64-bit POSIX system. Its most prominent features are simplicity and minimalism.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
immer
Postmodern immutable and persistent data structures for C++ — value semantics at scale (by arximboldi)
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
This looks so cool!
It does look like it has some technical similarities to Julia, with the LLVM JIT and such. It'd be great to see some benchmarks.
Also see the GitHub[0], which looks like the author put a ton of work into this. Very impressive.
That said, looking at the progress page[1], this is still far from achieving 100% feature parity. I'll be following it closely with my fingers crossed though.
[0]: https://github.com/jeaye/jank
[1]: https://jank-lang.org/progress/
Why not use something like https://github.com/ruricolist/cloture (a Clojure "adapter" that runs on Common Lisp) if you want that?
See also babashka, a native Clojure implementation for scripting. https://github.com/babashka/babashka
jank is currently using immer for persistent data structures: https://github.com/arximboldi/immer
Very much inspired by Clojure, with a lot of time put into benchmarking and profiling.
It's too early for me to share numbers on jank vs Clojure itself, especially due to the rewrite, but my earlier jank versions were definitely competitive with AOT compiled Clojure jars.
CLASP? CL on LLVM.
https://github.com/clasp-developers/clasp/
> Clasp is a new Common Lisp implementation that seamlessly interoperates with C++ libraries and programs using LLVM for compilation to native code. This allows Clasp to take advantage of a vast array of preexisting libraries and programs, such as out of the scientific computing ecosystem. Embedding them in a Common Lisp environment allows you to make use of rapid prototyping, incremental development, and other capabilities that make it a powerful language.
A dynamically typed Lisp has virtually nothing in common with Rust.
Also, Rust binaries have been of comparable size in the past. Check out this question where someone asks why Hello World is 3mb even in release mode:
https://stackoverflow.com/questions/29008127/why-are-rust-ex...
This 3mb doesn't have any cached heap, doesn't have any garbage collector, doesn't have support for high quality exceptions and doesn't have much in the way of a cross platform abstraction, whereas the Clojure-as-native binary has all of those and more.
There's a giant pile of things you can do here to try and reduce Rust's binary size:
https://github.com/johnthagen/min-sized-rust
... but as you can see, it's a lot of work.
Rust gets great press and HN is flooded with "let's do it in Rust" type comments. But I think sometimes we need a reality check. Rust is an extremely different language to most others, even C. The combination of the borrow checker+everything async is not obviously better than everything else, not even in the low level domains even though Rust is deservedly picking up loyal users there. The moment you care about development speed i.e. for the sort of apps Clojure was designed for, you're going to be better off with a GC and a strong runtime that abstracts the platform well.