Some of the difficulties in large projects include:

1. It's easy to break things accidentally, and it's hard to track down all the usages of something when you change it. This is especially true when functions and types can be aliased under different names, changing a class affects all subclasses, etc. The more complex the application, the more you get pervasive usage of types defined within the application. This is a real change from smaller applications where most of the pervasive types probably come from the language's standard library, which can be trusted to be stable between major releases.

2. A large codebase means that whatever finicky housekeeping the language requires is almost guaranteed to get screwed up somewhere in your application. If this affects the integrity of the whole app, it can be very bad. Invalid memory accesses are an infamous example. It doesn't matter if you have a million lines of awesome, feature-filled code; if one buggy line of code crashes your app every ten minutes by dereferencing an invalid pointer, your app is unusable.

3. Fragmentation of types and libraries. Programmer X adds a Flugelhorn library on one end of the app, programmer Y adds a Flugelhorn library on the other end of the app, and nobody realizes it until incompatible Flugelhorn types start bumping into each other in the middle. This is less of a problem for a community where "programming in the large" means many people writing many small independent projects, but it could be a major annoyance for a language where the goal is to write large, complex applications such as web browsers.

4. Concurrency. Concurrency can be a coupling factor that requires programmers to know too much about global design and global state. It can also destroy performance and stability. Finally, given principle #2 above (every large running application contains screwed-up code somewhere) runaway tasks are a threat to the whole system if not contained. When done well, however, concurrency can reduce coupling and improve stability.

5. It can take a long time to rebuild a large codebase and run its tests.

I don't know much about Rust so far, but here's my stab at matching the features of Rust against those five problems:

1. Compile-time type checking is a big help. Rust also has some ways to enhance types without subclassing.

2. Memory safety, garbage collection, errors that propagate upward by default, isolated tasks. Error handling is unappreciated in this category, I believe. It's important that an application not accidentally suppress an error and continue, because it could corrupt data, return incorrect results, or behave insecurely. A language like C where errors can be swallowed through oversight or programmer laziness is dangerous in that regard. In Rust, errors propagate upward, unwinding the stack until they terminate a task or are explicitly handled.

3. Generic types help, and built-in support for Unicode text is a necessity. It also helps that the organization shepherding the language is likely to be the biggest user of the language. It's important to note that anything that helps with #3 also helps with #1. For example, if the language has a standard string type you can use everywhere, then your tests don't need to protect against Doug down the hall (or across the world) changing the string type and not realizing he broke your code.

4. Immutability, message passing, isolated tasks, per-task GC. It sounds like Rust is trying to make task isolation the default way to firewall errors off from the rest of your app. For a web programmer, this is exactly like the way a Java web container is supposed to work. If one web app in the container goes haywire, the container and all the other web apps should ideally be able to continue running without their stability being compromised.

5. I don't know what techniques are used by Rust to speed up compilation. A compiled language is at a disadvantage on this count, but compiling to object code is necessary for a systems language. Also, static type checking means drastically fewer unit tests (I don't want to start a flamewar about whether this is a good thing; it's just the way people code) so you get a little bit of your lost compile time back when you run tests.