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

91–100 of 125 posts

Re: Brimstone: ES2025 JavaScript engine written in Rust

#91

Post by shuraman7 »

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…

are you for real? Rust most definitely is not highly readable and the language reeks of complexity

Re: Brimstone: ES2025 JavaScript engine written in Rust

#92

Post by robocat »

bsnnkv wrote: post #64
tetris11 wrote: post #57

There's no license I can see

Great to see more projects not opting into licenses which permit megacorp exploitation by default

Many megacorps provide value to users. For example Google and Apple are used by maybe 75% of humanity. Google in particular appears to have given back into the ecosystem (often to Google's detriment). It isn't as binary as you make it to be.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#94

Post by tcfhgj »

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

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.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#95

Post by danielheath »

shuraman7 wrote: post #91
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…

are you for real? Rust most definitely is not highly readable and the language reeks of complexity

Readable is relative; it’s much less readable than some languages, but much more than the ones it’s largely displacing.

I would much rather try and figure out a bug in unfamiliar rust than in unfamiliar cpp.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#96

Post by nicoburns »

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

> Most of mentioned features are stolen from ML

Rust is the most popular ML-derived language, so if some is considering Rust vs. some other language the chances are the other one they're considering does not have all the ML goodies.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#97

Post by varispeed »

vardump wrote: post #19
varispeed wrote: post #18

Earlier quoted context omitted.

Sorry for the offtop, but I really miss the cracktros. Imagine having Ikari intro before you boot into your OS.

Sorry also for being offtopic, but "cracking" in this case most likely refers to cracking [with laughter].

"Don't. Say. Crack, Jez. Yeah? Please. Not now. Cause you saying crack makes me think about crack and I love crack. So can you not say crack?"

Re: Brimstone: ES2025 JavaScript engine written in Rust

#98

Post by pabs3 »

nicoburns wrote: post #54
ambicapter wrote: post #47

Earlier quoted context omitted.

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.

Debian has a unicode-data package, so you can just depend on it.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#99

Post by echelon »

shuraman7 wrote: post #91
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…

are you for real? Rust most definitely is not highly readable and the language reeks of complexity

It's comparable with Java.

It's significantly easier to parse than C++.

Re: Brimstone: ES2025 JavaScript engine written in Rust

#100

Post by martin-t »

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.

I was gonna say the last few percent might increase the size disproportionally as the last percent tend to do[0] but looks like boa passes fewer tests (~91%).

This is something I notice in small few-person or one-person projects. They don't have the resources to build complex architectures so the code ends up smaller, cleaner and easier to maintain.

The other way to look at it is that cooperation has an overhead.

[0]: The famous 80:20 rule. Or another claiming that each additional 9 in reliability (and presumably other aspects) takes the same amount of work.

Post reply on HN