Hacker News Reader

Comment by aapoalas | Hacker News Reader

Hi, main developer of Nova here if you want to ask any questions! I'm at a choir event for the rest of the week though, so my answers may tarry a bit.

View on HN

Have you been following Meta's work on Static Hermes? It's one of two efforts I'm aware of* to define a subset of JavaScript with different runtime semantics, by putting limitations on dynamic behavior. Their primary goal is performance, but correctness benefits also seem likely, and they share your idea that being intended for embedding in a particular application lets you get away with breaking compatibility in ways that you couldn't in a browser. And if their thing ships, and you want to reduce fragmentation, then maybe you want your "sane subset" to match theirs.

* The other being Google's Closure Compiler, which probably isn't relevant to you as it assumes that its output has to run on existing engines in browsers.

Thanks for the heads up, I hadn't realised that Static Hermes has the "sane subset" idea underpinning it! I had just thought it's an (somewhat) AoT JS compiler, like a mix between Porffor and V8. I'll have to look into their subsetting and indeed, match theirs as much as possible. Especially if they have written custom specification patches / versions.

Thank you so much <3

Given the fact that you were so precise in your time estimate on interleaved garbage collection, how long do you think it would take to get to 99% of the tests?

Haha, I think that was a one time fluke! :D

I'm aiming for something like 75-85% this year; basically get iterators properly done (they're in the engine but not very complete yet), implement ECMAScript modules, and then mostly focus on correctness, builtins, and performance improvements after that. 99% would perhaps be possible by the end of next year, barring unforeseeable surprises.

have you considered using js polyfills to help you get closer to 100% coverage and then replacing with native implementations prioritized by performance impact?

Not really, no. Its an interesting proposition, but for the most part I believe I'll be sticking it out the "hard way". The ECMAScript spec is fairly easy to read as well, after all. (Nevermind that I spent the single free hour I had today cursing at my incapability of understanding what is going wrong with my iterator code and what it even should do vis-à-vis the spec :D )

Gz on your grant! I must have missed the announcement, but working on OSS for a living (even for just a bit) would be super awesome.

Thank you! I've been a bit bad with announcing it; blog post was a month late and all that. But indeed, it's really cool to be able to do this for half a year!

This may be too early to ask, but are you targeting a near-v8 level of performance? Or more like quickjs or duktape?

Of course, and thank you for taking the time to ask!

For the foreseeable future the aim will be rather on the QuickJS/DuckTape level than beating V8. But! That is only because they need to be beat before V8 can be beaten :)

I'm not rushing to build a JIT, and I don't even have exact plans for one right now but I'm not barring it out either.

If my life, capabilities, and external support enable it then I do want Nova to either supplant existing mainstream engines, or inspire them to rethink at least some of their heap data structures. But of course it is fairly unlikely I will get there; I will simply try.

Did you consider other systems languages (such as Zig, etc) before settling on Rust? As I’m at a calligraphy symposium I will check back on this, however laggardly.

Not really, no. The main reason is that the origins of the Nova JavaScript engine as a project (without the ECS / data-oriented design focus, that came later) are in the Deno runtime's Discord where a friend joked "so when are we starting our own JS engine?" in response to someone jokingly complaining about Deno using V8 which is of course written in C++.

So the project started as a "let's write a better JS engine than V8 in Rust!" kind of joke. Beyond that, I personally wanted to write in Rust, and it turns out that with sufficient abuse[1], the Rust borrow checker can be used to perform GC safety checks at compile time. This means that Nova can avoid rooting a lot of values during runtime because at compile time the borrow checker has already ensured that those values will never be used after a GC safepoint.

This is something that would not be feasible in other languages without significant custom checking infrastructure. As an example, Firefox / SpiderMonkey has a custom linter that checks that "no-GC" functions cannot accidentally call back into "GC" functions, but it is roughly a full-program analysis task and the checker is hand-written, custom code that sometimes lacks special cases for this function or that. In Nova, a "GC" function takes a move-only "GcScope" parameter by value (and all GC-able Values observe that value; when the value gets moved to a child call, all those observing Values invalidate; this is that GC safety checking), and "no-GC" functions take a copy "NoGcScope" parameter that can be created from a "GcScope" and that again observes the "GcScope". Through these, the borrow checker becomes the checker for this logic.

[1]: https://fosdem.org/2025/schedule/event/fosdem-2025-4394-abus...

> sufficient abuse[1],

And `1` is?

Oops, sorry! https://fosdem.org/2025/schedule/event/fosdem-2025-4394-abus...

FYI I'm getting an SSL certificate error trying to load the site.

It's hosted by GitHub pages with Cloudflare DNS so any issues are probably related to that.

Reply on news.ycombinator.com