[oconnor663]

> just C but with strong typing, a borrow checker and what would basically be super strong static analysis of pairing malloc() and free()

Most of Rust's features interact in ways that aren't obvious. For example to get the basic memory safety guarantees that the borrow checker provides, you also need:

- the "no mutable aliasing" rule

- destructive move semantics and the Copy trait

- generic containers like Mutex and (probably?) generic enums like Option and Result

- thread safety traits like Send and Sync

- closures, and closure traits like FnOnce

Of course yes, you can have "safe C" without async, and Rust 1.0 shipped without async. But I think it's notable that The Book doesn't teach async. Most of the things The Book teaches are actually necessary for memory safety to work.

[lionkor]

It doesnt matter what The Book teaches - for example a majority of Rusts web-facing ecosystem uses some async, which means

1) tokio, which uses unsafe{}, and/or

2) async functions requiring all calling functions to also be async

So, really, you can't avoid it. The ecosystem is built on the idea of NIH, which is fine, if it wasnt for so many rust features you can abuse so heavily (e.g. macros to make your own language that I then have to learn).

There are a lot of issues with the complexity Rust brings.

[flohofwoe]

IMHO a 'rusty C' wouldn't need to cover the entire memory safety feature set that Rust provides, it just needs to be 'close enough' and otherwise warn in areas where the compiler isn't entirely sure. It can also do some checks at runtime at the cost of a slight performance hit (but again, in old C tradition this should be controllable by compile options).