[HN Gopher] Brimstone: ES2025 JavaScript engine written in Rust
___________________________________________________________________
Brimstone: ES2025 JavaScript engine written in Rust
Author : ivankra
Score : 180 points
Date : 2025-11-16 11:41 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| maxloh wrote:
| Could you compare it with Boa? It is written in Rust too.
|
| https://github.com/boa-dev/boa
| ivankra wrote:
| I have some benchmark results here:
| https://ivankra.github.io/javascript-zoo/?v8=true
|
| It's impressively compliant, considering it's just a one man
| project! Almost as fully featured as Boa, plus or minus a few
| things. And generally faster too, almost double the speed of
| Boa on some benchmarks.
| mrec wrote:
| Surprised at the lack of a license though.
| nicoburns wrote:
| Interesting. Hermes and QuickJS both come out looking very
| good in these (in terms of performance vs. binary size)
| lucideer wrote:
| First time seeing a few of the engines listed here - based on
| this table I'm surprised Samsung's Escargot hasn't gotten
| more attention. LGPL, 100% ES2016+ compliance, top 10 perf
| ranking, 25% the size of V8 & only 318 Github stars.
|
| A quick HN search shows 0 comments for Escargot - is there
| some hidden problem with this engine not covered in this
| table?
| evilduck wrote:
| Because it pretty much only makes sense for Samsung TVs and
| smart appliances since it scores 3% on the benchmarks vs
| V8.
|
| It's too big for most embedded devices, too slow for
| general computing, and if you can run something 25% the
| size of V8, you can probably just run V8. If for some
| reason that size and speed profile does fit your niche and
| you aren't Samsung wanting to use their own software, then
| Facebook's Hermes looks better in terms of licensing, speed
| and binary size and writing compatible JS for it isn't that
| hard.
| cluckindan wrote:
| Memory safety is one of Rust's biggest selling points. It's a bit
| baffling that this engine would _choose_ to implement unsafe
| garbage collection.
| swiftcoder wrote:
| The whole point of unsafe is to be able to circumvent the
| guardrails where the developer knows something the compiler
| isn't (yet) smart enough to understand. It's likely that
| implementing a high-performance GC runs afoul of quite a few of
| those edge cases.
| scratcheee wrote:
| The obvious use-case for unsafe is to implement alternative
| memory regimes that don't exist in rust already, so you can
| write safe abstractions over them.
|
| Rust doesn't have the kind of high performance garbage
| collection you'd want for this, so starting with unsafe makes
| perfect sense to me. Hopefully they keep the unsafe layer small
| to minimise mistakes, but it seems reasonable to me.
| amelius wrote:
| I'm curious if it can be done in Rust entirely though. Maybe
| some assembly instructions are required e.g. for trapping or
| setting memory fences.
| nicoburns wrote:
| If it comes to it then Rust has excellent support for
| inline assembly
| amelius wrote:
| But how well does it play with memory fences?
| steveklabnik wrote:
| You don't even need inline assembly for those
| https://doc.rust-
| lang.org/stable/std/sync/atomic/fn.fence.ht...
| nicoburns wrote:
| Even using something as simple as Vec means using `unsafe` code
| (from the std library). The idea isn't to have no `unsafe` code
| (which is impossible). It's to limit it to small sections of
| your code that are much more easily verifiable.
|
| For some use cases, that means that "user code" can have no
| `unsafe`. But implementing a GC is very much not one of those.
| jeroenhd wrote:
| Rust also has some nice language features. Even unsafe rust
| doesn't have the huge "undefined behaviour" surface that
| languages like C++ still contain.
|
| If I were to write a toy JS runtime in Rust, I'd try to make it
| as safe as possible and deal with unsafe only when optimization
| starts to become necessary, but it's not like that's the only
| way to use Rust.
| LtdJorge wrote:
| That's the philosophy. Use the less constrained (but still
| somewhat constrained and borrow checked) unsafe to wrap/build
| the low level stuff, and expose a safe public API. That way
| you limit the exposure of human errors in unsafe code to a
| few key parts that can be well understood and tested.
| the__alchemist wrote:
| IMO the memory safety aspect is overblown by enthusiasts and
| purists. Rust is an overall nice fast imperative language.
| phplovesong wrote:
| Rust WAS really nice before it got mangled with syntax like
| we never seen before. Graydon did not imagine rust as what it
| is today. Rust core wo. async is ok, but in practice rust
| projects tend to have hundreds of deps and really slow
| compiles. Its just like javascript with npm.
| swiftcoder wrote:
| > in practice rust projects tend to have hundreds of deps
|
| That's really just any language with a built-in package
| manager. Go somewhat sidesteps this by making you vendor
| your dependencies, but very few other languages escape the
| ballooning dependency graph.
| phplovesong wrote:
| Go has probably more packages than Rust, but i rarely see
| Go projects that use as many as rust. In Go the usuals
| are depending on the app, possibly some db drivers, a
| simple router and maybe some crypto related thing. Most
| projects do fine with just the stdlib. In rust i tend to
| see 100 deps, and 1000 transient deps. Compile times are
| not in seconds, but minutes.
| swiftcoder wrote:
| You _can_ do that just fine in Rust too, for example the
| Makepad[1] developers take a pretty extreme non-invented-
| here stance, and builds a full UI toolkit with no
| external dependencies (and a major focus on clean-build
| compile times).
|
| However, it isn't really part of the Rust OSS culture to
| operate like that. The culture typically values safety
| over compile times, and prefers to lean on a deep stable
| of battle-hardened abstractions.
|
| [1]: https://makepad.nl,
| https://github.com/makepad/makepad
| the__alchemist wrote:
| This is a concern when viewing the Rust experience. It can
| be avoided by judiciously choosing dependencies that you
| need, and that have shallow trees of their own. I like to
| distinguish _the rust lang_ from _The rust OSS community_.
| They overlap, but can be treated separately if you exercise
| case.
| VerifiedReports wrote:
| "like we never seen"?
| boianmihailov wrote:
| "Compacting garbage collector, written in very unsafe Rust" got
| me cracking.
| varispeed wrote:
| Sorry for the offtop, but I really miss the cracktros. Imagine
| having Ikari intro before you boot into your OS.
| vardump wrote:
| Sorry also for being offtopic, but "cracking" in this case
| most likely refers to cracking [with laughter].
| BoredPositron wrote:
| Plymouth let's you do it on Linux without hacking around like
| osx or windows.
| bcardarella wrote:
| Just a small comparison, compiled for release:
|
| Boa: 23M Brimstone: 6.3M
|
| I don't know if closing the gap on features with Boa and
| hardening for production use will also bloat the compilation
| size. Regardless, for passing 97% of the spec at this size is
| pretty impressive.
| embedding-shape wrote:
| Is that with any other size optimizations? I think by default,
| most of them (like codegen-units=1, remove panic handling, etc)
| are tuned for performance, not binary size, so might want to
| look into if the results are different if you change them.
| LtdJorge wrote:
| Stripping can save a huge amount of binary size, there's lots
| of formatting code added for println! and family, stacktrace
| printing, etc. However, you lose those niceties if stripping
| at that level.
| bcardarella wrote:
| I only ran both with `cargo build --release`
| jerf wrote:
| It looks like Boa has Unicode tables compiled inside of itself:
| https://github.com/boa-dev/boa/tree/main/core/icu_provider
|
| Brimstone does not appear to.
|
| That covers the vast bulk of the difference. The ICU data is
| about 10.7MB in the source (boa/core/icu_provider) and may grow
| or shrink by some amount in the compiling.
|
| I'm not saying it's _all_ the difference, just the bulk.
|
| There's a few reasons why svelte little executables with small
| library backings aren't possible anymore, and it isn't just
| ambient undefined "bloat". Unicode is a big one. Correct
| handling of unicode involves megabytes of tables and data that
| have to live somewhere, whether it's a linked library, compiled
| in, tables on disks, whatever. If a program touches text and it
| needs to handle it correctly rather than just passing it
| through, there's a minimum size for that now.
| twoodfin wrote:
| As well-defined as Unicode is, surprising that no one has
| tried to replace ICU with a better mousetrap.
|
| Not to say ICU isn't a nice bit of engineering. The table
| builds in particular I recall having some great hacks.
| necovek wrote:
| POSIX systems actually have their own approach with
| "locales" and I it predates Unicode and ICU.
|
| Unfortunately, for a long time, POSIX system were uncommon
| on desktops, and most Unices do not provide a clean way to
| extend it from userland (though I believe GNU libc does).
| rixed wrote:
| I was currious to see what that data consisted of and
| aparently that's a lot of translations, like the name of all
| possible calendar formats in all possible languages, etc.
| This seems useless in the vast majority of use cases,
| including that of a JS interpreter. Looks to me like the
| typical output of a comitee that's looking too hard to extend
| its domain.
|
| Disclaimer: I never liked unicode specs.
| necovek wrote:
| Unicode is an attempt to encode the world's languages:
| there is not much to like or dislike about it, it only
| represents the reality. Sure, it has a number of weird
| details, butnif anything, it's due to the desire to
| simplify it (like Han unification or normal forms).
|
| Any language runtime wanting to provide date/time and
| string parsing functions needs access to the Unicode
| database (or something of comparable complexity and size).
|
| Saying "I don't like Unicode" is like saying "I don't like
| the linguistic diversity in the world": I mean sure, OK,
| but it's still there and it exists.
|
| Though note that date-time, currency, number, street etc.
| formatting is not "Unicode" even if provided by ICU: this
| is similarly defined by POSIX as "locales", anf GNU libc
| probably has the richest collection of locales outside of
| ICU.
|
| There are also many non-Unicode collation tables (think
| phonebook ordering that's different for each country and
| language): so no good sort() without those either.
| xeonmc wrote:
| Does that include emojis?
| jcranmer wrote:
| Emojis are complicated from a font rendering perspective.
| But from a string processing perspective, they're
| generally going to be among the simplest characters: they
| don't have a lot of complex properties with a lot of
| variation between individual characters. Compare
| something like the basic Latin characters, where the
| mappings for precomposed characters are going to vary
| wildly from 'a' to 'b' to 'c', etc., whereas the list of
| precomposed characters for the emoji blocks amounts to
| "none."
| necovek wrote:
| Agreed!
|
| FWIW, they are not even "complicated" from a font
| rendering perspective: they're simple non-combining
| characters and they are probably never used in ligatures
| either (though nothing really stops you; just like you
| can have locale-specific variants with locl tables). It's
| basically "draw whatever is in a font at this codepoint".
|
| Yes, if you want to call them out based on Unicode names,
| you need to have them in the database, and there are many
| of them, so a font needs to have them all, but really,
| they are the simplest of characters Unicode could have.
| nicoburns wrote:
| "draw whatever is in a font at this codepoint" is doing
| quite a lot of work there. Some emoji fonts just embed a
| PNG which is easy. But COLRv1 fonts define an entire
| vector graphics imaging model which is similar what you
| need to render an SVG.
| kibwen wrote:
| Yes, but at this point we're completely outside the scope
| of Unicode, which has nothing to do with how anything
| actually gets drawn to the screen.
| overfeed wrote:
| > they're simple non-combining characters
|
| Skin-tone emoji's are combined characters: base emoji +
| tone.
| ambicapter wrote:
| Unicode is everywhere though. You'd think there'd be much
| greater availability of those tables and data and that people
| wouldn't need to bundle it in their executables.
| nicoburns wrote:
| Unfortunately operating systems don't make the raw unicode
| data available (they only offer APIs to query it in various
| ways). Until they do we all have to ship it seperately.
| jancsika wrote:
| If someone builds, say, a Korean website and needs sort(),
| does the ICU monolith handle 100% of the common cases?
|
| (Or substitute for Korean the language that has the largest
| amount of "stuff" in the ICU monolith.)
| adzm wrote:
| Yes, though it's easy to not use the ICU library properly
| or run into issues wrt normalization etc
| HansHalverson wrote:
| Brimstone does embed Unicode tables, but a smaller set than
| Boa embeds: https://github.com/Hans-
| Halverson/brimstone/tree/master/icu.
|
| Brimstone does try to use the minimal set of Unicode data
| needed for the language itself. But I imagine much of the
| difference with Boa is because of Boa's support for the
| ECMA-402 Internationalization API (https://tc39.es/ecma402/).
| nekevss wrote:
| Yeah, the majority of the difference is from the Unicode
| data for Intl along with probably the timezone data for
| Temporal.
| nicoburns wrote:
| Is it possible to build Boa without these APIs?
| 383toast wrote:
| how does this compare to existing JS engines?
| echelon wrote:
| You can embed this one in your Rust programs. No linking to
| C/C++. All native Rust.
|
| That little 40 mb single binary server you wrote can now be
| scripted in JavaScript.
|
| This is frankly awesome, and now there are multiple Rust-native
| JavaScript engines. And they both look super ergonomic.
| phplovesong wrote:
| Why is stuff written in rust always promoted as "written in rust"
| like its some magic thing?
| dainiusse wrote:
| Yes. Getting really odd...
| the__alchemist wrote:
| In the case of libraries, this distinction is important; we've
| set up our computing infrastructure in a way replete with
| barriers which and drive repeated efforts in isolation.
| Therefore, if a library is written in Rust, it suggests that I
| can use it in my Rust program clear of a conspicuous barrier
| type.
|
| For an application, service, etc like this... it is not
| relevant.
| westoncb wrote:
| I think the idea is like: it took extra work 'cause Rust makes
| you be so explicit about allocations and types, but it's also
| probably faster/more reliable because that work was done.
|
| Of course at the end of the day it's just marketing and doesn't
| necessarily mean anything. In my experience the average piece
| of Rust software does seem to be of higher quality though..
| echelon wrote:
| Even forgetting the memory safety and async safety
| guarantees, the language design produces lower defect code by
| a wide margin. Google and other orgs have written papers
| about this.
|
| There are no exceptions. There are no nulls. You're
| encouraged to return explicit errors. No weird error flags or
| booleans or unexpected ways of handling abnormal behaviors.
| It's all standardized. Then the language syntax makes it easy
| to handle and super ergonomic and pleasurable. It's nice to
| handle errors in Rust. Fully first class.
|
| Result<T,E>, Option<T>, match, if let, if let Ok, if let
| Some, while let, `?`, map, map_err, ok_or, ok_or_else, etc.
| etc. It's all super ergonomic. The language makes this one of
| its chief concerns, and writing idiomatic Rust encourages you
| to handle errors smartly.
|
| Because errors were so well thought out, you write fewer
| bugs.
|
| Finally, the way the language makes you manage scope, it's
| almost impossible to write complicated nesting or difficult
| to follow logic. Hard to describe this one unless you have
| experience writing Rust, but it's a big contributor to high
| quality code.
|
| Rust code is highly readable and easy to reason about (once
| you learn the syntax). There are no surprises with Rust. It's
| written simply and straightforwardly and does what it says on
| the tin.
| phplovesong wrote:
| Thats not special to rust in any way or form. Most of
| mentioned features are stolen from ML, and in some cases
| badly. Eg rust has unwrap thats basically a ticking time
| bomb waiting to blow up. Rust has many other ways to blow
| up the program. Its not only about memory safety (80% of
| rust apps in the wild dont benefit from "memory safety" in
| any way or form).
| Tadpole9181 wrote:
| Okay, but the alternative isn't ML; virtually all of this
| software would otherwise be written in C or C++.
| shuraman7 wrote:
| are you for real? Rust most definitely is not highly
| readable and the language reeks of complexity
| enricozb wrote:
| It carries some weight, very roughly in the direction of formal
| verification. Since (assuming there isn't any unsafe), a
| specific class of bugs are guaranteed to not happen.
|
| However, this repo seems like it uses quite a bit of unsafe, by
| their own admission.
| phplovesong wrote:
| I mean if i care about safety that much i would just write
| the damn thing in ATS. Rust has too many escape hatches to be
| safe anyway.
| Pfeil wrote:
| You never have only one requirement to satisfy. For
| example, if you'd welcome a certain amount of contributors,
| your language should be something people know or people
| like to learn. And of course it may just be the mood of the
| initiator, which I find completely fine.
|
| Personally I find rust projects very inviting. Figuring out
| the amount of unsafe code is easy with grep/rg (to a
| certain degree), the project structure is pretty
| standardized, etc. All of this makes even a complex project
| relatively easy to start with. At the same time, the
| language is pretty usual (C-like and readable). I
| understand people like it, and writing "written in rust" is
| a good call for those people, I guess.
|
| "Written in JS" would communicate something else than
| "written in D" or "written in C++". It communicates a lot
| of things implicitly.
| ptravers wrote:
| There's a lot of unsafe in this at least. hard to be both
| safe and fast.
| kettlecorn wrote:
| One simple reason: for those of us invested in the Rust
| ecosystem it helps us spot new projects we could consider
| using.
| BiteCode_dev wrote:
| Because many people, including myself, have been consistently
| experiencing better quality from Rust-written software.
|
| Maybe it's the type of language that attracts people who are
| interested in getting the details right.
|
| Or maybe the qualities of the language mean if a project
| manages to reachthe production stage, it will be better than an
| alternative that would reach the production stage because the
| minimal level of quality and checks required are better.
|
| Or maybe it's because it comes with very little friction to
| install and use the software, because Rust software usually
| comes with a bunch of binaries from all popular platforms, and
| often, installers.
|
| Or maybe the ecosystem is just very good.
|
| Or maybe it's all together, and something more.
|
| Doesn't matter.
|
| The fact is, I did have a better experience with software
| written in rust that in Python, JS or even Go or Java.
|
| And I appreciate knowing the software is not written in C or
| C++, and potentially contains problems regarding security,
| segfaults, and encoding that are going to bite me down the
| road, as it's been common in the last 30 years.
|
| So "written in rust" is a thing I want to know, as it will make
| me more likely to try said software.
| DetroitThrow wrote:
| Usually if a project isn't using unsafe, it means memory bugs
| are not a thing while still promising non-GC speeds.
|
| However, this project is using a ton of unsafe (partly to offer
| GC behavior for js): https://github.com/search?q=repo%3AHans-
| Halverson%2Fbrimston...
| 65 wrote:
| Usually people think Rust = fast, so "Written in Rust" might
| imply it runs fast.
| ssrc wrote:
| I'm old enough to have seen the "written in lisp", "written in
| ruby", "written in javascript" eras, among others. It's
| natural.
| general1465 wrote:
| It is becoming meme like Arch - It is written in Rust btw.
| almost wrote:
| When it's a library it's fairly important what it's written (or
| at least written for)
| p1necone wrote:
| The people that complain about projects saying they were
| written in rust are _far_ more annoying than the projects
| themselves at this point.
| tetris11 wrote:
| There's no license I can see
| bsnnkv wrote:
| Great to see more projects not opting into licenses which
| permit megacorp exploitation by default
| robocat wrote:
| Many megacorps provide value to users. For example Google and
| Apple are used by maybe 75% of humanity. Google in particular
| appears to have given back into the ecosystem (often to
| Google's detriment). It isn't as binary as you make it to be.
| HansHalverson wrote:
| That was an oversight, this is now under the MIT license!
| HansHalverson wrote:
| Author here - very cool to see this get posted! Thank you
| @ivankra for adding this to
| https://github.com/ivankra/javascript-zoo and running those
| benchmarks, I really appreciate it!
|
| This started as a hobby project that I've ended up putting a lot
| of time into over the last three years chasing completeness and
| performance.
| larusso wrote:
| Love the name of the executable ;) For my taste it just sounds
| right. BS as in Bullsh#t :)
___________________________________________________________________
(page generated 2025-11-16 23:00 UTC)