a-mir-formality
unsafe-code-guidelines
Our great sponsors
a-mir-formality | unsafe-code-guidelines | |
---|---|---|
4 | 74 | |
244 | 639 | |
5.7% | 2.2% | |
9.3 | 6.9 | |
3 months ago | about 1 month ago | |
Rust | ||
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
a-mir-formality
-
My resignation letter as R7RS-large chair
Racket is very used in the PLT community (programming language theory) for prototyping programming languages. Lots of cool stuff in this area.
For example, the MIR formality [0] project of the Rust programming language to formalize MIR (their intermediate language) was first prototyped in Racket [1], then rewritten in Rust. [1]'s readme give a rationale:
> For the time being, the model is implemented in PLT Redex. PLT Redex was chosen because it is ridiculously accessible and fun to use. It lets you write down type system rules and operational semantics and then execute them, using a notation that is very similar to what is commonly used in published papers. You can also write collections of unit tests and fuzz your model by generating test programs automatically.
> The hope is that PLT Redex will prove to be a sufficiently accessible tool that many Rust contributors will be able to understand, play with, and extend the model.
> One downside of PLT Redex is that it doesn't scale naturally to performing proofs. We may choose to port the model to another system at some point, or maintain multiple variants.
[0] https://github.com/rust-lang/a-mir-formality
[1] https://github.com/rust-lang/a-mir-formality/tree/1f40120f09...
- Officially announcing the types team
-
Why are Rust programs slow to compile?
But MIR optimizations are a bit of a mess right now. The semantics of MIR are not completely settled but that is an area of active work: https://github.com/nikomatsakis/a-mir-formality
-
Announcing: MiniRust
That's happening separately, in the "mir-formality" project: https://github.com/nikomatsakis/a-mir-formality
The two projects are related, but have different objectives (mir-formality includes traits and borrow checking, while MiniRust focuses on operational semantics).
unsafe-code-guidelines
-
Passing nothing is surprisingly difficult
Useful context on the Rust side is this issue [1]. It sounds like some of the author's concerns are addressed already.
[1]: https://github.com/rust-lang/unsafe-code-guidelines/issues/4...
-
Blog Post: Non-Send Futures When?
Is this captured by one of the known soundness conflicts? If not then should consider adding it to the list.
- Are crates like vcell and volatile cell still unsound?
-
Question: Are there things for Unsafe Rust learn from Zig?
There are some competing proposals for different memory models. Stacked borrows is the current proposal, but there are more work in the approproate WG.
-
Let's thank who have helped us in the Rust Community together!
Thank you /u/RalfJung for bringing formal methods to Rust, both through models like Stacked Borrows, by developing miri, and by working on unsafe-code-guidelines which aims to specify exactly what is and isn't allowed in unsafe code (surprisingly, it's an open question as 2023!)
- Questions about ownership rule
-
Noob Here: Why doesn't this work?
You could imagine some way to make this safe for example automatically convert &'short &'long mut T to &'short &'short T, but it's non-trivial to prove they are safe at all, not to mention ensuring this is correctly implemented in the compiler. If you're interested there's also a discussion on whether the opposite (& & T to & &mut T) is sound here.
-
When Zig is safer and faster than (unsafe) Rust
Agreed! MIRI is so good, it still feels like magic to me. It also comforts me that the Rust team takes improving unsafe semantics seriously, with the past Unsafe Code Guidelines WG and today's operational semantics team (t-opsem).
-
Safety and Soundness in Rust
I think there are some aspects of this rule that are still undecided. See for example:
- https://github.com/rust-lang/unsafe-code-guidelines/issues/8...
- https://github.com/rust-lang/miri/issues/2732
-
I wanna be a crab.
C is much better specified than unsafe Rust. Some things are just not worked out yet in Rust. This may sometimes even bite very experienced devs, such as this issue with Box's aliasing semantics, which tripped up the author of left-right.
What are some alternatives?
datafrog - A lightweight Datalog engine in Rust
tokio - A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
renegade-way - Option Trading Application
rust - Empowering everyone to build reliable and efficient software.
minirust - A precise specification for "Rust lite / MIR plus"
rfcs - RFCs for changes to Rust
r7rs-spec
x11rb - X11 bindings for the rust programming language, similar to xcb being the X11 C bindings
options-chain-marketdata.ps1
bevy - A refreshingly simple data-driven game engine built in Rust
r7rs-work
miri - An interpreter for Rust's mid-level intermediate representation