Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust project goals: Immobile types and guaranteed destructors

github.com

Post reply on HN
Print view View original

91–100 of 112 posts

Re: Rust project goals: Immobile types and guaranteed destructors

#91

Post by yoshuaw »

ameliaquining wrote: post #73
Dagonfly wrote: post #57

Earlier quoted context omitted.

The compat issue has always been associated types on std traits. For example, should Iterator::Item be Move or ?Move If you leave it as Move, you can't create any iterators over !Move types. If you change it to ?Move, then functions using generic iterators can't assume that the elements of an Iterator are always moveable. Which is a breaking change compared to now. The most critical trait is probably Deref. Using !Mo…

The people working on this are aware that it poses backcompat problems that don't have obvious solutions. They are looking into non-obvious solutions. https://lcnr.de/blog/2025/11/28/implicit-auto-traits-assoc-t... is the most up-to-date one I'm currently aware of.

Niko Matsakis (T-Lang) has since also published a post on only-bounds: https://smallcultfollowing.com/babysteps/blog/2026/06/09/onl.... Sized hierarchy, Move, and Forget/Leak all share the same fundamental compat issues, so we're all pretty motivated to solve the underlying problems in a way that enables all the other features to be built on top.

Re: Rust project goals: Immobile types and guaranteed destructors

#93

Post by three_burgers »

drnick1 wrote: post #92

> Haskell is a very good language for writing this kind of application. I won't touch Pandoc with a ten foot pole because of the endless Haskell dependencies on Arch Linux. So no, Haskell is a pretty horrible choice.

Where was Haskell mentioned?

Re: Rust project goals: Immobile types and guaranteed destructors

#94

Post by ameliaquining »

yoshuaw wrote: post #91
ameliaquining wrote: post #73

Earlier quoted context omitted.

The people working on this are aware that it poses backcompat problems that don't have obvious solutions. They are looking into non-obvious solutions. https://lcnr.de/blog/2025/11/28/implicit-auto-traits-assoc-t... is the most up-to-date one I'm currently aware of.

Niko Matsakis (T-Lang) has since also published a post on only-bounds: https://smallcultfollowing.com/babysteps/blog/2026/06/09/onl... . Sized hierarchy, Move, and Forget/Leak all share the same fundamental compat issues, so we're all pretty motivated to solve the underlying problems in a way that enables all the other features to be built on top.

I had read that post, but IIUC it doesn't address the kind of backcompat issues that I meant to be referring to (the ones that would apply even if there was only ever going to be one new question-mark trait).

Re: Rust project goals: Immobile types and guaranteed destructors

#95

Post by appplication »

ddevnyc wrote: post #60
panstromek wrote: post #18

For everybody who doesn't have the context, just note that this is not an accepted langauge change. It's a just project goal, which means it's accepted as something people will work on, but the design might change significantly or it can even be abandoned completely (which is pretty unlikely for this one, to be fair).

I think it's absolutely amazing to have insight into long-term goals like this for open source projects. For one thing, it can help you plan your tech stack, and can even be a source of inspiration on what sorts of topics to learn and what sorts of research to do.

I second this. There’s so many OSS projects where long term plans live in private discords and maintainers act like it’s necessary to keep it all a secret

Re: Rust project goals: Immobile types and guaranteed destructors

#96

Post by ameliaquining »

afdbcreid wrote: post #84
ameliaquining wrote: post #71

Earlier quoted context omitted.

This is not currently a project goal. As with many things in the Rust project, it could be, if someone wanted to step up and dedicate the required engineering resources.

But also come with a plausible implementation strategy, that from what I know is not currently known for no-panic.

Out of curiosity, is there some reason it would be harder than I'm imagining? It seems like a fairly straightforward type-system feature. (I.e., it would be a lot of work, but only because any significant new language feature is a lot of work.)

Re: Rust project goals: Immobile types and guaranteed destructors

#97

Post by simonask »

stymaar wrote: post #78
simonask wrote: post #37

Earlier quoted context omitted.

I guess `!Move` is largely equivalent to `Unpin` for the purposes of `Pin`, so for example Pin's safe constructor `Pin::new()` can be re-expressed in terms of `!Move` instead of `Unpin`. Today you need unsafe code to pin a `!Unpin` (i.e. "movable") type. But I also suspect there are important differences between `!Move` and `Unpin` that I'm not sure about.

This whole thread summarizes what's wrong with Pin : it's so confusing everyone in here got something wrong. (Just to address your mistake in particular Unpin is almost the opposite of !Move : it's the trait that represents things that can be un-pinned, that is: moved despite having been pinned. See https://doc.rust-lang.org/std/pin/index.html#unpin ).

Right, of course. Yeah, it's an API riddled with so many double negatives it's hard to keep track.

Re: Rust project goals: Immobile types and guaranteed destructors

#98

Post by simonask »

spacechild1 wrote: post #81
simonask wrote: post #35

Earlier quoted context omitted.

> and is a major source why people dislike Rust's async It's worth mentioning that there is, in fact, no language out there other than Rust that can even do this in the first place. Some languages give the illusion that they support it by boxing the stack frame of async functions and letting a garbage collector deal with the consequences, but that comes with significant drawbacks too (additional GC pressure, heap all…

C++26 adopted senders/receivers (std::execution) as its official concurrency model, with the explicit aim of supporting structured concurrency. See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p23...

Skimming the proposal, that looks like the equivalent of the "executor" (scheduler) and "task" (sender) implemented in Rust async runtimes. I could have missed it, but I don't see anything in particular to help with managing structured concurrency?

Like, the central challenge is cancellation: In structured concurrency, subtasks spawned from a parent task must finish cancelling before the parent task can be cancelled.

Re: Rust project goals: Immobile types and guaranteed destructors

#99

Post by stymaar »

yoshuaw wrote: post #90
Dagonfly wrote: post #80

Earlier quoted context omitted.

Sure, thats one reason why IntoFuture and Future exist. Imo, in hindsight this is also main mistake in aysnc Rust: The whole async system should be build around IntoFuture rather than Future (async fn should return impl IntoFuture). That way you could pass around IntoFutures without being affected by auto traits leaking. Only when you actually call .await() or .poll() would the immovable Future materialize.

You're right that this is an important issue. I wrote a post explaining this in some detail, so at the very least we avoid having the same problem with generator functions: https://blog.yoshuawuyts.com/gen-auto-trait-problem

Thanks for the explanation (though I have to admit I liked your old blog theme more).

Since it's just a matter of how async get desugared, can it be changed through an edition?

Re: Rust project goals: Immobile types and guaranteed destructors

#100

Post by pjmlp »

virtualritz wrote: post #17
melodyogonna wrote: post #15

Earlier quoted context omitted.

Linear types requires significant work to incorporate into the core built-in collections and types. I've been following the work on Mojo to enable Linear type support for built-in types and collections, I don't think Rust's language semantics will allow for the same level of integration (Rust is already stable).

But Rust has editions. That is a big lever language designers can use if they painted themselves into a corner.

Editions are limited, there is this urban myth they can do anything regarding language evolution, but that isn't the case.

First of all they don't apply to the standard library currently, secondly the kind of automatic changes that are enabled and supported by rust fix, are limited.

It is not anything goes.

Post reply on HN