For a fun time, try implementing a C compiler for 6502. 256 byte stack, 8 bit index registers, single accumulator, 64K RAM max (which only became affordable in the mid 80s). Those are the types of constraints compiler writers were facing at the time.

"Features" weren't hard to compile because they were difficult to reason about, they were hard to compile due to physical constraints of the hardware.

While it might have failed in the long term anyway, Multics didn't fail because of market reasons. It failed because first, Honeywell was incompetent at developing serious hardware, e.g. officially blaming the failure of the first (and only, I guess) clean slate Multics CPU project on the decision to microcode the machine. Something which IBM had previously used in the System/360 to dominate the market....

That caused more and more problems as its async CPUs fell further and further behind, although this was still in the discrete logic days, and you could easily use up to 6 in a configuration, and more with a kludge. But it was still selling well, especially in France, where Bull seriously pushed it.

Then it was deliberately killed off due to internal politics, it seems that trying to smash together three computer companies, Honeywell's original stuff, GE's including Multics, and SDS -> Xerox -> Honeywell, creates a situation where killing off rival systems makes sense to political winners who just might not be technological winners.

That Multics was doomed by all this was self-evident to me in the 1979, one reason I never spent any serious time on it.

"Sounds like BCPL was an excellent tool for their use case, and in providing power with a low difficulty for implementation"

This is supposed to be a quick, digestible history. Your statement shows I might have chopped it too much myself. :) Work like Wirths...

https://news.ycombinator.com/item?id=12316092

...showed you can have a great baseline that trades against many somewhat-contradicting criteria without much difficulty in compiler. Something better was definitely doable, esp when C was being made. We can't know exactly what was in BCPL author's head as he and his team chopped this feature vs that feature of their ALGOL. What I do know is the constraint they had, which we don't, is the EDSAC they worked with. Here's you a great video of how glorious software development was for these people:

https://youtu.be/6v4Juzn10gM?t=3m41s

This computer was a glorified calculator. It had basically no processing or storage capability as we'd think of them today. They interacted with it using program tapes that were manually created. Everyone in building queued up to use and share it. The iteration time was long and increments had to be short. The developments were likely done on paper by a team who contributed to what would eventually be on the tape submissions. Truly a nightmare for someone trying to build an ALGOL or even a GCC for that matter. Hence, Most Godawful Computer on Earth. :)

It was that computer's limitations, in development time & running speed, that forced them to chop off features they knew were important. They probably had no choice. Later on, with a PDP-11, Wirth et al showed there was a choice for key features on better hardware. Thompson really liked BCPL... personal preference... since he used it on MULTICS project & toy projects. Wanted some MULTICS capabilities minus scope & hardware cost.They modified BCPL because he liked its style to put a slim, unsafe variant of MULTICS on a PDP-7 and PDP-11 because it couldn't fit OS safety features. Hardware weaknesses also crept into the stack direction, IIRC null pointer issue, bin vs sbin, and so on.

Once you know all this, you can make a more informed decision about how to improve C or avoid it. You can say, "Am I using an EDSAC-equivalent to build a compiler? Yes? Then BCPL or C maybe. If not, then go for default safety & modularity of Modula-2/3 given your job at OS & app levels are going to be way easier outside lowest layers." For OS, you might say, "Would it be easier to code the OS like any other application a la Wirth's Oberon with checks disabled for slow hardware and enabled for good hardware? Or should we just get rid of them permanently in a way that will require breaking apps later to improve?" UNIX went with latter but many others did former successfully. So, we know it can be done.

Stuff like that comes from knowing better models existed even for limited hardware + many design decisions were hardware constraints or personal preferences. And our current constraints/goals are different. So, the language should be. Gotta know the history to see that clearly. Lots of misinformation out there instead.

"Don't over-engineer your products, or you'll end up with a product that fails in the market; like MULTICS."

Or engineer it well to get those that dominate markets. Examples include Burroughs (Unisys) & IBM mainframes, the AS/400, OpenVMS during minicomputer era, the huge UNIXen (incl GNU/Linux) dominating servers, and the desktop clone/mod of OpenVMS Cutler did for Microsoft that had most desktop market-share last I checked. iPhone, opposite of simple platforms predating it, also dominates its market to point it made them $80+ billion. If anything, market-share and where the money is going contradicts your claim. Most simple, easily-modified OS's and tool-chains don't go anywhere with social, business, ecosystem, etc effects pushing the successful ones most of the time whether simple or ridiculously complex.

"C and Unix succeeded because they were simple to re-implement and/or port."

A combo of things I'm still collecting for accuracy. They were on common, cheap computers that had lots of users. The software on those sucked to point many tried creating their own. UNIX and C were small, met PDP needs decent enough, free, open, and easy to port. Initial spread created ecosystem effects. A combo of the open ecosystem and corporate suppliers turned a trickling flood into a tsunami of ecosystem effects. That inertia, resulting dependencies (i.e. backward compatibility), and psychological factors ("Linux is for cool, smart people!") keeps it going. Lessons to learn for successful projects (esp "Build a Killer, FOSS App!") but luck was a big factor much like for Microsoft's success. Successes will usually be smaller than UNIX/C if taking similar approach due to them being at right time & place for revolution. :)

"It's not like C and Unix stopped development, either. Let's not ignore the last 30 years, now."

This essay is about actual place C's design problems came from so that people know they're not justified in either clean-slate or C-related development. Need to get rid of them incrementally starting now. I totally agree with you that the world kept turning in more interesting directions. The comparison points from better stacks were how I knew to dig into UNIX and C's history in the first place. Plus all the ways I know to do fast, safe, low-level coding without C. ;)