The angle to work is memsafe yet C++-performant engine. The fly in ointment is JIT mem-unsafety.
-
-
Replying to @BrendanEich @_shu and
Maybe I'm just too pessimistic about the resultant memory unsafety. :)
1 reply 0 retweets 0 likes -
Replying to @gsnedders @BrendanEich and
Aren’t a lot of the memory safety problems in practice in non-core-VM parts? Built-in function implementations, etc.
2 replies 0 retweets 3 likes -
Replying to @pcwalton @gsnedders and
Related point: SM has had to move some builtin impls from self-hjosted back to C++ for perf. Heard similar from V8.
1 reply 2 retweets 3 likes -
In light of Patrick's point (incrementalism, almost always good), why not a Quantum for SpiderMonkey, C++ to Rust in small pay-as-go steps?
3 replies 0 retweets 5 likes -
Replying to @BrendanEich @pcwalton and
Hard for me to weigh in without Rust experience. My feeling is many higher value low-hanging fruits exist than rewriting components in Rust.
3 replies 0 retweets 2 likes -
-
Replying to @pcwalton @BrendanEich and
Any perf work that won't benefit from a compartmentalized rewrite, which is most perf work, I'd say.
1 reply 0 retweets 2 likes -
The thing I'd most like is an API to SM which still allowed use of linear types, lifetimes etc. ATM servo has to RefCell almost everything.
3 replies 0 retweets 4 likes -
Replying to @asajeffrey @_shu and
cc
@littlecalculist — Could we have a SpiderMonkey Neon? Could we implement builtins with it?2 replies 0 retweets 0 likes
Heck, maybe we could use a Neon-compatible API for implementing DOM objects…
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.