Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brimstone: ES2025 JavaScript engine written in Rust

github.com

Post reply on HN
Print view View original

71–80 of 125 posts

Re: Brimstone: ES2025 JavaScript engine written in Rust

#71

Post by xeonmc »

necovek wrote: post #56
rixed wrote: post #36

Earlier quoted context omitted.

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.

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 complex…

Does that include emojis?

Re: Brimstone: ES2025 JavaScript engine written in Rust

#72

Post by HansHalverson »

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.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#74

Post by ptravers »

enricozb wrote: post #44
phplovesong wrote: post #37

Why is stuff written in rust always promoted as "written in rust" like its some magic thing?

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.

There's a lot of unsafe in this at least. hard to be both safe and fast.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#75

Post by HansHalverson »

jerf wrote: post #25
bcardarella wrote: post #15

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.

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 exec…

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/).

Re: Brimstone: ES2025 JavaScript engine written in Rust

#76

Post by swiftcoder »

phplovesong wrote: post #60
swiftcoder wrote: post #49

Earlier quoted context omitted.

> 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.

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.

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

Re: Brimstone: ES2025 JavaScript engine written in Rust

#77

Post by gishh »

necovek wrote: post #56
rixed wrote: post #36

Earlier quoted context omitted.

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.

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 complex…

[flagged]

Re: Brimstone: ES2025 JavaScript engine written in Rust

#78

Post by adzm »

jancsika wrote: post #69
jerf wrote: post #25

Earlier quoted context omitted.

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 exec…

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.)

Yes, though it's easy to not use the ICU library properly or run into issues wrt normalization etc

Re: Brimstone: ES2025 JavaScript engine written in Rust

#79

Post by jcranmer »

xeonmc wrote: post #71
necovek wrote: post #56

Earlier quoted context omitted.

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 complex…

Does that include emojis?

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."
Post reply on HN