[gary17the]

> I love the idea of Rust, but the language itself seems needlessly complex

Well, I have to agree Rust isn't one of the simplest PL-s on the planet. This is due to the fact that it is quite a modern PL and quite a versatile PL, supporting elements of functional programming, trait-oriented (conditional generics) programming, asynchronous programming, etc. and a capable standard library on top of it all. It takes, indeed, quite some time to take all of that Rust in. As a reward, you get a lot of expressiveness and the capability to discover a significant percentage (if not an overwhelming majority) of your programming mistakes at compile time as opposed to runtime (unit/integration tests or Q/A), which to me is priceless.

Nevertheless, from my experience, Rust is, at the same time, one of the most... "consistent", "predictable", "internally symmetric" PL-s I have ever seen. I consider Rust to be way easier to learn than, say, Swift.

> `let` patterns can be used as conditions in `if`

I somewhat cannot help it but feel that such an example should not be used in an introductory tutorial. `if let` is usually used to pattern-match a simple `enum`[1], not a complex `struct` that looks "dense" unless you're used to it.

[1] https://doc.rust-lang.org/book/ch06-03-if-let.html

[bornfreddy]

> ...and quite a versatile PL, supporting elements of functional programming, trait-oriented (conditional generics) programming, asynchronous programming, etc. and a capable standard library on top of it all.

Yes, exactly! Now can I have just a safe C without all the other stuff, pretty please? :) I understand Rust is not it, but I hope someone comes up with a simple PL which is also compile-time memory safe. I think it would be an instant hit.

[dureuill]

> Now can I have just a safe C without all the other stuff, pretty please? :)

Not sure how much we could remove from Rust while keeping the problem tractable. The borrow checker is needed for compile time memory safety sans garbage collection. For borrow checking to be tractable, one needs shared references, exclusive references, owned values, the possibility for reference counting, and the possibility for interior mutability. This mandates smart pointers, that pretty much mandate generics. These various abstractions also mandate a capable standard library, unless the language would hardcode all these abstractions, which would endanger the low-levelness of the language (since you wouldn't be able to implement your own abstractions for e.g. embedded contexts)

For the demarcation between unsafe Rust and safe Rust to work, one needs encapsulation, so field privacy.

For concurrency, the language requires a way to mark types as thread safe, which requires a way to say things about structures, so a least a weak version of traits.

A smaller version of Rust probably exists, but I don't think we could remove as much of the language as we could imagine at first without compromising safety. It also wouldn't be "just a safe C", because C itself has heaps of accidental complexity (e.g. the way function pointers are declared, integer promotions, implicit conversions, the antiquated textual inclusion compilation model that is prone to ODR violations and complicates build systems, array decay, and so on...) that would need to be removed.

[gary17the]

> Now can I have just a safe C without all the other stuff, pretty please? :)

Hmmmmm, if you are not being forced by others into any particular Rust feature set (standard) and you are not being forced into any preexisting Rust codebase, then perhaps just forget the entire standard library, traits, async, etc. and go Bare Metal Rust[1], using only the Rust language features that you need and interfacing with external C APIs through Foreign Function Interface[2].

[1] https://google.github.io/comprehensive-rust/bare-metal.html

[2] https://doc.rust-lang.org/nomicon/ffi.html