←back to thread

Brimstone: ES2025 JavaScript engine written in Rust

(github.com)
239 points ivankra | 3 comments | 16 Nov 25 11:41 UTC | HN request time: 0.001s | source
Show context
cluckindan ◴[16 Nov 25 13:15 UTC] No.45944902[source]▶
Memory safety is one of Rust’s biggest selling points. It’s a bit baffling that this engine would choose to implement unsafe garbage collection.
replies(5): >>45945042 #>>45945421 #>>45945492 #>>45945613 #>>45945847 #
the__alchemist ◴[16 Nov 25 15:35 UTC] No.45945847[source]▶
IMO the memory safety aspect is overblown by enthusiasts and purists. Rust is an overall nice fast imperative language.
replies(1): >>45946021 #
phplovesong ◴[16 Nov 25 15:58 UTC] No.45946021[source]▶
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.
replies(3): >>45946339 #>>45946744 #>>45947876 #
swiftcoder ◴[16 Nov 25 16:33 UTC] No.45946339[source]▶
> 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.

replies(1): >>45946721 #
1. phplovesong ◴[16 Nov 25 17:22 UTC] No.45946721[source]▶
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.
replies(1): >>45947415 #
2. swiftcoder ◴[16 Nov 25 18:54 UTC] No.45947415[source]▶
You can do that just fine in Rust too, for example the Makepad[1] developers take a pretty extreme non-invented-here stance, and builds a full UI toolkit with no external dependencies (and a major focus on clean-build compile times).

However, it isn't really part of the Rust OSS culture to operate like that. The culture typically values safety over compile times, and prefers to lean on a deep stable of battle-hardened abstractions.

[1]: https://makepad.nl, https://github.com/makepad/makepad

replies(1): >>45951047 #
3. hu3 ◴[17 Nov 25 05:25 UTC] No.45951047[source]▶
It's still hundreds of functionalities that they have to maintain themselves instead of leveraging a much more battle tested stdlib.