Okay. I gave it another read and I think we agree in general, but maybe disagree on how much memory model strangeness is acceptable, and how wide the gap between, “The behaviour can be understood by a developer,” and, “it should be possible to write a sequential JS program that creates an indistinguishable heap,” is likely to be.
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.
It’s certainly possible, but I worry that weird things can happen when doing something as “simple” as defining a property if another thread is messing with the prototype chain. Even thread safe property maps can’t entirely save you because operations that need to go up the prototype chain are not and cannot be atomic.
Although the work being done to enable multiple threads in JS is impressive I think it will be hard to make robust in many casss without locks, or fairly strict limits what operations can be performed on objects shared between threads.
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.
The point is that having a GC will affect your data structure and algorithm design, so it’s easier to automatically transform JS or TS to Go than to rust because you’re mostly reducing things down to one problem (translation) rather than multiple intertwined problems.
It depends a lot on where you were brought up, and the language you were exposed to. My first association would be a very Yorkshire, “Thou knowest,” rather than the king james.
I recommend actual human reviewers who you can stick with over time and who do not just say that a book is good or bad but something about why. Those don’t have to be professional reviewers, they can just be people you know or follow who talk about what they read.
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).
It’s been swinging for at least 30 years, Toplink came out in 1994, and I have worked on systems that were written half a decade earlier that contained things we’d all call ORMs.
Orthography is probably the biggest stumbling block going back to the 1500s or 1400s , but that’s really because the rest of the language has changed in vocabulary and style, but is still understandable. If you think the 1200 or 1100 entry are mostly orthographical changes then you are missing the interesting bits.
Obviously there isn’t any of that in Warhammer, at least not officially. Even a pretty niche thing for them is probably at a scale where resin casting would make more sense (assuming they aren’t going to sell or license out STL files). There is a decent unofficial scene around alternative weapons load outs and such like, but it’s not going to destroy GW any time soon.
You need more than a simple sandbox for what you describe. You also need to avoid infinite loops or other constructs from causing a DoS or similar, and if you are doing this with the intention of interacting with some other parts of a system then you need to think about how that interaction works and whether there is a way to execute something outside of that sandbox.
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.
Confirmation codes are not sufficient on their own, they cycle through them relatively quickly so they have to be combined with things like the passengers family name to actually identify the booking.
Calling them AI flamegraphs is really naming them after the workload they are likely to be used on. If you want to make workloads more efficient it’s useful to know where they are spending their time.
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.