> That's why so many useful things start with a single person or *a very small team*,

You subtly shifted the goal posts here. But even if you start out with a single person you eventually have to have new maintainers, if only because of human mortality. Software is a young field so we haven't had to contend much with this fact yet, but it's inevitable.

Personally I think something like Rust is helpful for large solo programs too, keeping everything in your head past 10kCLOC is hard so why not have a language and compiler that helps you?

My personal opinion is that Rust is a bit too lengthy to keep everything in your head. For a solo program, I'd probably go with Python first, just because it tends to produce very short and yet readable source code.

And yes, I shifted the goal post a bit by assuming the team to be medium to large in size. If I assume a very small team like the initial Photoshop release with 2 people closely working together every day, then I think their communication will be so good that there aren't "many things that make working on team code dangerous" left. So in that case, I wouldn't expect much benefit from using Rust.

> My personal opinion is that Rust is a bit too lengthy to keep everything in your head

I'm curious what you mean by "lengthy" here. The reason I say Rust lets me keep fewer things in my head is because something like this in C:

    struct Bar {};
    
    struct Foo {
        struct Bar *bar;
    };

where it's no clear if Foo owns Bar or merely outlives it, becomes

    struct Bar;
    struct Foo<'b> {
        bar: &'b Bar,
    }

in Rust and I no longer have to keep this information in my head.

Interesting, it's mostly concepts and architecture in my head, and less lines of code.

Ugh, seen this pattern happen many times at smallish companies. The O.G. codebase was written by a single person. It did one or two things very well, with few bugs, had consistent filenames, variable names, APIs, formatting, and so on, it had a single, pure vision throughout the code, and didn't have all those problems that happen when multiple people reason differently about the same code.

Then, eventually, the company gets bigger and the product needs to grow beyond the capability of one person, so a team starts developing on the codebase. That's where the bugs start pouring in, where everything becomes less consistent, where different design patterns are used all over the place, and where the "single clear vision" gets cast aside. A lot of problems that get blamed on "technical debt" and "brittle code" are often just plain coordination and consistency problems that are happening because multiple people can't share a single consciousness.