GraalJS as an alternate to bun #12655
Replies: 1 comment 6 replies
|
Hey @ivan-velikanov. This is a good idea. Such a good idea that we are building exactly that, it is called Elide. A portion of Elide is open source if you'd like to see how we architected our approach. But, Elide is specifically designed as "Bun for JVM," sort of:
Later, we do intend to open source the full thing, and it's possible to obtain a license which allows source access so you can contribute. The EAP version is free forever and can be downloaded at Anyway, if this stuff interests you, we have a Discord that is open to anyone. We are always looking for ideas and feedback! P.S. We are able to beat Bun in some notable benchmarks, even startup time. I have actually witnessed GraalJs start up as fast as 3ms before, which is incredible (Bun manages 6ms at best on Linux amd64). This kind of use style requires some serious tuning, but it is possible. It isn't the case yet, but it is possible that someday Elide (GraalJs + GraalPython) could beat both Bun and CPython startup time, at least on Linux. Mac would be harder, but we are working on that too. Mac performance for Python is currently on-par (I think last benchmark was ~1.05x CPython) but Bun is much smaller on disk and thus enjoys startup benefits as a result. |
|
@ivan-velikanov Hey, thanks! I am happy to accept ideas as simple inputs :) sure, I think we could add a |
We run in native mode, of course, so, Elide is a Native Image, not a JVM. Memory usage, in terms of floor, can be quite low in this mode. I haven't tried running Claude Code on native GraalJs; I'll have to see if I can give that a shot. |
|
Here is an example benchmark, which tests (Benchmark taken on |
|
my guess is, rather my hypothesis is, or i should say proposition is, if they can sell bun to anthropic saying it is twice as fast as nodejs (yes i am simplifying things but accept this simplification for sake of argument), then if you can give a claude code native exe which is faster or somehow better, then you showcase potential acquisition to anthropic, and if not anthropic, then to someone out there in market, and if no one is still interested, you still have a value proposition which is bound to interest people to atleast consider and give it a try. more than that it is a lot of hard work and quality which the developers deliver. and ofcourse i don't know the licensing term complications. Even if we don't go along those routes, even just for marketing it is a good comparison to show people to take a note. This is fair and reasonable thing to look at. |
not only that, elide could be a jvm that jbang installs. an integration into jbang ecosystem. if we could do a simple standard installation, where we have some 1Mb-2Mb setup files, which install elide once in a proper shared location (shared with jbang also), then subsequent installation will not each install their own jvms. this makes distribution ligther, smaller, standardized and cohesive. Today there are n ways to do it, but they just bloat the harddisk. i felt convergence with jbang made sense, because it is the most light weight entry front. all these things, integration with maven, integration of different languages and their tools (npm and python ecosystem) and on top of that integration with jbang and standard installation discipline ... all these are my personal thoughts of how overall things can be harmonized ... something which i am just thinking, but you have already delivered. jbang in this equation is a low effort feature. But i wanted to point out to the other aspects of standard installation directory and shared jvms etc, small distributions, all these things .... that would make the jvm ecosystem look very native-like; further integration with other tools, gives a very swiss army knife feeling. i hope i was able to communicate the picture in my mind fully. what to say you already have done it. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
For a long time I've wondered: could GraalVM compete with Bun? This feels more relevant now that Bun was acquired by Anthropic.
Using Claude Code on Bun, I noticed it's memory-heavy but produces nice single executables. Bun's
bun buildfeels cleaner than GraalVM's native-image (no MSVC dependency on Windows).I've also wondered: could there be a polyglot GraalVM tool like Bun - not just for Node.js but Python and Java too? A "GUN" (GraalVM Universal Node... just kidding 😄). With all that polyglot/AOT power, where does GraalVM head if not providing better alternatives?
Disclaimer: These benchmarks were generated with AI assistance (Claude). While I monitored and corrected issues along the way, I'm not an expert - please take results with appropriate skepticism!
Quick Observations
If GraalVM instances could share memory via CDS/AOT caching, this overhead might be justified. But currently it's significant.
Benchmark Results Summary
Runtimes Tested (All with JIT warmup)
Key Test Results (After Warmup)
⭐ TeaVM WASM surprisingly beats everyone on object creation!
GraalVM vs Bun Detailed Comparison
Cold Start
After JIT Warmup (10+ iterations)
Consistency
Memory & Startup
My Humble Suggestions
GraalVM should benchmark against Bun, not just Node.js - Bun is the new performance bar
Consider TeaVM collaboration - TeaVM WASM performed surprisingly well (4.4x slower than Java, similar to GraalVM). Perhaps symbiotic development could benefit both projects? Just as Anthropic acquired Bun...
Java ecosystem is mature - Incremental JDK improvements are welcome but the exciting frontier is JavaScript/WASM. GraalVM's future outside JVM seems to be competing in that space
Caveats
Test Environment
TL;DR: Native Java JVM wins overall. Bun is 2.45x faster than GraalVM after warmup. TeaVM WASM is surprisingly competitive. Perhaps GraalVM could learn from or collaborate with these projects?
Benchmarks code and testing done with AI assistance - corrections and scepticism welcome!
All reactions