Moreover due to the fact that .NET is coupled with Windows, it seems to be less of a problem to be stuck with a very outdated version of the framework. In Java I often had to write for version 4, whereas 6 was already released.

Agreed, apart from nullable types which I think is a misfeature (having dealt with the inevitable null reference/null value tristate hell left by some developers).

.NET won't allow you to create a Nullable<T> where T is itself a nullable type. (And Nullable<T> is not itself nullable.) I'm not sure about all languages, but in C# code like that won't even compile.

I agree, allowing a nullable wrapper around a (already inherently nullable) reference type would be a horrible misfeature. What language was that?

I just wish that rather than adding nullable primitives they added non-nullable objects. The type system used by googles javascript compiler has support for those and working with it is fantastic.

That would be fantastic - great idea!

No More:

   Check.IsNotNull(objRef, "stop being a muppet");

I thought .NET types were optionally nullable? I don't think they are by default.

Basic types are optionally nullable. int? is nullable, int is not.

It is a fantastic tool in many cases where a null is much clearer than something like -1 to denote a missing value.

However, I can see the issue with some developers using nullable types for everything. But any sufficiently powerful/flexible tool is always going to be misused by some.

I had the misfortune in the past to maintain C# code that kept everything as strings; whether it was an integer, a floating-point number, a guid, a date or a boolean. Lousy developers can abuse anything, in itself in my opinion this is not a reason to not have it included.

(I have a the same opinion about goto and operator overloading; clearly the folks at Microsoft agree with me here.)

They are optionally nullable. Unfortunately, people seem to think that making use of them everywhere is cool :(

Scala might be an option for you. It is not as "stable" as Java, but more like C# and it actually has a real "deprecation cycle", e. g. stuff gets removed after two versions, both in the language and the library. Pace of development is actually really impressive. If you are interested, I wrote down some nodes about the keynote at ScalaDays here: http://hackerne.ws/item?id=3912885

I think that the "deprecation cycle" is ultimately hurtful for Scala. Breaking changes in a programming language are immensely difficult and expensive for enterprises to deal with, and breaking changes in core libraries are no picnic either. I'd be extremely hesitant to advise my employer to adopt a language whose maintainers have a cavalier attitude about such things, because it does really bad things to our ability to predict costs.

It is certainly not worse than anywhere else (see for example what happened with Windows RT/Metro ... that was certainly magnitudes worse and Microsoft still decided to do it (or the breaking changes in C# 5)).

The only exception is Java, where everything is basically frozen after release and cannot ever be changed anymore.

Most of the time, targeting a newer version in Scala is just a recompilation away, like on .NET. So if you are good with .NET, you should be good with Scala, too.