3 ms·

Uses "data-oriented design", so it's likely striving to be faster than other non-JIT runtimes by being more cache-friendly. Still at early stages, quite incomp

• aapoalas 1y ago
  Hi, Nova dev here. Yes, basically. And removing structural inheritance.
  • throwaway894345 1y ago
    Can you elaborate on "And removing structural inheritance"? Does that mean Nova doesn't use traits, and if so, why would that matter?
    • aapoalas 1y ago
      Traits are a type of interface inheritance; base classes and inherited classes à la C++ is structural inheritance. So basically it just means that I have to write more interfaces and implementations for them, because I don't have base classes to fall onto. Instead, in derived type/class instances I have an optional (maybe null) "pointer" to a base type/class instance. If the derived instance never uses its base class features, then the pointer stays null and no base instance is created. Often derived objects in JS are only used for those derived features, so I save live memory. But: the derived object type needs its own version of at least some of the base class methods, so I pay more in instruction memory (executable size).
• Permik 1y ago
  Essentially implementing JavaScript on top of the ECS architecture :D
  • aapoalas 1y ago
    Yup! My whole inspiration for this came from a friend explaining ECS to me and me thinking "wouldn't that work for a JS engine?"
    • SkiFire13 1y ago
      I've seen this brought up a couple times now, but I never get it. Why would ECS fit a JS engine? The ECS pattern optimizes for iterating over ton of data, but a JS engine does the opposite of that, it need to interpret instruction by instruction which could access random data.
      • aapoalas 1y ago
        Indeed, there's no guarantee that it will fit: I think it will but I don't know and want to find out. There are strong (IMO) reasons to think it will fit, though. User code can indeed do whatever but it rarely does. Programs written in JS are no less structured and predictable than ones written in C++ or Rust or any other language: they mostly operate on groups of data running iterations, loops, and algorithms over and over again. So the instructions being interpreted are likely to form roughly ECS System-like access patterns. Furthermore, it is more likely that data that came into the engine at one time (eg. one JSON.parse call or fetch result) will be iterated through at the same time. Thus, if the engine can ensure that data is and stays temporally colocated, then it is statistically likely that the interpreter's memory access patterns will not only come from System-like algorithms, they will access Component-array like memory. So: JS objects (and other heap allocated data) are Entities, their data is laid out in arrays of Components (TODO laying out object properties in Component arrays, at least in some cases), and the program forms the Systems. ECS :)
        • eyelidlessness 1y ago
          Disclaimer: I’m way out of my depth on the theoretical front, despite similarly taking interest in ECS in unconventional places. I’m responding from the perspective of most of my career being in JS/TS. I think your instincts about program structure are mostly right, but the outliers are pretty far out there. I’m much less optimistic about how you’re framing arbitrary data access. In my experience, it’s very common for JS code (marginally less common when authored as TS) to treat JSON (or other I/O bound data) as a perpetual blob of uncertainty. Data gets partially resolved into program interfaces haphazardly, at seemingly random points downstream, often with tons of redundancy and internal contradictions. I’m not sure how much that matters for your goals! But if I were taking on a project like this I’d be looking at that subset of non-ideal patterns frequently to reassess my assumptions.