5 ms·

That explains why: - the architecture is idiotic. - they have zero credible perf numbers. I plan to benchmark it using generally accepted methods. Porffor m

That explains why: - the architecture is idiotic. - they have zero credible perf numbers. I plan to benchmark it using generally accepted methods. Porffor makes careful trade offs that make sense and is benchmarked in a way that I can believe. (Source: I make dynamic languages fast for a living)

bbor 2mo ago
Putting aside the whole “team of professionals putting out a product vs solo dev fine tuning their opus” of it all: 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.
- pizlonator 2mo ago
  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
    - 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...
- jeswin 2mo ago
  Just randomly: 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?

bbor 2mo ago

Putting aside the whole “team of professionals putting out a product vs solo dev fine tuning their opus” of it all: 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.

pizlonator 2mo ago
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
  - 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...
jeswin 2mo ago
Just randomly: 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?