Our great sponsors
-
graalvm-clojure
This project contains a set of "hello world" projects to verify which Clojure libraries do actually compile and produce native images under GraalVM.
-
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)
-
-
Wren
The Wren Programming Language. Wren is a small, fast, class-based concurrent scripting language.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
Check out https://github.com/carp-lang/Carp
From the readme:
> The key features of Carp are the following:
> - Automatic and deterministic memory management (no garbage collector or VM)
> - Inferred static types for great speed and reliability
> - Ownership tracking enables a functional programming style while still using mutation of cache-friendly data structures under the hood
> - No hidden performance penalties – allocation and copying are explicit
> - Straightforward integration with existing C code
> - Lisp macros, compile time scripting and a helpful REPL
Caveat: I've barely used Go personally.
Just speculating on what GP specifically meant, but Go lacks the ability to pack structs, and probably lacks the equivalent of tricks like computed gotos [0] to increase bytecode interpreter speeds. In general, Go seems to (intentionally) lack a lot of low-level control of code generation, preferring a "there's one way to do things, and it either works, or it's a bug we'll fix" approach.
Which is probably for the best in "most" software, but interpreters typically use weird hacks to squeeze more performance out of the rock. Wren is a good example [1] of some of these optimizations, and has splendid comments/documentation.
[0] https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e...
[1] https://github.com/wren-lang/wren/blob/main/src/vm/wren_vm.c
Some clarification for those interested:
Joker is not a dialect of Clojure hosted on the Go runtime. Joker is a dialect of Clojure using its own interpreted runtime, that happens to be implemented in Go.
That means you cannot use Joker to build statically linked Go binaries and you cannot interop with Go from your own code.
And if you're interested in the idea of having an interpreted implementation of Clojure, for scripting use cases and fast startup, I would recommend you look into Babashka instead of Joker: https://github.com/babashka/babashka
Joker was the best interpreted Clojure prior to Babashka, and nowadays, I would recommend Babashka over Joker all the time.
The reason Babashka is better than Joker for this is that it is implemented in Java, so it can directly reuse the existing Clojure implementation and libraries as-is as part of its interpreter. That allowed it to quickly surpass Joker in the amount of Clojure features it support and libraries it exposes, and continue to quickly keep up with Clojure. I'd also say the main developer behind Babashka is more active.
Even though Babashka is implemented in Java, it is still a single statically linked binary runtime that starts extremely fast.
Kudos to Joker though for pioneering the idea and leading to Babashka.
Consider perhaps https://github.com/clasp-developers/clasp which is a common-lisp specifically designed to interop with C++.
I've recently started implementing a VM for Scheme [1] and was already envisioning to maybe add Clojure at some point. I'm writing it in plain C, since I don't see much reason to use C++ for the VM itself, and I like the simplicity and transparency of C. Also, I'm hoping to prove security at some point and C may make that easier (support from tooling like proof assistants). I don't think C++ would help enough to avoid security pitfalls by itself, unless one accepts the result to be very slow. But the VM does compile as C++, and complex data structures like HAMT may really better be written in C++, so I don't think I mind that. I think the approach to take for all speed-sensitive objects would be for them to be integrated directly with the GC (allocated from the GC heap, and traced via an object specific method).
Let me know if you'd like to discuss this more.
[1] https://github.com/pflanze/lilyvm