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?

There are algebraic operations available on nightly: https://doc.rust-lang.org/nightly/std/primitive.f32.html#alg...

Keep an eye out for the algebraic operations on floats currently in nightly then: https://doc.rust-lang.org/nightly/std/primitive.f32.html#alg...

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.

I have an issue where I have two canvases that are overlapping and only WebKitGTK (not even just WebKit) just randomly stops showing one of the canvases.

First it was "Why Do Animals Keep Evolving into Crabs?", now it's "Why Do Programming Languages Keep Evolving into Crabs?"

I'd love to see VSCode integrate all the LSP information into Copilot. That seems to be the natural evolution of this idea.

It's 1.5x3 if you have a 21:9 screen. It's so bad.

For me they made it so large that I can only see 3 full thumbnails. The rest don't even fit the screen anymore. https://i.imgur.com/11iI4sI.jpeg

There's no interpreter, I just map each instruction to equivalent Rust code. Linear memory is accessed through a trait.

The compiler is here: https://github.com/CryZe/wasm-to-rust

I have an example of a GameBoy emulator compiled from AssemblyScript to WASM to Rust here: https://github.com/CryZe/wasmboy-rs/blob/master/src/wasm.rs

I once implemented a WASM to Rust compiler that due to WASM's safety compiles to fully safe Rust. So I was able to compile C -> WASM -> Rust and ended up with fully safe code. Though of course, just like in WASM, the C code is still able to corrupt its own linear memory, just can't escape the "sandbox". Firefox has employed a similar strategy: https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...

Take a look into bytemuck or zerocopy. I haven't used unsafe when doing byte level manipulation in a long time.

They are in the process of marking them safe, which is enabled through the target_feature 1.1 RFC.

In fact, it has already been merged two weeks ago: https://github.com/rust-lang/stdarch/pull/1714

The change is already visible on nightly: https://doc.rust-lang.org/nightly/core/arch/x86/fn._mm_xor_s...

Compared to stable: https://doc.rust-lang.org/core/arch/x86/fn._mm_xor_si128.htm...

So this should be stable in 1.87 on May 15 (Rust's 10 year anniversary since 1.0)

That was the time we learned about the changes to the block feature.

I still don't know why that isn't just provided for you.

> ability to use 64 bit types more easily

Those are available on wasm32 just the same.

> It's not like you can rely on Rust references and C pointers being identical in the ABI either.

You absolutely can rely on that: https://doc.rust-lang.org/reference/type-layout.html#pointer...

In fact, it's almost even best practice to do so, because it reduces the unsafe needed on Rust's side. E.g. if you want to pass a nullable pointer to T, declare it as e.g. a parameter x: Option<&T> on the Rust side and now can you do fully safe pattern matching as usual to handle the null case.

Want to use some Rust type (not even repr(C)) from C? Just do something like this:

#[no_mangle] pub extern "C" fn Foo_new() -> Box<Foo> { Box::new(Foo::new()) }

#[no_mangle] pub extern "C" fn Foo_free(_: Box<Foo>) { /* automatic cleanup */ }

#[no_mangle] pub extern "C" fn Foo_do_something(this: &mut Foo) { this.do_something() }

all fully safe. Unfortunately for the OP, Vec<_> isn't FFI safe, so that's still one of those cases that are on the rough side.

Only about 1/3 of those are language features. Out of those a ton are #[cfg] related (i.e. being able to more accurately doing conditional compilation), const (lifting limitations with compile time evaluation), documentation, architecture specific additions (like intrinsics) and co.

I only see about like 30 or so that are actual proper language additions, some of which are just exploration without even an RFC either, leaving us with about 15 or so, which really isn't that bad.

> Maybe not yet, but it is heading in that direction

About 95% of the unstable features lift limitations that most people expect not to be there in the first place. I'm not aware of all too many that aren't like that.

> huge pain in the ass

Maybe if you structure your code weirdly? I haven't encountered a major borrow checker issue that I couldn't easily resolve in many years.

I wouldn't be surprised if they showed up at the maintainer's house even.