The author reflects on their experience with the Rust programming language, likening it to the first generation of the iPhone—innovative but incomplete. Initially captivated by Rust's features such as memory safety and a modern package manager, the author expresses frustration after four years of use, feeling that the language has stagnated. They note a significant slowdown in the introduction of new features, with many promising ideas, like coroutines, remaining unimplemented despite being in the pipeline for years. The author suggests that the Rust community's consensus process has become unwieldy, leading to a graveyard of good ideas that never see the light of day. The author fantasizes about forking the Rust compiler to create a new version of the language, which they refer to as "seph." They propose several changes, starting with the introduction of function traits, which would allow developers to specify properties of functions, such as whether they can panic or if they are pure. This would enhance the language's ability to guarantee certain behaviors at compile time, addressing concerns like ensuring that specific blocks of code do not panic. Another significant proposal involves implementing compile-time capabilities to mitigate supply chain risks associated with third-party crates. The author suggests that functions interacting with sensitive operations, like file system access, should be marked with capabilities that require explicit whitelisting in a project's configuration. This would prevent potentially malicious code from being executed without the developer's knowledge. The author also critiques the complexity of Rust's Pin and borrow checker, arguing that the current implementation complicates the language unnecessarily. They propose a more intuitive system that would allow developers to express borrowing semantics directly in their code, making it easier to work with self-referential structures and async functions. Additionally, the author expresses admiration for Zig's compile-time capabilities, suggesting that Rust could benefit from a similar approach that allows developers to write compile-time code using the same syntax as regular Rust. They also list smaller improvements they would like to see, such as better ergonomics for raw pointers and enhancements to the language's collection types. In closing, the author acknowledges that many of their proposed changes would be incompatible with existing Rust, potentially requiring a new edition of the language. They express reluctance to engage with the RFC process, feeling that it often leads to frustration and unfulfilled ideas. Ultimately, they contemplate the possibility of forking Rust to implement their vision, though they recognize the challenges involved in such an endeavor.