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

81–90 of 125 posts

Re: Brimstone: ES2025 JavaScript engine written in Rust

#81

Post by nekevss »

HansHalverson wrote: post #75
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…

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

Yeah, the majority of the difference is from the Unicode data for Intl along with probably the timezone data for Temporal.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#82

Post by Pfeil »

phplovesong wrote: post #58
enricozb wrote: post #44

Earlier quoted context omitted.

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.

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.

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.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#83

Post by VerifiedReports »

phplovesong wrote: post #40
the__alchemist wrote: post #33

Earlier quoted context omitted.

IMO the memory safety aspect is overblown by enthusiasts and purists. Rust is an overall nice fast imperative language.

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.

"like we never seen"?

Re: Brimstone: ES2025 JavaScript engine written in Rust

#85

Post by necovek »

jcranmer wrote: post #79
xeonmc wrote: post #71

Earlier quoted context omitted.

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…

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.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#86

Post by nicoburns »

nekevss wrote: post #81
HansHalverson wrote: post #75

Earlier quoted context omitted.

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

Yeah, the majority of the difference is from the Unicode data for Intl along with probably the timezone data for Temporal.

Is it possible to build Boa without these APIs?

Re: Brimstone: ES2025 JavaScript engine written in Rust

#87

Post by nicoburns »

necovek wrote: post #85
jcranmer wrote: post #79

Earlier quoted context omitted.

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…

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…

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

Re: Brimstone: ES2025 JavaScript engine written in Rust

#88

Post by kibwen »

nicoburns wrote: post #87
necovek wrote: post #85

Earlier quoted context omitted.

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…

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

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.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#89

Post by overfeed »

necovek wrote: post #85
jcranmer wrote: post #79

Earlier quoted context omitted.

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…

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…

> they're simple non-combining characters

Skin-tone emoji's are combined characters: base emoji + tone.

Post reply on HN