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

111–120 of 125 posts

Re: Brimstone: ES2025 JavaScript engine written in Rust

#111

Post by SkiFire13 »

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…

To add to the skintone emojis example, country flags emojis are combined characters using two letter characters corresponding to the country code. The various "family" emojis are also combined characters of individual person emojis, and so on.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#112

Post by miki123211 »

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…

I just wish we could use system tables for that, instead of bloating every executable with their own outdated copy.

I have no issue with my system using an extra 10mb for Ancient Egyptian capitalization to work correctly. Every single program including those rules is a lot more wasteful.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#113

Post by rixed »

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…

I am not questionning the goal of representing all the fine details of every possible languages and currencies and calendars in use anywhere at any time in the universe, that's a respectable achievment. I'm discussing the process that lead to a programming language interpreter needing, according to the comment I was replying to, to embed that trove of data.

Most of us are not using computers to represent subtle variants of those cultural artifacts and therefore they should be left in some specialized libraries.

Computers are symbolic machines, after all, and many times we would be as good using only 16 symbols and typing our code on a keyboard with just that many keys. We can't have anything but 64bits floats in JS, but somehow we absolutely need to be able to tell between the "peso lourd argentin (1970–1983)" and the "peso argentin (1881–1970)"? And that to display a chemical concentration in millimole per liter in German one has to write "mmol/l"?

I get it, the symbolic machines need to communicate with humans, who use natural languages written in all kind of ways, so it's very nice to have a good way to output and input text. We wanted that way to not favor any particular culture and I can understand that. But how do you get from there to the amount of arcane specialized minute details in the ICU dataset is questionable.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#114

Post by animuchan »

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…

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

Respectfully disagree, linguistic diversity isn't by definition impossible to create a good abstraction on top of; I think that it's more of a failure of this particular attempt.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#115

Post by necovek »

animuchan wrote: post #114
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…

> 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. Respectfully disagree, linguistic diversity isn't by definition impossible to create a good abstraction on top of; I think that it's more of a failure of this particular attempt.

Care to point out a -- by your definition -- successful attempt to do it?

Re: Brimstone: ES2025 JavaScript engine written in Rust

#116

Post by evilduck »

ivankra wrote: post #102
evilduck wrote: post #68

Earlier quoted context omitted.

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…

Escargot is more spec-compliant than Hermes though. Sometimes you can't run V8 or any JIT engine because policy or politics, and it's nice to have options.

I get it, I'm not saying it's bad, I just think it fills a small niche and its popularity and reception mirror that.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#117

Post by phplovesong »

ssrc wrote: post #65
phplovesong wrote: post #37

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

I'm old enough to have seen the "written in lisp", "written in ruby", "written in javascript" eras, among others. It's natural.

Im also old enough to recall when ruby (rails really) was the hype everyone jumped on. But i cant say i ever seen "rewritten in javascript/X" thing as its used with rust.

In rust i see that the rewrite is the important thing, not the software itself. Its completely bonkers.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#118

Post by phplovesong »

tcfhgj wrote: post #94
phplovesong wrote: post #62

Earlier quoted context omitted.

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

IMHO every app benefits from memory safety. Memory safety doesn't only have security implications, but reduces crashes, misbehavior and corrupt data. You don't want either in any software, which has to fulfill a task in a productive way.

Sure, but a GC gives you that. Having manual memory management (like in C) is something only a very few applications REALLY need. Hell i have seen web frontends written in rust. Now the circle is complete.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#119

Post by tcfhgj »

phplovesong wrote: post #118
tcfhgj wrote: post #94

Earlier quoted context omitted.

IMHO every app benefits from memory safety. Memory safety doesn't only have security implications, but reduces crashes, misbehavior and corrupt data. You don't want either in any software, which has to fulfill a task in a productive way.

Sure, but a GC gives you that. Having manual memory management (like in C) is something only a very few applications REALLY need. Hell i have seen web frontends written in rust. Now the circle is complete.

1. It doesn't give you that necessarily, see Go.

2. Rust doesn't have memory management like in C. In Rust, abstractions and the compiler manage memory for you, except when you opt into C-like memory management using unsafe.

3. The comment was about memory safety, not memory management, and its benefit.

4. In case of GC vs manual memory management was used as a speed comparison: You might not REALLY need the speed of Rust, but I gladly take it where I can. I am tired of sluggish resource hogging electron apps and similar. Electron probably destroyed at least 10-15 years of progress in hardware performance gains.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#120

Post by necovek »

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

I am not questionning the goal of representing all the fine details of every possible languages and currencies and calendars in use anywhere at any time in the universe, that's a respectable achievment. I'm discussing the process that lead to a programming language interpreter needing, according to the comment I was replying to, to embed that trove of data. Most of us are not using computers to represent subtle varia…

You bring up numbers, but you ignore the strings, another fundamental data type in all programming languages.

Without this trove of data, you can't do something as simple as length(str) or uppercase(str) — even in a CLI if you want to line text up.

So yes, this database has a big chunk that represents rarely useful data like you mention. But majority of it is still generally useful.

Post reply on HN