> I'm more than a little suspicious of how Vercel has made so much progress so fast
Coding agents. They landed 918,000 lines of code in a single week: https://github.com/vercel-labs/scriptc/graphs/contributors?s...
Coding agents. They landed 918,000 lines of code in a single week: https://github.com/vercel-labs/scriptc/graphs/contributors?s...
I vibeslopped thousands of pages of blueprints, nobody reviewed them, but another team of digital monkeys with the intellect of an ant have already built the bridge, and it seems to not have collapsed yet, so we're already directing traffic there.
I can't imagine actual engineers feeling anything but deepest contempt for this industry.
But it is indeed engineering, and that’s OK.
Do you have some other definition of engineering that excludes SWE?
Here is the definition https://dictionary.cambridge.org/dictionary/english/engineer...
Many people's lives do depend on software today. Insurance software dictates who gets treatment and who doesn't; that's real lives at stake. Finance software controls access to things like food and shelter; that's real lives at stake. Firmware in prosthetics and diabetic injectors and so on and so forth. Software runs the world, we pat ourselves on the back saying, but forget the world is full of real lives.
(At one point I even debated the value of getting PE credentials at my age for extra leverage in that company.)
“Actual” engineering went through a phase where bridges and other structures did collapse due to structural flaws - it’s not like they magically figured out ahead of time how to avoid that.
Now, they can build structures that are some specified tolerance away from collapsing, but that’s only the case because the edges of what was possible were explored.
- 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)
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?