one core thesis of rust is that history has adequately demonstrated that humans do not have sufficient vigilance

I think this is obvious if you've ever worked in a large project.

Yes, you can always avoid making mistakes, but you can't make others avoid the same mistakes. It just never scales.

The software industry on the other hand is scaling heavily. Which is why what worked in the 80s isn't good enough anymore.

My line of thought - which is perhaps partly and indirectly based on "Small is beautiful" [1] applied by others to software - is that if "large project" is what gets you into (various) troubles, then you should avoid doing this. And indeed, the idea of breaking large projects into small, human-size components is a common "good practices" recommendation.

OTOH I experience quite the opposite everyday in the software industry, so I understand one could reject that position as too idealistic.

[1] https://en.wikipedia.org/wiki/Small_Is_Beautiful

> [I]f "large project" is what gets you into (various) troubles, then you should avoid doing this.

This makes perfect sense and I do agree. But I also wonder what you would say to someone writing, say, an operating system or a browser? Projects that are inherently large and where the stakes of errors are high.

I do think you need great safety and abstractions to raise your complexity ceiling to the level of these projects, if that's what you've set out to do.

An OS is actually not that "large" - at least if one looks at Linux. If you do a simple LoC count you do get an answer in the millions, yet the core is much smaller and the rest is in a bazillion of drivers.

Browser are the typical case of a project/product that became bloated over time; they began as relatively simple document downloader and viewer, but now they are also application downloader and execution environments. This causes all kind of problems for users and implementors. The answer is somewhat eye-rolling: we should go back to Flashplayer times (with something better than FlashPlayer though). Let browsers handle HTML/CSS, and delegate everything else (PDF, big media files,...) to dedicated applications chosen by the end user. One can still do that, indeed, except it has become more and more difficult - even for simple text-and-images documents - because websites are abusing Javascript capabilities.

"we have to handle complexity better" is the common way of thinking, and I think it is wrong as a first reaction. Trying to lower the complexity first is better.

I agree that it's better to reduce complexity and that browsers have been subject to mission creep, but a.) I'm not really convinced that adding more integration points will reduce complexity and b.) the mission creep already happened - I don't think we get to reverse it. Creating an application platform _is_ the mission of a browser now. I think there would be value in an alternative such was just a simple document viewer and form filler, but it'd be a different kind of application and customers would need to be sold on it from scratch.

Is your position that no project needs to be large if we employ the right strategy, or that we should look at our complexity ceiling and say, "okay, that's how large a project we can take on?" Or something else?

After skimming that Wikipedia article, I think I understand better that your criticism is that these are inappropriate technologies & that we're increasing our complexity budget instead of making technologies that are more appropriate. And I do fully agree with that.

Thank you for mentioning this book, I look forward to reading it.