2,160 karma · joined November 28, 2011
Formerly at Oracle Labs VM Research Group working on the truffleruby implementation.
Have a look at https://en.wikipedia.org/wiki/Subnormal_number for some context.
I looked at your sample chapter and immediately bounced off a police officer in Maine calling in a murder as a 187 (California penal code).
This is also true when creating with security patches and other things that need to be backported to multiple releases.
The lower level bits round the object model etc. all look very solid.
Although structs may not be necessary to make JS concurrent their limitations might help in reducing where memory model strangeness could creep in.
The property lookup and modification process in JS is complex enough as is, is not specified in an atomic kind of way, and has many opportunities for user code to be run as part of accessor properties. Enabling it in multithreaded implementations is tricky without opening up deadlocks when modifying property collections, and even with that could likely be broken by some suitably evil code. Ive worked on more than one implementation that offered some degree of multithreaded access and it’s generally only safe when limited to simple properties.
Async / await avoids those issues because none of the places where user code can be executed allow async code, so there is no opportunity for the world to be changed under your feet during something like property access.
Looking at award shortlists and nomination lists is also a good filter providing you know a little about the award (I wouldn’t go to the Clarke Award shortlist for mil sf stuff, for example).
Even if you go with something backed by a full time team there is still going to be a chance you have to deal with a security issue in a hurry, maybe in the run up to Christmas. That is just going to come with the territory and if you don’t want to deal with that then you probably need to think about whether you really need a sandbox that can execute untrusted code.