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

121–125 of 125 posts

Re: Brimstone: ES2025 JavaScript engine written in Rust

#121

Post by rixed »

necovek wrote: post #120
rixed wrote: post #113

Earlier quoted context omitted.

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.

I may be wrong, but a cursory look at the data gave me the impression that the actual majority of that data was actually not related to dealing with commonplace string manipulations. Other than that, we probably agree.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#122

Post by phplovesong »

VerifiedReports wrote: post #83
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.

"like we never seen"?

Yes. Rust syntax is aweful for no real reason.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#123

Post by phplovesong »

tcfhgj wrote: post #119
phplovesong wrote: post #118

Earlier quoted context omitted.

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…

Electron is on a totally diffrent level. Im talking small compact programs (like rust/go/ocaml etc). Most do not need the 1-2ms faster execution rust provides.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#124

Post by necovek »

rixed wrote: post #121
necovek wrote: post #120

Earlier quoted context omitted.

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.

I may be wrong, but a cursory look at the data gave me the impression that the actual majority of that data was actually not related to dealing with commonplace string manipulations. Other than that, we probably agree.

The big one that's often ignored are collation tables: while there's the default in ISO 10646 IIRC, each region-language combo might have their specific overrides (imagine "ss" being sorted as a separate letter in German, and not as after "sr" and before "st", so it would be sa..., sb..., sr..., st..., ssa..., ssb... etc); and then Austrian German might have a different phonebook ordering.
Post reply on HN