[WorldMaker]

The DLR is just a shared library. It never changed anything about the CLR under the hood nor did it change anything about how Generics worked in the CLR (being the most relevant part of the thread here). IronPython could instantiate Generics just fine, and did just fine working with them.

The DLR is not "abandoned" so much as "complete". Everything did survive the transition into modern .NET and IronPython 3.4.2 runs just fine on .NET 6+ [1]. (For those trapped on the ugly side of the Python 2/3 split, even IronPython 2.7.12 runs on .NET 6.) Most of the "magic" of the DLR is shared with C# Linq in interesting ways (the System.Linq.Expressions AST) and sort of "has to survive" if only to properly support IQueryable<T> (and wilder relatives like IQbservable<T>, the Q is not a typo) even if most people aren't actively using DLR languages today (nor that much usage of C#'s `dynamic` keyword).

IronPython is a community supported (truly open source) language so doesn't get as much attention now as it did in the brief "first party" support era, so some may call that "abandoned" but F# has always lived in that gray space where it is primarily "community supported" more than "officially supported" by a dedicated team at Microsoft.

[1] https://github.com/IronLanguages/ironpython3/releases/tag/v3...

[pjmlp]

The addition of dynamic, and JIT being aware of IDynamicMetaObjectProvider also mattered.

Even though most of the communication around dynamic was about COM support and Excel.

[WorldMaker]

IDynamicMetaObjectProvider mostly just caches and returns System.Linq.Expressions for various asks, so again most of the JIT awareness is still just System.Linq.Expressions awareness.

The COM support is by implementing IDynamicMetaObjectProvider in a cross-language reusable base class.

The C# `dynamic` keyword adds some smarts about IDynamicMetaObjectProvider to the C# compiler, but those smarts were never seen to be needed as a low level tool in the CLR itself. And again, once the C# compiles the IDynamicMetaObjectProvider calls, those mostly just result in System.Linq.Expressions for the JIT compiler to optimize in the same way it optimizes other usages of Linq.