By this definition Monads are also a core part of C#, they're not used to do IO but the async/await, IEnumerable, null-safe operators ('?.') are all implementations of Monads (not by coincidence), and above all you have the Linq syntax that you can extend to all of them and any other Monads you care to define.

Yet I imagine most C# programmers have little to no formal understanding of Monads (although quite a few probably do at least know about the link).

Sorry, I'm only vaguely familiar with C#, but maybe you're right, if they get sugar in the form of LINQ syntax. But regarding async/await, (?.), etc., a language doesn't have special support for vector spaces just because it has many vector spaces in it - and every language has many vector spaces in it.

That's true, it's just that it's culturally inappropriate to use the full power of monads in C# outside specific scenarios like Linq.

Well that really depends on who's working on it. In my opinion Linq isn't so much the only appropriate way to use monads but rather the most convenient way to demonstrate their full power.

This is misleading. There's no place in the specification of Haskell that specifically defines monads as part of the language. They aren't a language feature. They are a pattern which happens to be expressible in Haskell, and which is supported by libraries:

"Haskell's built in support for monads is split among the standard prelude, which exports the most common monad functions, and the Monad module, which contains less-commonly used monad functions. The individual monad types are each in their own libraries and are the subject of Part II of this tutorial."

https://wiki.haskell.org/All_About_Monads#Monad_support_in_H...

The fact that monads are used to implement parts of the language doesn't make them a core part of it. Techniques used in implementation aren't the same as language features.

I don't think this is true, do notation (see https://www.haskell.org/onlinereport/haskell2010/haskellch3....) specifically depends on the Monad typeclass and exists as syntactic sugar for monadic operators:

> A do expression provides a more conventional syntax for monadic programming

The Haskell 2010 Report mentions monads all over the place, both in the language and library sections. A Monad instance is literally the only way to do IO in standard Haskell. Monads get special syntax in the form of do-notation and, in an extension, monad comprehensions. It's undeniably a core feature of the language.

A pedantic distinction without a practical difference. Everyone who learns Haskell learns about Monads.

Is do notation a language feature?

it's syntactic sugar