Ecosystem: Why "No Rust Crates" Misses the Point
The third standard objection to SuperJ — after "no threads" and "no memory safety" — is "no ecosystem: Rust has crates, C++ has libraries, SuperJ has one SDK." The framing assumes an ecosystem is a source-level thing, and at that layer it's true: you can't cargo add a Rust crate into a SuperJ project and get its derive macros, its async desugaring, its trait-based dispatch.
But SuperJ is an LLVM language, and that changes the math.
The linkable ecosystem is the compiled ecosystem
SuperJ's native keyword links C ABI symbols — that's how runtime/*.c works today. Every other LLVM language (Rust, C, C++, Zig, Swift) can export extern "C" functions, which are just LLVM IR functions with the C calling convention. SuperJ links them the same way it links arena.c. You get the compiled, ABI-stable portion of every LLVM language's ecosystem for free:
- Crypto —
ring, BoringSSL, libsodium, libsecp256k1 (already linked by SuperJ's ownruntime/secp256k1.c). - Compression — zstd, lz4, zlib, brotli.
- Numerical kernels — BLAS/LAPACK, simde, OpenMP runtime.
- Parsers — the compiled core of any parser library (the macros and derives don't cross language boundaries — they don't cross any language boundary, not even to C).
- System bindings — anything with a C header is already linkable.
This is the part of an ecosystem that actually matters for linking. The part you don't get — serde's derive macros, tokio's async desugaring, axum's trait-based routing — is the ergonomic layer, which lives at the source language level and doesn't cross language boundaries in any direction (you can't use serde from C either). That layer is convenience, not capability: a Rust #[derive(Serialize)] produces a function that calls into the same serde core that you can link from SuperJ and invoke through a thin native wrapper.
The asymmetry that matters
Rust can link C, but Rust cannot link Rust crates from a non-Rust host — the macro/derive layer is a compile-time expansion that requires the Rust compiler. So the Rust ecosystem is monolingual at the ergonomic layer. SuperJ is multilingual at the link layer: anything that compiles to LLVM IR with a C ABI is a native declaration away. The "ecosystem advantage" reverses once you stop conflating the source-ergonomic layer with the linkable-capability layer.
What SuperJ's own SDK already covers
The SuperJ SDK isn't a token gesture — it covers the cases where the ergonomic layer would otherwise matter:
- Collections — primitive-specialized (
IntArrayList,Int2IntMap,Obj2ObjMap<K,V>,IntSet, …) avoiding the boxing a generic Java collection would impose. - JSON — a hand-written incremental parser, no derive macros needed.
- HTTP/1.1 — an incremental server with TLS 1.3.
- SEDA — the event-driven framework this manual is built around.
- Crypto — SHA256 (ARM NEON), Secp256k1 for blockchain.
- Math, Integer, Long, Short — full
java.lang.Mathequivalent.
The cases where you'd reach for a Rust crate are mostly the cases where the compiled core is linkable anyway: you want zstd, you link zstd. You want BLAS, you link BLAS. You want a specific parser, you link its compiled core. The SuperJ SDK covers the Java-ergonomic gap (collections, JSON, HTTP); the LLVM link layer covers the systems gap (everything else).
The honest remainder
What you genuinely can't get: a library that requires its source language's compile-time features to function at all — a Rust crate whose entire API surface is generated by a procedural macro, with no extern "C" fallback. Those exist but are rare; most real capability crypto, compression, numerical kernels, parsers has a C-ABI core underneath the ergonomic sugar. The ergonomic sugar is what you write yourself in SuperJ, and because SuperJ is Java-shaped, that sugar is cheap: a native declaration and a thin wrapper method. That's the cost of being a small ecosystem, and the LLVM link layer is what keeps it small rather than crippling.