[AboutTheWhisles]

I'm not sure an anecdote about about a software project failing twice and succeeding on a third try can be used as evidence the the language of the third try enabled something to be pragmatically possible. I'm sure rust helped, but I'm also very confident that I could architect even a large scale project in C++ well enough that it would remain modular and progress could remain steady.

[steveklabnik]

The team said it, not me. (I realize I didn’t make that clear before) There was a talk at a Rust conference about it in detail.

Modularity was not the issue. Complexity combined with concurrency was. Rust’s compile time checks was what made it feasible to be so aggressive without the bugs.

[AboutTheWhisles]

I was already assuming that concurrency was a big part of that statement. I respect Rust's attempt to solve these issues at the language level, but my experience has led me to think that they need to be solved at the architectural level of a program.

As far as I can tell, concurrency is fundamentally about grouping data by dependencies to find chunks that can be isolated. I think that resources are more about lifetimes and ownership and that resources and data aren't the same thing. This doesn't contradict what Rust is doing, it is more about relying on the language less.

You can see what I'm talking about in this link, though I don't think it has been digestible enough yet without video or examples.

https://github.com/LiveAsynchronousVisualizedArchitecture/la...

https://github.com/LiveAsynchronousVisualizedArchitecture/la...