In F# these are "guaranteed" to be non-null, even though null instances come up during deserialization all the time. In C# use cases, I don't think the non-null "guarantee" should be made or implied, just a POCO.

You have to override Equals() and GetHashCode() for starters. Then you also need to make sure you only have getters and no setters (or private setters). In some cases you need to make your empty constructor private and force a specific constructor to be used. If you have multiple constructors it means you will have different invariants which puts you in class land, you are better off with classes then anyway. Also if your immutable objects have many methods..that also puts you in class land.

Just that alone makes it cumbersome.

So a new record type that behaves somewhat like a struct would be perfect. Or the F# way, which is basically perfection.

It's now as simple as

record SomeData(string Name, int Id);

Which gives you an immutable object, auto generated constructor, and some additional helpers to make life easier.

The `using` static is actually really good news. I have seen people who seem to be really mad about it, but sometimes it would be nice to have, for example:

    // Something like Scala's 'Predef'
    public static class Id<T>
    {
	public static Func<T, T> Identity { get {  return x => x; } }
    }

   using Id;

   var grouped = list.GroupBy(Identity);

Equivalent of F#'s record types would be also awesome, which is what you put as 'readonly class':

    type Person = { FirstName : string; LastName : string }
    let single = { FirstName = "Jane"; LastName = "Doe" }
    let married = { single with LastName = "Smith" }

His item 4 is to some extent a result of the limited immutable support (he mentions "a lightweight way of building immutable list/collection expression"). Fix that support and 1,4 out of his list are not much of a problem anymore or at least ameliorated.

2) I would be glad to never need hear of IComparer or IEqualityComparer again, which I only need due to the stdlib leftovers... Admittedly not much, but enough to be annoying. His solution is more general, but your idea is very nice. Why didn't I think of that?

5) Dynamic is there for the Dynamic Language Runtime and for dynamic code far more general than your example. It should be kept in that silo, but it does do its job there.

IMHO, the author tries to write C# with the current trend of functional+immutable, and that's why he ended up hitting these issues. It's true that the OOP way isn't bad (at least with those examples), but it's also true C# could offer better support for doing things the other way without much effort.

public string Example { get; }

You can set it in the constructor and only the constructor.

On the other hand in C# it's still relatively hard/annoying to build Structural Equality into your classes (which anonymous types and tuples both handle for you) where the equality of two objects is based on the contents of their properties rather than the equivalence of their references. (Ease of Structural Equality is the number one reason for my typical reliance on Tuple as I tend to use tuples often as Dictionary<K, V>/ILookup<K, V> keys.)

And while you're at it dear C# team, add .Distinct<TSource, TDest>(Func<TSource, TDest>, IEqualityComparer<TDest>) similar to OrderBy and friends, and various constructors to the generic collection types taking Func<T, T, int> instead of IComparer<T>. Yeah, API bloat, but good one in this case IMHO.

C# and the .NET runtime and the compiler(s) are still evolving indeed, and I would guess a lot of issues will be addressed and fixed in the future.

PS: the most annoying bit to me about the immutable collection library is that they are dead slow whenever I tried them.

I am sure there could be a good way to automate this using type providers, but I haven't tried it yet.

You can have those semantics in .net, because any hashable can be a dictionary key. It will have a small performance penalty, which won't matter in 99% of cases. You could roll your own collection and get O(1).

F# lets enum values be records, which is the most elegant solution IMO for manageable counts and fields.

var filteredCollection = collection.Where(x => predicate(x));