IronPython did just fine with reified generics.
Nowadays largely abandoned, and I think not everything survived the transition from .NET Framework into modern .NET.
I suppose DLR would be comparable to GraalVM/Truffle.
The difficulty of implementing a dynamically-typed language directly on the CLR and JVM are about the same. Though, it would probably be more efficient on the CLR with access to lower level operations for memory management.
I think an interesting project would be to implement a CIL interpreter on GraalVM.
GraalVM already handles LLVM bitcode, much cooler than plain MSIL.
And here there is another example where Java ecosystem ends up being better.
MSR had a compiler framework similar to GraalVM, called Phoenix, it was going to replace VS, LLVM style, instead it died and what is left are a couple of research papers.
Anonymous classes are still used (sometimes). It simply depends on the circumstance of the lambda.
For example, this will result in a new anonymous class being generated.
void foo(String s) {
stream.filter(i->s.equals(i));
}
What won't generate a new anonymous class is this sort of lambda
stream.filter(i->"foo".equals(i));
Never bothered to actually look into the generated bytecodes.
I was wrong, it looks like the case I gave is one which doesn't result in a new anonymous class being generated. Instead the lambda metafactory gets involved to avoid that allocation.
I apparently didn't see what I thought I saw. I thought that I had seen new `lambda.$1` classes being created in call stacks when debugging. Maybe I did, but the lambda was serializable (we have that in some unfortunate places in our code base).
There are still cases where new classes get generated, but that's pretty much just for serialization.
[1] https://cr.openjdk.org/~briangoetz/lambda/lambda-translation...
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...
Even though most of the communication around dynamic was about COM support and Excel.
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.