Viewing profile — Rusky

Compilers don't take away the code we need to write; they translate it into a different formal language that emphasizes and de-emphasizes various aspects of its meaning. LLMs are c…

There's Eytzinger order: https://algorithmica.org/en/eytzinger

This is not actually a problem for total languages, which simply model these kinds of processes using corecursion/coinduction/codata.

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.

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…

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 th…

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…

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 b…

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 an…

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…

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…

> 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 reso…

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.) w…

Hypothetically Rust could make `Mutex ` work with just two bits in the same way it makes `Option ` the same size as `&T`. Annotate `InnerBlah` with the information about which bits…

You don't need any of that, and you can keep cancellation too. The core of an eager cooperative multitasking system does not even need the concept of an executor. You can spawn a n…

> in principle the exact same optimization could be done for stackful coroutines. Yes, I totally agree, and this is sort of what I imagine a better design would look like. > One of…

"Not inert" does not at all imply "a single runtime within std+compiler." You've jumped way too far in the opposite direction there. The problem is that the particular interface Ru…

This one is relevant because it avoids heap allocation while running the iterator and for loop body concurrently. Which is exactly the kind of thing that `async` does.

The requirement is that the futures are not separate heap allocations, not that they are inert. It's not at all obvious that Rust's is the only possible design that would work here…

If that is what profiles were actually doing, it would probably make sense. But it's not what profiles are doing. Instead, for example, the lifetime safety profile ( https://github…

There is work coming from the "academic pedantism" sphere for exploiting single-resumability. For example: https://dl.acm.org/doi/pdf/10.1145/3632896

Yes, that's how it should work. It is not how it works in today's rustc.

> I'd be fine writing `.into()` or `.trunc()` Yes, this is specifically what I'm disagreeing with. > I fully expect that such methods will be inlined, likely even in debug mode (e.…

A method call like `.trunc()` is still going to be abysmally less ergonomic than `as`. It relies on inference or turbofish to pick a type, and it has all the syntactic noise of a f…

It is context free, just ambiguous.