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

61–70 of 125 posts

Re: Brimstone: ES2025 JavaScript engine written in Rust

#61

Post by the__alchemist »

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.

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.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#62

Post by phplovesong »

echelon wrote: post #50
westoncb wrote: post #42

Earlier quoted context omitted.

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

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…

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

Re: Brimstone: ES2025 JavaScript engine written in Rust

#66

Post by Tadpole9181 »

phplovesong wrote: post #62
echelon wrote: post #50

Earlier quoted context omitted.

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…

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

Okay, but the alternative isn't ML; virtually all of this software would otherwise be written in C or C++.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#67

Post by [deleted] »

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…

[deleted]

Re: Brimstone: ES2025 JavaScript engine written in Rust

#68

Post by evilduck »

lucideer wrote: post #34
ivankra wrote: post #3

Earlier quoted context omitted.

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.

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?

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.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#69

Post by jancsika »

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…

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

Post reply on HN