Can you clarify what about the architecture is ‘idiotic’? Not trying to catch you or demand a defense, just looking for a vague description. I don’t even know how to start examining the architecture of something like this.
- 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
Note that “untyped dependency” means any code that says `any`.
Being able to build small, fast binaries without writing them in C or Rust - if you're already fluent in TypeScript - seems like a valuable capability.
CanadaHonk has gotten further than the rest of us. It’s surprising and impressive.
You’re only replying to the quickjs issue I raised, but it’s not the only issue. Their approach to numbers is broken. Their approach to measurement is broken. The quickjs thing raises another red flag: it suggests to me that they are using reference counting, not GC. That’s guaranteed to make them too slow to be useful. (If they weren’t using RC, then they’d have a hard time on the boundary to quickjs.)
As to the `any` issue, let me explain it in a way you’ll appreciate. I asked Claude how likely it is that TS code uses any, and it found:
- 79.5% of TS repos use any explicitly. So, about 4/5 chance that newly written dep-free TS code will use it.
- the explicit any type is about as common as Boolean and void.
- a third of inferred types are any. That’s huge.
So, if you don’t believe me, then at least believe Claude: any is a super common type, so they will be falling off into quickjs a lot.
Oh, and in case it isn’t clear, quickjs-ng is no better than quickjs. They’re the same thing for the purpose of perf
I had to do a triple take on this.
If I was using this project for something I'd expect to write custom TypeScript for it.
The floats rather than integers thing does look bad though. I tried compiling their fibonacci example to C (--backend c) and got this:
static double sc_f_fib(double sc_l_n_0) { /* /private/tmp/fib.ts:1 */
double sc_t0 = sc_l_n_0;
double sc_t1 = 2.0;
bool sc_t2 = sc_t0 < sc_t1;
double sc_t3;
if (sc_t2) {
double sc_t4 = sc_l_n_0;
sc_t3 = sc_t4;
} else {
double sc_t5 = sc_l_n_0;
double sc_t6 = 1.0;
double sc_t7 = sc_t5 - sc_t6;
double sc_t8 = sc_f_fib(sc_t7);
double sc_t9 = sc_l_n_0;
double sc_t10 = 2.0;
double sc_t11 = sc_t9 - sc_t10;
double sc_t12 = sc_f_fib(sc_t11);
double sc_t13 = sc_t8 + sc_t12;
sc_t3 = sc_t13;
}
return sc_t3; /* /private/tmp/fib.ts:2 */
}I've just been teaching myself Go, also a single binary but without the overhead. But in Go i miss the expressiveness of the TS type system sometimes.
This phrase I think highlights the fundamental issue for a lot of folks that would otherwise consider adopting a project like this written by humans.
This part made me laugh out loud
For a project like this, isn't it worth introducing a TS type for Ints? Since they are trying to leverage TypeScript anyway...
1. TS only has a "number" type. But what type of number is it? This is doable safely via keywords (or known markers), or sometimes via analysis, but I couldn't find it in the README.
2. A compiler that works only on macOS?