3 ms·

Rust hasn't grown in scope very much since its release, but in places where it has grown, particularly async and unpin, I find that there features interact very

Rust hasn't grown in scope very much since its release, but in places where it has grown, particularly async and unpin, I find that there features interact very badly with lifetimes and borrowing. I am often forced to ditch borrowing across async method calls and to put everything in Arcs, even when the lifetime is well-defined and it could be easily used if it had been scoped threads instead of futures. I fear that newer features will be incompatible with older ones in a similar way, but fortunately there are no such features on the horizon. Considering all that, I still see Rust as the most sane choice for writing native programs. I don't really want a "better C", I want to write memory-safe software with confidence, and that means static analysis or a thick safe runtime, whatever is more suitable for the use case.

mr_00ff00 3y ago
Technically though, isn’t memory safety not necessary in some cases? For example, single player video games. You can exploit your own machine if you want, but that’s not an issue. I like rust, but if I ran into async issues and annoying stuff, I could see a world where I grab a non-memory safe language to make games easily.
- nequo 3y ago
  Crashing the program during runtime and having to debug it then is still a worse experience than knowing before running it that it cannot crash (due to memory errors). This certainty comes at a cost, either by negotiating with the Rust compiler or by putting up with a GC. But depending on your calculus, that cost might be worth paying.
- pjmlp 3y ago
  It is an issue if it also allows players to work around DLC and other goodies. Or if having the game on the system can be used by another malicious application as jumping point into root access, starting it as subprocess and injecting the exploit. Example, Windows attacks via Notepad.
- yjftsjthsd-h 3y ago
  Memory safety isn't just a security thing, it's also a reliability thing. That is, even if my games have zero security sensitivity I'd still like them to not crash or corrupt data.

mr_00ff00 3y ago

Technically though, isn’t memory safety not necessary in some cases? For example, single player video games. You can exploit your own machine if you want, but that’s not an issue. I like rust, but if I ran into async issues and annoying stuff, I could see a world where I grab a non-memory safe language to make games easily.

nequo 3y ago
Crashing the program during runtime and having to debug it then is still a worse experience than knowing before running it that it cannot crash (due to memory errors). This certainty comes at a cost, either by negotiating with the Rust compiler or by putting up with a GC. But depending on your calculus, that cost might be worth paying.
pjmlp 3y ago
It is an issue if it also allows players to work around DLC and other goodies. Or if having the game on the system can be used by another malicious application as jumping point into root access, starting it as subprocess and injecting the exploit. Example, Windows attacks via Notepad.
yjftsjthsd-h 3y ago
Memory safety isn't just a security thing, it's also a reliability thing. That is, even if my games have zero security sensitivity I'd still like them to not crash or corrupt data.