rust-realworld-entrait VS rust

I'm working on a PoC to rewrite the realworld app from launchbadge to use entrait: https://github.com/audunhalland/rust-realworld-ioc/ (work in progress), maybe it can be used as inspiration.

modules are meant to be the boundary for a safe abstraction, but sometimes you get fun holes like https://github.com/rust-lang/rust/issues/128872 where you can implement Copy for a type in a different module in the same crate, even if the fields are private

>Use Zig as a zero-dependency, drop-in C/C++ compiler that supports cross-compilation out-of-the-box.

I know barely anything about Zig, so I don't know the veracity of this, however.

Rust's FFI also relies on undefined behavior if this comment isn't outdated https://github.com/rust-lang/rust/pull/59625#issuecomment-48... https://github.com/rust-lang/rust/blob/master/library/core/s... . Might not be an issue as long as the implementation is only used with LLVM and LLVM doesn't change.

Mountpoint is a new FUSE based solution written in the Rust programming language and based on a Rust version of the Linux FUSE library. See here for an explanation of the choice of Rust. Other popular tools in the FUSE-based family of solutions are goofysand s3fs.

Yep, and even without dynamic memory management, Ada is not type-safe: https://www.enyo.de/fw/notes/ada-type-safety.html

Rust also has problems: https://github.com/rust-lang/rust/issues/25860

The bug used by that repository [1] isn't the only one that can be used to escape the Safe Rust type system. There are a couple others I've tried [2] [3], and the Rust issue tracker currently lists 92 unsoundness bugs (though only some of them are general-purpose escapes), and that's only the ones we know about.

These bugs are not really a problem in practice though as long as the developer is not malicious. However, they are a problem for supply chain security or any case where the Rust source is fully untrusted.

[1]: https://github.com/rust-lang/rust/issues/25860

[2]: https://github.com/rust-lang/rust/issues/57893

[3]: https://github.com/rust-lang/rust/issues/133361

Since at least 2018, there's been a planned upgrade to the borrow checker to permit certain patterns that it currently rejects [0]. Also since 2018, there's been an implementation of the new version (called Polonius) that can be enabled with an unstable compiler flag [1].

But it's 2025, and the new version still hasn't been enabled on stable Rust, since the Polonius implementation is seen as too slow for larger programs. A big goal of the types team since last year has been to reimplement a faster version within rustc [2].

I'd count this as a language feature (albeit a relatively minor one) that's been greatly deferred in favor of shorter compile times.

[0] https://blog.rust-lang.org/inside-rust/2023/10/06/polonius-u...

[1] https://github.com/rust-lang/rust/pull/51133

[2] https://rust-lang.github.io/rust-project-goals/2024h2/Poloni...

> Is there evidence more baking won't happen?

No, actually there is a lot of evidence that it will still be worked on.

Normally I would just say look at the issue linked in the nightly docs but due to an overlap of tacking PR and moving it from std to core PR it's not supper useful.

Tracking Issue: https://github.com/rust-lang/rust/issues/78485

If the author has constructive critique they should probably mention it there (after skimming through the discussion to make sure this wasn't already considered and not done due to subtleties they overlooked in the blog post (like e.g. that it's a standard/core feature which has to work across all targets and as such can't rely on anything being initialized to 0 by the OS, or that depending on the global allocator used you definitely can't rely on things being zeroed even if the OS only hands out zeroed memory, etc. etc.))

I recently had the need to subscribe to changes to a Github repo and it turns out it provides a feed for them. For rust master branch, for example, subscribe to https://github.com/rust-lang/rust/commits/master.atom.