xuejie

Note: this involves blockchain VMs. If that's a dealbreaker, feel free to skip. I get it.

I've spent 8 years working on RISC-V VMs for blockchains, recently also contributing to ZK VMs. Modern blockchain VMs are drastically more powerful, and I'm curious how far we can push them. I started porting real game logic to blockchain VMs, running game loop, physics simulation, collision detection, etc., on blockchain VMs. So far I have:

* Teeworlds to CKB-VM: https://xuejie.space/2026_06_16_teeworlds_on_ckb/

* One Hour One Life to CKB-VM: https://xuejie.space/2026_06_29_porting_one_hour_one_life_ga...

* A small ray tracer to Jolt ZK VM: https://xuejie.space/2026_07_10_cpp_ray_tracer_on_jolt_zk_vm...

Source is available for 2 of the 3, I need to clean up the OHOL one.

Some context: CKB-VM [1] is a RISC-V virtual machine I designed for Nervos starting in 2018. Jolt ZK VM [2] is a zero-knowledge virtual machine developed by a16z. Both execute RISC-V code, but due to different design, Jolt ZK VM is a much faster CPU than CKB-VM.

Technically this is a fun challenge. Many techniques I used resemble game development tricks from the 90s on game consoles: fixed point math, banked memory in ROMs, aggressively inlining tricks, etc. I want to push to see where the ceiling is. Right now I'm trying to get a Godot [3] + JoltPhysics [4] game loop running on Jolt ZK VM.

Happy to answer questions about the VM internals, the porting process, or anything in general.

[1] https://github.com/nervosnetwork/ckb-vm

[2] https://jolt.a16zcrypto.com/

[3] https://godotengine.org/

[4] https://github.com/jrouwe/JoltPhysics

Just provide a not-related-at-all but IMHO still interesting case: I used to have a Kioxia CM6 U2 SSD drive, it would pass all sorts of benchmarks the reseller is willing to run, but whenever I tried to clean-compile Rust on it, the drive would fail almost certainly somewhere in the build process. While there are configurations you can compile Rust using pre-built LLVM, in my tests I'm compiling LLVM along the way. So I can agree with the comment here, there might be some unique property when doing multi-core compilations, though my tests show a potentially faulty drive, while the above comment here is about Intel CPU.

Like other comments here, just want to say thank you for this amazing editor! It has been my primary code editor for the past few years. I did use a few different editors for specific purposes(vscode for interactively proving coq code, joe/nvi for editing super large files), but micro does provide what I need in 90% of the cases :P

I've been using micro as my main code editor(well I do use vscode for writing coq but that's the only exception) after 10+ years' time with emacs. I simply treat micro as the modern compromised version of acme. It almost has all the features to support the core idea of acme, I have written a plugin to exploit this direction: https://github.com/xxuejie/micro-acme So far it has been working perfectly for me.

Also a fan of structural regular expressions in the exact same shoes that every time when I try to use it it's an unpleasant experience. Maybe I'm just not good enough at it.

That being said, I've been recently employing comby (https://comby.dev/) in my workflow, which solves similar problem, but understands certain languages to simplify the usage.

> The Raspberry Pi 4 is THE cheapest 2Gflops/W computer ever made and probably that will ever be made in the future too!

Can you expand on this one? I was curious why you think there probably will not be a cheaper one in the future with similar or better specs.

Reminds me of the first version of Redis in tcl: https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e...

IMO such a category existed for quite a long time, JVM and .NET all falls into this category. Yes WASM has its fame for becoming a browser standard, but fundamentally, there is very little difference between WASM and JVM.

Personally, I already pulled the trigger 2 years ago when I first starting to write Rust professionally. A laptop just becomes far tooooo noisy compiling Rust code. These days I use 3 machines:

* A fanless Chromebook with decent screen for travel use

* An Intel NUC that is hooked to a big monitor, which is also the device I'm typing this on

* A beefy Ryzen desktop that sits in the corner of my balcony, which I usually connect via ssh and perform all the heavy tasks

To me I'm getting all the benefits of each computer, and the combined cost is still less than a so-called macbook pro :)

> I feel like the plethora of (partially incompatible) extensions make the language very complicated and messy. There is no single Haskell. Each file can be GHC Haskell with OverloadedStrings or GADTs or ....

Aren't macros, especially proc macros these days in Rust having the same effect? Personally I feel like this is a tradeoff every language has to play with: you either limit to a special way of writing, or adding some sort of ad-hoc system that enables rewriting syntax and even to a degree, semantics.

Thanks guys for the explanation! I truly have misunderstood this post.

The author first goes with:

> Idris 1 is implemented in Haskell, but that has little (if anything) to do with the difference.

But latter they also go on to say:

> Idris 2 benefits from a robust, well-engineered and optimised run time system, by compiling to Chez Scheme.

I must say I'm slightly confused here. Yes a rewrite might also enable to avoid all the legacy part that might slow down the code, but what is also possible, is that a new language and a new runtime could enable new optimizations that are not possible before. The author did mention Chez's profiling tools help a lot in the rewrite. So I was curious: is it really true, that we cannot attribute some part of the speedup to language differences?

Also I was interested in the rationale behind using Scheme to replace Haskell, but I failed to find some reasoning behind this, anyone can shed some light on this?

I used to have a similar opinion, that it requires a special language to leverage such power. But recently I've discovered that Rust, with its latest advancement in async/await design together with swappable runtime, can provide a decent story for building determinism tests like described in the video. Yes of course one still needs to mock all the IO as well as clock part, but the deterministic core is already there, and with a carefully designed runtime and surrounding library, we might have pretty good support in Rust for this.

Disclaimer: I'm never a Rust zealot, I do understand Rust has its tradeoffs, and it's not the panacea for every problem. In fact I do have side projects which are perfectly suited and written in Go. I'm just saying Rust's design turns out to be suitable for such a deterministic testing structure, and Rust's target for system programming, can also benefit A LOT from this style of testing.

And also a shameless plug: I do have some initial work exploring this area: https://github.com/xxuejie/diviner. It's still quite rough and a lot of work is needed but I do believe this is something that is worth exploring.

While I certainly agree a Standard ML compiler can be quite useful(and huge respect for the author!), I noticed the compiler is purely written from scratch, and the question remains when the quality of generated code can be as decent as BuckleScript behind ReasonML. Unless SML fits well with the model of WASM(which I believe is not the case), significant work will be required to tweak the compiler.

Crystal is indeed a very nice language, but the only thing that is holding me from using it greatly, is that it still uses the Boehm GC, which makes it hard to compete with other languages in a production setting.

I understand we might get there one day but I'm afraid this is taking far too long.

Does the fact that ARM is a bad choice disproves all other choices other than WASM? I'm not sure this is a good argument here. Lower-level bytecodes are more flourishing than just ARM.

Personally I don't see why we cannot get all three.

There's nothing wrong with LLVM itself, my point is we could've picked a lower level model which don't need a complicated setup like LLVM. Or one that you can direct shipped optimized compiled result of LLVM, that will be a much better world

That is their very nice slogan, while in reality WASM still has quite a way to go to compete with native code.

Some shits I see these days are that when code speed is measured, people compare that with JS but not native code, when portability is talked about, the comparison is then made against native code, not JS.

wasmer [1] has a LLVM backend, WAVM [2] uses LLVM as the bakend, I could be wrong but last time I checked, cranelift is only meant to be the next generation WASM engine used in Firefox, it is not yet in production.

And actually the argument is: all of v8, Firefox/Cranelift and LLVM used in wasmer requires non-trivial work to make WASM fast, which shouldn't be needed given a different model.

[1] https://github.com/wasmerio/wasmer/tree/master/lib/llvm-back... [2] https://github.com/WAVM/WAVM

No I'm not talking about register-based vs stack-based VM, that's a totally different topic. I'm just saying WASM is still quite distant from real hardware, making it a non-trivial task to performantly run the code. In fact if you look at the asm.js, which is the original inspiration of WASM, it is a much closer mode to real hardware.

And of course JIT can make WASM fast but if you look around, building a performant WASM JIT still remains terribly hard, some implementation even needs LLVM to perform optimizations. I'd say if this is the case, we must've chosen the wrong model.

I totally agree that it's not the best tech always wins, that's why I'm pointing it out, I really wish that 5 years from now, we can rely on something that makes sense to be there, not just because something has a low cost of adoption.

While I do agree WASM makes a lot of sense for the Web, I personally am having doubts regarding treating WASM as a general abstractions for native code as used in the post. For this case, it might suit the job better to have a bytecode that resembles more of underlying machine architecture, rather than a still highly abstracted model like WASM. Please don't get me wrong, I do agree WASM is already one step ahead of, say, JavaScript, but we can do better than that.

The problem with WASM here, is that it really is a bloated model like JVM in its early days, huge amount of work is needed to make it closer to native speed, which is contradictory to the original slogan. What's more, people are still planning to add tons of new features to it: https://webassembly.org/docs/future-features/. Before you tell me those are opt-in features, the question I want to raise is: for an abstraction of general platform, you would definitely want to have a widely accepted standard so people know what features will be expected, one example is that people know SSE will be available for 64-bit x86 code.

With all those opt-in features, I doubt if we can have a proper layer that adapts well to different implementations with different supported features. We might end up with the situation like Rust, where you can claim a secondary compiler could exist, but in practice people are all using the same compiler/implementation.

Any chance you can elaborate the reasons for staying away from Intel syntax?

This is indeed amazing! But I was wondering if it's possible to compile the whole TeXmacs into WebAssembly and have it in the browser. That will be a totally different world.

This is really depending on your view, but the moment you step outside of lists and use arrays, you are keeping modern CPU architecture in mind. And all of a sudden all those wonder car/cdr/cons concepts as well as things built upon it no longer holds, which, again depending on the view, actually harms the abstractions in Lisp, and we are actually back at the same page with all the other programming languages.

Also, when you are promoting something, it might not a good idea to compare against Python when it comes to speed, but when talking maintainability, only C is talking as a target here.

Although I do agree data flow programming can be useful sometimes, it has been pointed out that data oriented design is not about data flow: https://sites.google.com/site/macton/home/onwhydodisntamodel...

And taking from the other side of the view, even when you consider high performance data flow programming, there're great people pointing out going functional might not be a very good idea: https://www.freelists.org/post/luajit/Ramblings-on-languages...

> about 20x+ faster than Python, too; speed in the same order of magnitude than C.

I think this is exactly into parent thread's point: yes the performance can be great but you need to tail the code for the hardware, which is niche and the beautiful abstraction might never hold anymore

Nightly Rust already has basic RISC-V support, but the problem is Rust's libc binding is not yet ported to RISC-V. Without libc, Rust's std will not be usable, that's the main blocker here. While the theory is you don't require std to compile a Rust program, most, if not all, Rust programs leverage std in some extent.

I'm confused here, Quill has a a very nice OT solution built-in to solve collaborative issue: https://github.com/quilljs/delta

Why not leverage that solution than just saying OT is incorrect and roll out a rudimentary solution? CRDT is not something easier, OT and CRDT are just 2 different beasts with different trade-offs.