I would absolutely not call Rust a simpler Swift. Swift doesn't have and ownership/borrowing system, explicit lifetime for objects, much more expressive (and therefore complex) macro support...

I get that there's a tradeoff. Rust requires you to be way more explicit about what you're intending upfront and that can, in the long term, lead to simpler code -- but there's no dimension (depth-wise or breadth-wise) that I'd call Rust simpler.

Rust is still more complicated than Swift, but you needn't worry - the Swift team is flexing their muscles hard to ensure that Swift becomes the biggest, most complicated language on Earth and wins the complexity, cognitive burden and snail performance once and for all eternity. Their compiler already times out on the language, soon even an M7 will also give up.

One of my recurring language design hot takes is that it's easier to design for speed and then make it easy to use than it is to make it easy to use and then try to speed it up.

    #include <print>
    #include <map>
    #include <string>

    int main(int argc, char** argv) 
    {
      using namespace std::literals;

      std::string foo = "foo:";
      foo += argv[0];

      std::map<std::string, int> m{
        {foo, 123}
      , {"count: "s + std::to_string(argc), 456}
      };

      std::println("{}", m);
    }

Except the entire design of swift is meant to make everything more automated.

* automated exclusivity with value types and value witness tables, classes as arc types (ie Arc<Mutex<T>>)

* automated interop with C/C++/Obj-C through the clang ast importer

Maybe they could have started with rust and added on what they needed, but why not build a new language at that point where things so fundamental are involved?

Source: I worked in lattners org at the time of swifts inception (on an unrelated backend) but that was the motivation. I also worked on the swift compiler for a little bit some years later on in my career.