&gt; I think this point has probably been argued to death by now, but I still can&#x27;t see this as a good idea. &#x27;Side effects&#x27; are really just a reality of software development. For example if I want to fade in a GUI element on a page, I don&#x27;t want to create a new element for every transition change. Theres nothing wrong with mutable state, but it is nice to have immutability for some use cases. In this case c# has valuetypes, and the const&#x2F;readonly modifiers.<p>Mutability is one side effect. OCaml is not Haskell and doesn&#x27;t have a type system baked in. Sure, sometimes you need to cheat, but mutability as the general rule is crazyland. Immutability gives you a compile-time assurance that your data structures are consistent and valid, as long as the tests in your constructor function are correct.<p>&gt; Yep C# has had this since the beginning. And you can even use &#x27;dynamic&#x27; if you really want which moves all type checking to runtime.<p>Well, it has strong static type checking... within the bounds of what its type system supports. Which is fairly limited.<p>&gt; I feel like these are more buzz words than actual substance.<p>Others have responded to that, but in short, your impression is wrong.<p>&gt; Again C# has these abilities with &#x27;var a = 0&#x27; for example. It won&#x27;t infer method return types, not because it couldn&#x27;t, but because it&#x27;s just generally clearer to have the explicit return type written there in the code for the reader.<p>C#&#x27;s &quot;type inference&quot; is cute, but you can&#x27;t seriously compare it with OCaml&#x27;s.