logoalt Hacker News

aw1621107today at 3:40 PM1 replyview on HN

> still a widespread issue in 2026

Is it "widespread"? The article you link is from 2022 and none of the discussion I saw on said article gave me the impression that it was particularly common issue back then, let alone now.


Replies

modularitynewtoday at 3:55 PM

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.

show 1 reply