1/ An interesting bit of history for .NET and C# is that there used to be a public System.Variant type. It was actually a keyword in C# for a while, alongside of object. If you’re unfamiliar with variants, they are a tagged union type.
2/ This means that they can represent many different data types and contain a ‘tag’ (a small enumeration) that defines the type of data they hold. This evolved because COM uses variants heavily, as did VB6 (and many other languages).
3/ In the original iterations of VB.NET, Variant was used for any untyped declaration (e.g. Dim a, b). Variants and System.Object are similar in some ways, and as you might guess, this led to problems.
4/ Variants were implemented as value-types in .NET. This meant that given a variant there were two ways to ‘get’ an object. You could box the variant itself, or you could get the object representation of the *contents* of the variant.
5/ The second is far and away the more common operation, though once you start storing variants into lists (like ArrayList), it starts to get confusing. An example where this kind of confusion came up in C# is this scenario: 
6/ Is that a delegate onto variant’s GetHashCode or MyClass instance’s GetHashCode? We did define rules for these cases, but it added complexity that felt onerous. The concept of ‘null’ is also somewhat confusing with variants.
7/ Variants can represent ‘missing’, ‘null’, ‘empty’, (and in VB6 also Nothing). This is somewhat like the confusion that undefined and null creates in JavaScript, but worse. Outside of the confusion for the language, the complexity in the framework was arguably worse.
8/ There were many overloads in the framework that ended up taking both object and variant. It also made cross language compatibility between C#, VB.NET, and other languages much more difficult. For C#, we removed variant as a keyword and simple-type.
9/ More globally, we decided to centralize on object to better unify the type system, improve cross language compatibility, and reduce complexity. This had big implications for VB6 compatibility and COM interoperability that I’ll save for another thread.
10/ This particular decision was difficult and contentious. As mentioned, it had implications for existing language compat and interop, two value propositions for .NET. In hindsight, I believe it was the right call – but .NET would look entirely different if we had either chosen
11/ to unify on variant and/or keep both.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
