4 ms·

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 num

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

simonw 2mo ago
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?
- pizlonator 2mo ago
  They will have untyped dependencies. That’s how the TS/JS ecosystem works. Note that “untyped dependency” means any code that says `any`.
  - simonw 2mo ago
    They won't have untyped dependencies for situations where someone used Scriptc as a way to build a fast binary executable for some custom-written TypeScript, which was the first use-case that came to mind for me. 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.
    - vips7L 2mo ago
      So like less than 1% of the time? What part of the JS ecosystem doesn’t depend on a mountain of untyped dependencies?
    - pizlonator 2mo ago
      Yes, being able to build small and fast binaries in TS would be a valuable capability, which is why basically all of us who work in this space have thought of this idea and rejected it after going deep on it. This isn’t a new idea. 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
      - slopinthebag 2mo ago
        I think more human effort is going into defending this project then what was put into the project itself haha.
      - skeledrew 2mo ago
        > if you don’t believe me, then at least believe Claude I had to do a triple take on this.
      - simonw 2mo ago
        The QuickJS thing doesn't seem like a big deal to me, provided the documentation makes it clear that code will run slower if you use Any. 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 */ }
  - torginus 2mo ago
    Devil's advocate - this is for the backend. You get to control your dependencies there, and I'd say Vercel controls its own stack, so they can replace deps as they go by submitting patches/slopforking projects to remove incompatible features.
- piker 2mo ago
  > "As far as I can tell they..." 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.
Tadpole9181 2mo ago
So you don't actually have real criticisms of the architecture at all...?
anematode 2mo ago
> deferring int optimizations for later This part made me laugh out loud
drunkenmagician 2mo ago
"This project reeks of weapons grade AI psychosis" - fantastic quote: I will shamelessly steal & use. Apologies to pizlonator
Altern4tiveAcc 2mo ago
> 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...

simonw 2mo ago

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?

pizlonator 2mo ago
They will have untyped dependencies. That’s how the TS/JS ecosystem works. Note that “untyped dependency” means any code that says `any`.
- simonw 2mo ago
  They won't have untyped dependencies for situations where someone used Scriptc as a way to build a fast binary executable for some custom-written TypeScript, which was the first use-case that came to mind for me. 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.
  - vips7L 2mo ago
    So like less than 1% of the time? What part of the JS ecosystem doesn’t depend on a mountain of untyped dependencies?
  - pizlonator 2mo ago
    Yes, being able to build small and fast binaries in TS would be a valuable capability, which is why basically all of us who work in this space have thought of this idea and rejected it after going deep on it. This isn’t a new idea. 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
    - slopinthebag 2mo ago
      I think more human effort is going into defending this project then what was put into the project itself haha.
    - skeledrew 2mo ago
      > if you don’t believe me, then at least believe Claude I had to do a triple take on this.
    - simonw 2mo ago
      The QuickJS thing doesn't seem like a big deal to me, provided the documentation makes it clear that code will run slower if you use Any. 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 */ }
- torginus 2mo ago
  Devil's advocate - this is for the backend. You get to control your dependencies there, and I'd say Vercel controls its own stack, so they can replace deps as they go by submitting patches/slopforking projects to remove incompatible features.
piker 2mo ago
> "As far as I can tell they..." 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.

Tadpole9181 2mo ago

So you don't actually have real criticisms of the architecture at all...?

anematode 2mo ago

> deferring int optimizations for later This part made me laugh out loud

drunkenmagician 2mo ago

"This project reeks of weapons grade AI psychosis" - fantastic quote: I will shamelessly steal & use. Apologies to pizlonator

Altern4tiveAcc 2mo ago

> 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...