.NET caters to the enterprise, or at least it used to. It's irrelevant what other ecosystems prioritise. What makes you say that XML is legacy tech? In the financial industry XML is used extensively. For example, FpML underpins a massive part of global finance, and it is a regularly updated standard. COBOL has been superceded by other languages; I'm not aware of any technology that can replace the XML-based FpML schema.

"Legacy" is perhaps not the best word to describe it; what I mean is that new technologies, protocols etc being developed generally avoid XML. So new products and libraries don't have to deal with it that much. And older ones are already written relying on older versions of XPath etc, so there isn't a strong incentive to upgrade there. Even if we're talking about libraries that are still getting updated to reflect changes in the standards.

The comparison with COBOL is fairly straightforward. There's still plenty of COBOL code running in prod around the world - but you don't see much clamoring to add new features to it.

Oh, and .NET doesn't really cater specifically to the enterprise these days. It was definitely true back when it was first released (remember all the emphasis on SOAP?), and for a while after. But .NET Core was an attempt to broaden its scope, and it very much succeeded.

I should add that I'm not particularly happy about this. I did a lot of XSLT 2.0 and XQuery 2.0 back in mid-00s, using Saxon, and I still miss many aspects of it. The new "best thing" seems to be JSON, but, while the syntax is certainly nicer, the tooling ecosystem around it is still nowhere near what we had back then.

> .NET caters to the enterprise, or at least it used to.

.NET is for enterprises who don't treat tech as frozen in time the instant it gets adopted now.