I'd say Elm should be noted as here well. Both as a small language and as one that, like Lua, has been willing to make breaking changes by removing features. It doesn't include macro system, so unlike a Lisp dialect it won't be able to grow in that way either. It's still quite young compared to e.g. Python but similarly aged languages, such as Rust, have only grown in size.

If you are talking about syntax, Smalltalk has stayed pretty stable since Smalltalk-80. I can name only a very few extensions, namely traits, slots and dynamic arrays, and only the last of these required a change to the syntax of the language.

One of my biggest complaints with almost every language ever invented is that they don't mark the language level expected in each file, so that when a breaking change happens you can forward convert the file, and also so you can know what version of the compiler to run against. Languages can last decades, and natural evolution will mean that some code will stop compiling. It is often a trial-and-error process to get some C fragment to compile, because the code assumes some set of compiler flags, external to the source files, that are required to build it properly.

That is why in my Beads language i require the language version code on the first line of each file so that you can 1) detect the language without using the file suffix, and 2) know what version of the language was needed.

Language version marking should be included in every language, because code can last a very long time.

Two comments:

• Designers like to grow their language, but users are also a major source of pressure. If you have a large codebase in language X, you are incentivized to improve X to make it as good as possible for you, because switching to the new language Y is unreasonably expensive.

• The blog post assumes that having a big language is bad. Is there a way to build big languages so that they do not crumble under their complexity? Maybe having big languages would be fine if we did it right? Wikipedia is large, and seems to be doing okay. The package ecosystem of most programming languages (or system distributions, etc.) is large (much larger than the implementations of the language in any case), and people don't generally ask to stop publishing new packages. Can we make language designs and implementations more like those?

In particular:

• Does a given language feature have a cost for programs that do not use it?

• When evolving a language we have to think about how existing programmers will adapt, and also how new programmers in the future will learn the language from scratch. Can we propose systematic, better answer to those questions? You mentiond that language specifications are disappointing. Would there be a form of specification (for example: a reference interpreter intended only for documentation purposes) that could accelerate user's understanding of new features, and whose maintenance would structure the language evolution process? What about "how to teach this language", is there a form of document containing this information that could be maintained alongside the language, which would also contribute to the evaluation of language change proposals?

I know a lot less about languages like C# and the like, but I wouldn't be surprised if they've gone, or are going, through something similar.

C# has always been a fairly maximalist language, and has never in its history been shy about adding features. This is not to disparage the people behind it: Anders Hejlsberg (e.g.) is an exceptional language designer! But language size was never a priority.

Note that Python 1.6 and 2.0 were developed simultaneously and released one month apart (September 2000 and October 2000). 1.6 was really a "legal obligation" release that included the Unicode support and a licensing change; 2.0 used a different license. See the 2.0 release notes at https://docs.python.org/3/whatsnew/2.0.html#what-about-python-1-6 ; I co-wrote them.

As someone who enjoyed this post, I also enjoyed:

https://www.youtube.com/watch?v=lw6TaiXzHAE

The more I use Rust, the more I'm asking myself, "Why do we even need other programming languages?"

Rust simply does it all. I've used it to write low-level OS kernel and driver code. I've used it to write middleware. I've used it to write math-intensive graphics applications. I've used it to write text processing software. I've used it to write high-performance network servers. I've even used it as a scripting language for a simulator.

I haven't reached for other programming languages in years. These days, the only tool in my toolbox is Rust.