February 1, 2025 at 1:18 AM, "Yuqian Yang" <crup...@crupest.life mailto:crup...@crupest.life?to=%22Yuqian%20Yang%22%20%3Ccrupest%40crupest.life%3E > wrote:
> > > > > Slightly off topic, but I was watching Bryan Lunduke make fun of the > > beta COSMIC desktop environment, which is written in memory safe rust. > > However, it seems to be using a lot of memory. > > ... > > There seems to be some interesting (though no code yet) of Hurd > > developers using Rust. > > ... > > ... Or is rust still not quite there yet? > > > I happened to have contributed to Neovide (a cross-platform GUI of Neovim), > which is written with Rust.[1] The patch is to add Metal (Apple's D3D) > GPU-accelerate renderer on macOS. > > Here are my humble opinions on memory-safe languages like Rust. The ultimate > rule > is nothing can be *unconditionally* memory-safe. > > 1. Rust has some conditions to be memory-safe, that is you never use `unsafe`. > However, there are two common situations where `unsafe` is required. > > - When you have to interact with C library, aka, some kind of fii, > you must use `unsafe`, which, of course, can never be avoided in low-level > development. The reason of the requirement of `unsafe` here is Rust can't > promise memory-safe of the external C library. > > In my case, I have to interact with Apple's GUI and Metal api, which is > actually in objective-c. So I must use `unsafe`. > > - When something can not be expressed in Rust memory-safe semantics. One > important case of this is you need to use "partial ownership", which is not > allowed in `safe` Rust. Many std structs use this a lot internally actually. > One typical case is to split a slice into 2 slices, via `split_at`[2]. It > will finally call `split_at_unchecked`[3], which is `unsafe`. The reason is > apparent. You need "partial" of the slice. > > The Rust has already written an offical book for the `unsafe` problem, which > is an essential material of Rust.[4] > > 2. Even if a programming language is memory-safe for its special mechanism, > like > Java, which has a JVM to do garbage collection, or Rust, which is memory- > safe via its semantics, there is always one kind of "memory leak". It's > a super simple logic. > > If you create a global variable, it has a list, and you add a lot of elements > to it, but you forget to delete them when you no longer use them, they are > actually leaked. No language, whether has a VM or some other mechanisms, can > stop > you from this unless global variable is not used. > > So how Rust helps us? The reason is actually simple, too. If you don't > interact > with low-level things, and what you need to do does not escape the range of > Rust > semantics, aka, you don't have to `unsafe` yourself, you can definitely use > Rust. > Without `unsafe`, its semantics will ensure you stay memory-safe, which is > regulated by its compiler and the ownership checker in it. Std already wraps > most > `unsafe` things for you, so you don't have to `unsafe` yourself for these > fundamental > constructs. The typical use cases are, Web Service, GUI application, even Web > Browser Engine[5], etc, with the help of various packages made by community > contributors of Rust. > > Oh, a lot of words. Please forgive me for being unable to control my mouth on > this topic. > > Hope it can help you a little! Feel free to discuss with me and point out my > mistakes! :) > > BTW, maybe I can put this in my blog later, hahaha! Thanks for the explanation! Please do blog about it someday! > > [1] https://github.com/neovide/neovide/pull/2461 > [2] https://doc.rust-lang.org/std/primitive.slice.html#method.split_at > [3] > https://doc.rust-lang.org/std/primitive.slice.html#method.split_at_unchecked > [4] https://doc.rust-lang.org/nomicon/index.html > [5] https://servo.org/ > > -- Yuqian Yang <crup...@crupest.life> >
