I don't feel like C was ever meant to be the permanent foundation on which all other computing was built. It was a language for its time. It took assemblies of

I don't feel like C was ever meant to be the permanent foundation on which all other computing was built. It was a language for its time. It took assemblies of the 70s made them much more palatable with an imperative syntax. C++ was also not meant to be a permanent foundation. It took shortcomings in C for scale and hacked on top functionality Bjarne wanted. The complexity difference between a computer 46 years ago, almost half a century, when C was first developed and now is incomprehensible. It is reflected in how these languages, fundamentally, are willing to just say "since the computer only runs in 30 cycles a second and we are just doing increment operations if you break the rules it undefined" and the idea of having behavior native to the grammar that would impose kilobytes of size complexity or megacycles of computation would have been absurd. At the time, of course. Modern C++ doesn't hesitate to generate multiple vtables for a complex class while juggling reference counting smart pointers with streamlined initialization grammars that can take up thousands of words of memory. But because the primitives that must remain stable for backwards compatiblity were built on the most constrained architectures the whole house of cards is thus constrained. I think Rust has already made a lot of "just get it out there, don't think about the ramifications" decisions in its language design, especially around its grammar. On one hand there is still logic to what glyphs do what and how control flow is laid out - particularly concerning minimizing the number of retraced parses the source needs to go through - but it doesn't change the syntax of lifetimes ('), the use of double colon namespacing (::), or the turbofish but being an unintitive disgusting hack. In my experience the RFC process though has helped temper that. All those blemishes are predominantly from the origin of the language up through ~2014. Once the ecosystem developed and decisions required months or years of hanging around on the issue tracker to see stabilization Rust mostly stopped grafting on arcane behavior and started reusing its syntax in intuitive ways (like impl trait). I don't think any of the current crop of outstanding wants really makes the language more complex. A lot of it is just increasing the compliers complexity to handle more generic code, be it in terms of kindedness or by type delegation or inference. Those kinds of complexities aren't generally something for users to explicitly learn in rote memorization to use the language - if Rust introduced overloading and default arguments all those who don't know it exists won't have the language made any harder to use, but those that want it can take advantage of it. As long as Rust is never tempted into the "a substantial portion of this behavior is undefined if not done explicitly as intended" hole that C and C++ were predestined to fall upon I don't think features make the language harder. The core syntax is there, shouldn't change, and is being made easier and more intuitive, not harder and more complex (NLLs save the day, and the number of explicit lifetimes needed have been culled dramatically in the last two years of development). In just a few glyphs of C++: void* = 0 - there are already all manner of edge case, undefined behavior, syntactic complexity beyound comprehension. Nobody working on Rust today wants arcane, impossible to process grammar or undefined behavior complexity. The language already mostly lacks it. Nobody in their right mind will add it. Thats never a feature, its the bug Rust fixes that is inherent to the C lineage in ways nothing but a rewrite can fix. It took a decade of pain for Python to change its string type from bytes to unicode - there is absolutely no way to salvage C or any of its descendants. By design. From its fundamentals. All the complexity on top has just been repeated attempts to temper the fundamental incongruities.