CryZe

Seems to match the pareto frontier on Artificial Analysis as well. Terra is nowhere on it.

> THE SPINNER MESSAGE CAUSES 100% GPU USAGE ON AN MBP M5!!

This seems to be a common Chromium problem across tons of software. GitHub has the same issue with its spinners, VSCode as well.

This doesn't implement a JS engine, it's just a wrapper around boa.

I've been using both Opus 4.6 and Codex 5.3 in VSCode's Copilot and while Opus is indeed 3x and Codex is 1x, that doesn't seem to matter as Opus is willing to go work in the background for like an hour for 3 credits, whereas Codex asks you whether to continue every few lines of code it changes, quickly eating way more credits than Opus. In fact Opus in Copilot is probably underpriced, as it can definitely work for an hour with just those 12 cents of cost. Which I'm not sure you get anywhere else at such a low price.

Update: I don't know why I can't reply to your reply, so I'll just update this. I have tried many times to give it a big todo list and told it to do it all. But I've never gotten it to actually work on it all and instead after the first task is complete it always asks if it should move onto the next task. In fact, I always tell it not to ask me and yet it still does. So unless I need to do very specific prompt engineering, that does not seem to work for me.

Wasm can do 64-bit integers, SIMD and statically typed GC classes.

It depends. If you are compiling a high level GC language to WasmGC then there's really close to no reason why it would be larger than JS.

Zig has no undefined behavior?

You can buffer overflow in fil-c and it won't detect it unless the entire buffer was its own stack or heap allocation with nothing following it (and also it needs to be a multiple of 16 bytes, cause that's padding that fil-c allows you to overflow into). So it arguably isn't much different from wasm.

Quick example:

typedef struct Foo {

    int buf[2];

    float some_float;

} Foo;

int main(void) {

    Foo foo = {0};

    for (size_t i = 0; i < 3; ++i) {

        foo.buf[i] = 0x3f000000;

        printf("foo.buf[%zu]: %d\n", i, foo.buf[i]);

    }

    printf("foo.some_float: %f\n", foo.some_float);

}

This overflows into the float, not causing any panics, printing 0.5 for the float.

Ferrocene has donated their specification to the project, so there absolutely is a specification now. What you can argue is that the memory model isn‘t fully defined, but it‘s almost certainly going to land somewhere around stacked borrows or tree borrows. Arguably C doesn‘t fare much better in that regard though as it doesn‘t even properly define its pointer provenance model either and Rust is much closer to defining its.

A ton of that is actually still doing codegen (for the proc macros for example).

WebAssembly also ended up calling its set of similar instructions relaxed.