21–30 of 125 posts
Earlier quoted context omitted.
I'm curious if it can be done in Rust entirely though. Maybe some assembly instructions are required e.g. for trapping or setting memory fences.
If it comes to it then Rust has excellent support for inline assembly
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.
[flagged]
> who in the fuck would write a garbage collector using garbage collected Rust? Rust is not garbage collected unless you explicitly opt into using Rc/Arc
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.
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 executables with small library backings aren't possible anymore, and it isn't just ambient undefined "bloat". Unicode is a big one. Correct handling of unicode involves megabytes of tables and data that have to live somewhere, whether it's a linked library, compiled in, tables on disks, whatever. If a program touches text and it needs to handle it correctly rather than just passing it through, there's a minimum size for that now.
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.
Is that with any other size optimizations? I think by default, most of them (like codegen-units=1, remove panic handling, etc) are tuned for performance, not binary size, so might want to look into if the results are different if you change them.
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.
Rust also has some nice language features. Even unsafe rust doesn't have the huge "undefined behaviour" surface that languages like C++ still contain. If I were to write a toy JS runtime in Rust, I'd try to make it as safe as possible and deal with unsafe only when optimization starts to become necessary, but it's not like that's the only way to use Rust.
Earlier quoted context omitted.
> who in the fuck would write a garbage collector using garbage collected Rust? Rust is not garbage collected unless you explicitly opt into using Rc/Arc
I still wouldn't call it GC in that case. It's pretty much exactly the same as std::shared_ptr in C++, and we don't usually call that GC. I don't know about the academic definition, but I draw the line at a cycle collector. (So e.g. Python is GC'd, but Rust/C++/Swift are not.)
Earlier quoted context omitted.
If it comes to it then Rust has excellent support for inline assembly
But how well does it play with memory fences?