[celeritascelery]

I will agree with you that most languages should just be gc. Rust is niche; targeted at applications where you need control over memory and layout. It is not a good general purpose language.

That being said, most of things you pointed out as “no reason to be this complex” do have good reasons. String and &str could be renamed to StringBuf and StringSlice. The String type lets you manipulate the string value, but it is a bigger type than a slice (&str). &’static just indicates that the string slice will live for the entire program. As you continue to learn Rust, more of these distinctions will make sense to you.

GAT’s themselves are actually a great example of a feature that adds capabilities without really adding complexity. They feel like they should have always been there, and I feel like anyone who has worked with the language for a while has implicitly tried to do this and was surprised it didn’t work.

[Smaug123]

> I feel like anyone who has worked with the language for a while has implicitly tried to do this and was surprised it didn’t work.

Just to lend some extra evidence to your assertion, I hit the lack of GATs within two days of starting to learn Rust. In the natural course of trying to solve a problem, I tried to write `LendingInterator`, and discovered that I could not.

[kibwen]

Agreed, people should not assume that the design of Rust is some sort of statement about how higher-level languages should operate. It's a very targeted design with specific goals. For instance, the fact that Rust eschews exceptions should not be interpreted as "exceptions are bad", but rather "we don't think exceptions are a fit for what we're trying to achieve in this one specific domain".

[return_to_monke]

String was indeed once named StrBuf: https://github.com/rust-lang/rfcs/pull/60

[oxff]

> without really adding complexity

Pretty sure many relevant contributors have said it is the most complex language feature since async ..

[celeritascelery]

certainly complex from a implementation standpoint, and some of the rough edges can be a footgun around lifetimes until those are ironed out. But being able to add generic arguments to associated types is just a natural extension of the language from a user standpoint. You could already add generic arguments to functions, structs, type aliases, enums, etc. This just allows it in one more place.