Classic, and timeless. (HT: Patricia Aas, Tony Van Eerd and Peter Sommerlad)
Note that when he says “growing a language” he doesn’t mean literally the language itself — it’s not a talk about language evolution. Rather, he’s talking about enabling users to write rich and powerful abstractions in that language without having to go beg their language designer and compiler vendor to build them into the compiler every time.
Steele’s argument in the back half of the talk is on point, on the importance of imbuing a programming language with a few well-chosen “patterns” that allow, and guide, specific kinds of extensibility. His argument is a great description of why I’m pursuing metaclasses for C++, because we should have a convenient way for programmers to write their own Words of Power like “value_type” or “interface” as libraries instead of forcing them to go bother their local compiler writer (or local standards committee) for a language extension each time for that sort of thing. And his “as a pattern” description is a great summary of why I’m proposing them as “just” a sugar to apply a compile-time function in a very specific place and in a very constrained way, and not going anywhere near making a mutable language which would be crazy not worth pursuing.
Sutter’s Mill 
Trust the programmer! Remembering that principle extinguished the concerns I had. The best feature of metaclasses is that programmers decide how they are used or abused. I would prefer them over any multifurcation of the type system. As a warning example, in C# the meaning of assignment operator depends on the keyword with which type was declared! The poor programmer has to keep in his finite head those keywords in addition to all else!
But I think lightweight exceptions are more urgently needed. I don’t believe that dynamic exceptions will disappear, but C-style error handling will be finally obsolete, and division into incompatible dialects will stop.