Comment by vacuity

3 hours ago

https://news.ycombinator.com/item?id=46684673 (reply to sibling)

> I think it's fair to expect that it will stabilize in time.

The allocator work is facing a lot of obstacles, unfortunately. I prefer it to be unstable for as long as it needs, though.

> Quite a few have already been implemented and are available as libraries exactly as you describe, today. I wouldn't phrase that as "Rust has GC" because that might imply that the GC is required.

This is exactly my point. Rust does not prevent GC by any means, but Rust also does not encourage GC by any means. The same goes for custom allocators, aside from the highly-unstable Allocator API.

2 comments

vacuity

Reply
timschmidt  3 hours ago

> The allocator work is facing a lot of obstacles, unfortunately.

Got any links? Sounds like interesting reading. Seriously. Kind of thing I come here for. I'd really appreciate it. Or I can ask the AI for some.

> I prefer it to be unstable for as long as it needs, though.

Sure, same. Fully baking things is a process, and it's nice when things are fully baked. So I agree. I think Rust's async could be a bit more ergonomic, though it wasn't too difficult to wrap my head around, and sort of shockingly simple to implement a basic no-std async executor (~10 lines), so maybe I'm coming around. I was pleased to find out that it was simple enough that I could do it, and understand how it worked, as I try to do with all my microcontroller code, and wasn't dependent on a big async runtime like Tokio if I didn't need it's features (or bloat).