Rusky (u/Rusky) - Readit News

Rusky commented on Nominal Types in WebAssembly wingolog.org/archives/202... · Posted by u/ingve

kjksf · 2 days ago

Good lord. WebAssembly was sold as "portable assembly for the web". It's in the fricking name. Web. Assembly. Assembly for the web.

It was supposed to solve the problem of: some computers run x86, some arm, we need something that is equivalent, but portable across different cpus

What business is it for WebAssembly to know about complex types? What x86 instructions is there for `(type $t (struct i32))` ? Or doing garbage collection.

We would be better off standardizing on a subset of x86 and writing translators to arm etc. Or standardize on arm and translate to x86.

We know it can work. Apple did it with rosetta. Microsoft did it with Prism. I don't think WebAssembly implementation generate faster code than rosetta or prism.

QEMU did it simply (albeit slowly).

WebAssembly is becoming another JVM. It's not simple. It's not fast. It's not easy to use.

But now we're stuck with it and the only path is to add and add and add.

Rusky · 2 days ago

The types are there for garbage collection, which is there for integration with the Web APIs which are all defined in terms of garbage collected objects.

Rusky commented on My “grand vision” for Rust blog.yoshuawuyts.com/a-gr... · Posted by u/todsacerdoti

satvikpendem · 7 days ago

> We (Oli, Niko, and Yosh) are excited to announce the start of the Keyword Generics Initiative, a new initiative 1 under the purview of the language team

https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge...

Maybe he's not on the language team (I haven't read enough into Rust governance structures to know definitively) but it's not like he's on some random person working on this. And yes, work takes time, I actually disagreed with his initial approach where his syntax was to have a bunch of effects before the function name, and everyone rightly mentioned how messy it was. So they should be taking it slow anyway.

Rusky · 7 days ago

The thing is that anyone can show up and spend time discussing ideas in Rust project spaces. From the outside it is easy to confuse that with actual movement toward landing changes in the language.

(The communication aspect of this is something that has bothered me many times in the past- even people who are lang team members often phrase things in a way that makes it sound like something is on its way in, when it's still just in the stage of "we're kinda noodling with ideas.")

Rusky commented on My “grand vision” for Rust blog.yoshuawuyts.com/a-gr... · Posted by u/todsacerdoti

satvikpendem · 9 days ago

Yoshua works directly on developing the language, and mentions he is working on these features specifically (he is part of the effects initiative), I'm not sure you won't see these features in Rust.

Rusky · 8 days ago

Yoshua is part of the "loud contingent" being described. He's not on the lang team, and he's been "working on" things like keyword generics for years without any indication that they are going to make it into the language.

Rusky commented on My “grand vision” for Rust blog.yoshuawuyts.com/a-gr... · Posted by u/todsacerdoti

pjmlp · 8 days ago

Because in order to have standard library breaking changes across editions, if those types are exposed in the crate public types, or change their semantics across editions, the compiler has to be able to translate between them when generating code.

See the Rust documentation on what editions are allowed to change, and the advanced migration guide on examples regarding manual code migration.

Not so much what has happened thus far, rather the limitations imposed in what is possible to actually break across editions.

Rusky · 8 days ago

Or put another way, a hypothetical feature that you made up in your head is the thing that requires source access. Editions do not let you change the semantics of types.

To be fair, Rust tooling does tend toward build-from-source. But this is for completely different reasons than the edition system: if you had a way to build a crate and then feed the binary into builds by future compilers, it would require zero additional work to link it into a crate using a different edition.

Rusky commented on Notes on writing Rust-based Wasm notes.brooklynzelenka.com... · Posted by u/vinhnx

flohofwoe · 8 days ago

This is about the same as saying that the x86 or ARM instruction sets are largely useless outside of targeting C/C++ and derivatives...

Rusky · 8 days ago

Not at all. It's much more efficient to implement a GC on x86 or ARM than it is on Wasm 1.0/2.0, because you control the stack layout, and you don't have an impenetrable security boundary with the JS runtime that your GC needs to interop with.

Not to mention the issue that bundling a GC implementation as part of your web page can be prohibitive in terms of download size.

Rusky commented on Against Query Based Compilers matklad.github.io/2026/02... · Posted by u/surprisetalk

foolswisdom · 14 days ago

I would really appreciate if rust analyzer was faster, actually. It feels even worse with the fact that you need to save the file before it updates the type checking (though I assume it's because it's too slow to feel smooth if you do it while typing?).

Rusky · 14 days ago

The reason rust-analyzer doesn't update diagnostics until you save is historical. Originally, people tried to build IDE support by reusing rustc itself, but this proved too slow and cumbersome at the time.

Rust-analyzer reimplemented the frontend in a more IDE-friendly architecture, but focused more on name resolution than on type checking. So it delegated diagnostics to literally just running `cargo check`.

As parts of rustc get rewritten over time (the trait solver, borrow checker) they have also been made more IDE-friendly and reusable, so rust-analyzer is slowly gaining the ability to surface more type checking diagnostics as you edit, without delegating to `cargo check`.

Rusky commented on Rue: Higher level than Rust, lower level than Go rue-lang.dev/... · Posted by u/ingve

stouset · 3 months ago

Would someone please explain to me why TCO—seemingly alone amongst the gajillions of optimization passes performed by modern compilers—is so singularly important to some people?

Rusky · 3 months ago

TCO is less of an optimization (which are typically best-effort on the part of the compiler) and more of an actual semantic change that expands the set of valid programs. It's like a new control flow construct that lives alongside `while` loops.

Rusky commented on Inside Rust's std and parking_lot mutexes – who wins? blog.cuongle.dev/p/inside... · Posted by u/signa11

JoshTriplett · 4 months ago

The difference is that unwinding unwinds code that isn't necessarily prepared for it, rather than only code that explicitly wants it.

And I would expect to turn it into an efficient solution, in part by doing the "store in a side table" approach for hook registration.

Rusky · 4 months ago

Giving special treatment to code that "explicitly wants" to handle unwinding means two things:

* You have to know when an API can unwind, and you have to make it an error to unwind when the caller isn't expecting it. If this is done statically, you are getting into effect annotation territory. If this is done dynamically, are essentially just injecting drop bombs into code that doesn't expect unwinding. Either way, you are multiplying complexity for generic code. (Not to mention you have to invent a whole new set of idioms for panic-free code.)

* You still have to be able to clean up the resources held by a caller that does expect unwinding. So all your vocabulary/glue/library code (the stuff that can't just assume panic=abort) still needs these "scoped panic hooks" in all the same places it has any level of panic awareness in Drop today.

So for anyone to actually benefit from this, they have to be writing panic-free code with whatever new static or dynamic tools come with this, and they have to be narrowly scoped and purpose-specific enough that they could essentially already today afford panic=abort. Who is this even for?

Rusky commented on Inside Rust's std and parking_lot mutexes – who wins? blog.cuongle.dev/p/inside... · Posted by u/signa11

JoshTriplett · 4 months ago

For the simple case, suppose that you're writing a TUI application that takes over the terminal. When it exits, even by panic, you want to clean up the terminal state so the user doesn't have to blindly type "reset".

Today, people sometimes do that by using `panic = "unwind"`, and writing a `catch_unwind` around their program, and using that to essentially implement a "finally" block. Or, they do it by having an RAII type that cleans up on `Drop`, and then they count on unwinding to ensure their `Drop` gets called even on panic. (That leaves aside the issue that something called from `Drop` is not allowed to fail or panic itself.) The question is, how would you do that without unwinding?

We have a panic hook mechanism, where on panic the standard library will call a user-supplied function. However, there is only one panic hook; if you set it, it replaces the old hook. If you have only one cleanup to do, that works fine. For more than one, you can follow the semantic of having your panic hook call the previous hook, but that does not allow unregistering hooks out of order; it only really works if you register a panic hook once for the whole program and never unregister it (e.g. "here's the hook for cleaning up tracing", "here's the hook for cleaning up the terminal state").

Suppose, instead, we had a mechanism that allowed registering arbitrary panic hooks, and unregistering them when no longer needed, in any order. Then, we could do RAII-style resource handling: you could have a `CursesTerminal` type, which is responsible for cleaning up the terminal, and it cleans up the terminal on `Drop` and on panic. To do the latter, it would register a panic hook, and deregister that hook on `Drop`.

With such a mechanism, panic hooks could replace anything that uses `catch_unwind` to do cleanup before going on to exit the program. That wouldn't fully solve the problem of doing cleanup and then swallowing the panic and continuing, but it'd be a useful component for that.

Rusky · 4 months ago

> Suppose, instead, we had a mechanism that allowed registering arbitrary panic hooks, and unregistering them when no longer needed, in any order. Then, we could do RAII-style resource handling: you could have a `CursesTerminal` type, which is responsible for cleaning up the terminal, and it cleans up the terminal on `Drop` and on panic. To do the latter, it would register a panic hook, and deregister that hook on `Drop`.

This doesn't get rid of unwinding at all- it's an inefficient reimplementation of it. There's a reason language implementations have switched away from having the main execution path register and unregister destructors and finally blocks, to storing them in a side table and recovering them at the time of the throw.

Rusky commented on Inside Rust's std and parking_lot mutexes – who wins? blog.cuongle.dev/p/inside... · Posted by u/signa11

timClicks · 4 months ago

References only have a single bit available as a niche (the null byte), which Option makes use of for null pointer optimization (https://doc.rust-lang.org/std/option/index.html#representati...).

In principle, you Rust could create something like std::num::NonZero and its corresponding sealed trait ZeroablePrimitive to mark that two bits are unused. But that doesn't exist yet as far as I know.

Rusky · 4 months ago

There are also currently the unstable rustc_layout_scalar_valid_range_start and rustc_layout_scalar_valid_range_end attributes (which are used in the definition of NonNull, etc.) which could be used for some bit patterns.

Also aspirations to use pattern types for this sort of thing: https://github.com/rust-lang/rust/issues/135996