I guess I should write up what I had in mind then...
-
-
https://gist.github.com/gsnedders/0cbe42412315da53dbde70bea1d91963 … --- lmk what you think, though it obviously omits much (uh, how are we representing objects)
3 replies 3 retweets 4 likes -
Replying to @gsnedders @__farre__1 reply 0 retweets 0 likes
-
Replying to @BrendanEich @gsnedders and
Those points seem fine but only incidentally about Rust. My 2c: no impl PL adds enough to justify reengineering any mature JS VM. 1/
1 reply 0 retweets 5 likes -
Replying to @_shu @BrendanEich and
If you want to write a new production VM, justify real hard an existing one doesn't fit/too much maintenance/you have massive resources. 2/
2 replies 0 retweets 2 likes -
Replying to @_shu @BrendanEich and
FWIW, I on the whole agree; highly unlikely to add enough. "Production" only insofar as "has the required features". /1
1 reply 0 retweets 0 likes -
Replying to @gsnedders @_shu and
Unlikely to ever actually be competitive because of resources, especially on an ongoing basis. /2
1 reply 0 retweets 0 likes -
Replying to @gsnedders @_shu and
The angle to work is memsafe yet C++-performant engine. The fly in ointment is JIT mem-unsafety.
1 reply 0 retweets 0 likes -
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
For example, https://github.com/tunz/js-vuln-db#javascriptcore …
-
-
Replying to @pcwalton @gsnedders and
Also consider the parser, etc. The nice thing about this low-hanging fruit is that it avoids
@_shu’s dilemma—it can be done incrementally0 replies 1 retweet 3 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.