Yeah
- using quickjs at all in a thing that needs perf. Quickjs is hilariously slow. Midwits use it because it has “quick” in the name.
- using floats for numbers and deferring int optimizations for later. Inferring ints is like half the problem of fast JS.
- rejecting inadequately annotated or too dynamic code without a whole heck of a lot of self-reflection about how unlikely that is to work out.
The observation that languages that are even slightly dynamic need dynamic JIT opts is very old; folks figured that out in the 80s.
This project reeks of weapons grade AI psychosis
"This project reeks of weapons grade AI psychosis" - fantastic quote: I will shamelessly steal & use. Apologies to pizlonator
> deferring int optimizations for later
This part made me laugh out loud
> using floats for numbers and deferring int optimizations for later. Inferring ints is like half the problem of fast JS.
For a project like this, isn't it worth introducing a TS type for Ints? Since they are trying to leverage TypeScript anyway...
So you don't actually have real criticisms of the architecture at all...?
As far as I can tell they pull in QuickJS (actually quickjs-ng) only in the case where the program has untyped dependencies that still need to be run by an interpreter - and they chose that library because it's pretty small (620KB). Did I miss something, are they using it outside of that purpose?