Hacker Newsnew | past | comments | ask | show | jobs | submit | bbor's commentslogin

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.


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


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?

They will have untyped dependencies. That’s how the TS/JS ecosystem works.

Note that “untyped dependency” means any code that says `any`.


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.


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


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 */
  }

If you’re writing Typescript with zero dependencies and trying to target native I feel like it makes more sense to write it in a different language like Rust or Go. The main reason for this I think is getting cheap perf wins by running existing code natively.

For some new custom small thing you'd be better off using not this though, right?

Personally i can kind of see a use case here. I've shipped some simple server side packages as a "compiled" Node single executable written in TS, but you're stuck with the big overhead of Node.

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.


> if you don’t believe me, then at least believe Claude

I had to do a triple take on this.


There is always AssemblyScript

I think more human effort is going into defending this project then what was put into the project itself haha.

So like less than 1% of the time? What part of the JS ecosystem doesn’t depend on a mountain of untyped dependencies?

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.

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


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

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?


Those are good reasons to publish untyped libraries as a rule, sure. But the contention that those reasons outweigh the value of types kinda boggles the mind, ngl!

Publishing a lib as JS with .d.ts type files gives you JS compatibility and TS types for using the lib, but no TS source so no types inside.

I’ve seen people want to publish TS libs but there are issues: TS will type check the libs as well as your project. You can’t tell it to stop just because it’s going inside node modules. And the app may have tighter settings than the library and you will get type errors if your configs were setup differently. It would be interesting to standardize publishing real typescript libs but I haven’t seen it. Maybe deno tried? I haven’t looked.


When publishing on jsr.io, you upload the TypeScript, and if using Deno, you also download TypeScript (with import statements rewritten.) Having nearly the original source code is better for debugging.

Deno doesn’t type-check external dependencies unless you ask.


With the exports rewritten? Maybe we should have a export of “ts” like we have “types” instead?

Not sure what you mean, but to expand on what I wrote, JSR rewrites the import statements to include file extensions and full version numbers for package dependencies, so that the imports can be resolved without looking for them in multiple places.

There's a way to download JSR packages and use them with npm too. I don't know what it does in that case.


It’s too bad we didn’t start out with Deno

lol I just made a very similar thing — great minds! Yours is definitely better, tho.

“Kill-a-watt” is hilarious btw.

Out of curiosity: why watts ove microjules?



  Ruff v0.16 has a small number of breaking changes
Why. Why must my poor semver be hurt so!

I sorta kinda get why `ty` is pre v1.0.0 -- it's a typechecker that doesn't check a huge number of types. But what are we waiting for with `ruff`? Surely it's eaten whatever the old options were (black? maybe a few takes on py+lint?) by now many times over, and is even more dominant than `uv`.

I run this program hundreds of times a day so I'm generally excited for new features, but I guess the OAI acquisition has made me ornery when it comes to these folks. Apologies to kindly nerds who made this release happen, and congrats <3


Why must my poor semver be hurt so!

It is fully according to their versioning policy:

https://docs.astral.sh/ruff/versioning/

But also compliant with semver:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

https://semver.org/

(Maybe I misinterpreted your remark, but semver does not get hurt.)


It's conventional for semver to allow breaking changes for 0.x minor releases (but not for patch releases).

Yes but the question is why Ruff has not released v1 yet. They’re clearly used in production and the entire purpose of v0.x is to signal a project is early in development and is expected to have coarse edges.

The versioning doc linked elsewhere in the thread explains: There isn't yet a stable API and they want to wait on that before releasing v1.

Zerover for life

...which is why they were able to withdraw access to that tool, yes. You're just clarifying but the original comment here is deeply confused, IMHO.

1. Languages are used for much, much more than communication, and there is good reason to think that capacity didn't evolve for communication, but rather for metacognitive problem solving.

2. The idea that Tolkein --one of the most reknowned writers in our entire canon-- did something isn't relevant to the philosophical discussion of creativity and its obvious bounds. Even Tolkein was just painting within the lines set by the linguists he had read and the obscure languages he adored, not to mention the fundamental limits set by our capacity for language in the first place.

For anyone who's curious about this kind of thing, I cannot reccomend the infamous debate b/w Chomsky & Foucault enough; it ranges across topics a bit, but chapter markers should help you skip to the core of it (creativity) if you prefer. Video here: https://www.youtube.com/watch?v=3wfNl2L0Gf8 , some old summaries on /r/AskPhilosophy here: https://www.reddit.com/r/askphilosophy/comments/vgz1vb/what_...


Sadly, we have gone above and beyond the level of innovation where stock market disruption is a primary concern.

Luckily, we're all in this together. As long as enough people realize the weight of what's happening soon enough, I'm confident the indominable human spirit and the relative momentum of post-enlightenment social & institutional progress will carry us the rest of the way on a wave of clearly-justified solidarity.

To think otherwise --to truly face the spectre before us without hope-- is pathology, I think. Not necessarily incorrect of course, but definitely an unhealthy source of cognitive distress.


When the very first prokaryotic life forms saw the very first cells with mitochondria were they cognitively distressed? We face a similar phase change. In our lifetimes, probably.

I’d politely beg us all to resist those “maybe it’s PR” framing around model safety, and tbh to take a post-mortem mindsight to this historical event and what it teaches us in general, rather than questioning their security talents. We need to do our very best to make sure they tell us about the next time this happens and it affects real lives.

Sorry to bring the party down/be obstinate… I’m just a lil scared for the lives of me and my family. We need all of us, right now.

The problem with a super smart model is that it just may be smarter than you, after all… for anyone newly shaken by this occurrence, I encourage you to Kagi “superpersuasion”


The problem is that the people telling us about these things are the same people that benefit from their model (and AI generally) being used, getting publicity, etc.

I think we desperately need some independent group to evaluate claims like this or the world-ending Mythos cybersecurity risk and tell us what’s going on.


OpenAI already has loads of publicity. At this point, they don't need more brand recognition. This incident just has the effect of tarnishing their brand.

OpenAI leadership has been lobbying against regulation of AI systems. That doesn't comport with instigating incidents like this one, which give ammo to the heavy-regulation advocates.


I don’t think this is true. OpenAI is well known, but they still benefit from drumming up hype about AI, keeping it in the news, etc.

We did hear about this incident from a third party this time, from HuggingFace. What claim are you doubting?

They attacked a competitor (huggingface) with their models.

How and why are pr claims.


Whelp today’s a unique day on hacker news, wow! Didn’t expect to read that at my desk lol

Thank god!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: