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

51–60 of 125 posts

Re: Brimstone: ES2025 JavaScript engine written in Rust

#51

Post by bcardarella »

embedding-shape wrote: post #22
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.

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.

I only ran both with `cargo build --release`

Re: Brimstone: ES2025 JavaScript engine written in Rust

#53

Post by BiteCode_dev »

phplovesong wrote: post #37

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

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.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#54

Post by nicoburns »

ambicapter wrote: post #47
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…

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.

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.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#55

Post by DetroitThrow »

phplovesong wrote: post #37

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

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

Re: Brimstone: ES2025 JavaScript engine written in Rust

#56

Post by necovek »

rixed wrote: post #36
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…

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

Re: Brimstone: ES2025 JavaScript engine written in Rust

#58

Post by phplovesong »

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.

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.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#59

Post by necovek »

twoodfin wrote: post #31
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…

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.

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

Re: Brimstone: ES2025 JavaScript engine written in Rust

#60

Post by phplovesong »

swiftcoder wrote: post #49
phplovesong wrote: post #40

Earlier quoted context omitted.

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.

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