| ▲ | modularitynew 9 hours ago | |||||||||||||||||||||||||
Indeed it is, read this: https://old.reddit.com/r/rust/comments/1v54et2/what_are_the_... https://old.reddit.com/r/rust/comments/1v54et2/what_are_the_... Links for anyone without a Reddit account: https://redlib.catsarch.com/r/rust/comments/1v54et2/what_are... https://redlib.catsarch.com/r/rust/comments/1v54et2/what_are... It is a mess, temporary lifetime extension is a mess in both Rust, C++ and Zig (despite Zig not having RAII unlike Rust and C++). Interestingly, Mojo might avoid some or all of that, by having some destructors be implicit, and some destructors be explicit, https://mojolang.org/docs/manual/lifecycle/death/ , requiring users to write the destructors manually. Thus, a lock in Mojo can be forced by the compiler to be explicit, and that prevents the Rust problem of https://fasterthanli.me/articles/a-rust-match-made-in-hell , since developers will have to explicitly destroy the lock in Mojo. C also does not have that temporary lifetime extension issue, since there is barely any temporary lifetime extension in C, apart possibly from compound literals, but compound literals might also have some issues and involved rules. The edition system in Rust tripping LLMs up is not great either. That can happen because the same code in one edition of Rust can have very different behavior in another edition of Rust, like the same piece of Rust code having a deadlock in one edition and not in another. | ||||||||||||||||||||||||||
| ▲ | aw1621107 7 hours ago | parent [-] | |||||||||||||||||||||||||
Interesting, thanks for the links! I'm curious as to how many of the apparent issues are attributable to lifetime extension specifically as opposed to something else like async-related deadlocks as mentioned in the parent to the first linked comment (which I feel I've heard much more about), especially after the Rust 2024 changes. That being said, after a bit more searching I found this 2023 blog from one of the Rust devs [0] which supports the "widespread" description at the time: > One very common problem is deadlocks (or panics, for ref-cell) when mutex locks occur in a match scrutinee so I think we can chalk this up to me being insufficiently well-read. I think it would be interesting to see to what extent the Rust 2024 changes alleviated the problem since it only changed if let, but I haven't found that information (yet). There's also this related work [1], but I think the scope of that is rather larger. > Interestingly, Mojo might avoid some or all of that, by having some destructors be implicit, and some destructors be explicit, [] , requiring users to write the destructors manually. There's some relevant exploration being done in Rust that in principle could enable linear types [2], though obviously it remains to be seen to what extent this work will pan out. [0]: https://smallcultfollowing.com/babysteps/blog/2023/03/15/tem... [1]: https://blog.m-ou.se/super-let/ [2]: https://github.com/rust-lang/goals/blob/main/src/2026/move-t... | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||