I still don't see any C# developers that are 200% more productive than Java developers due to limited infrastructure around the C# ecosystems.

Say anything about Maven but the recent discussion about embedding Bundler to Gem is just one step closer to be like Maven (now if they merged Rake+Gem+Bundler then Maven is). Even if Maven is not "good enough", .NET is thousand miles behind Java when it comes to dependency management and build system.

Google-Guava, as ugly as the syntax is, is good enough for most of us. Java 8 is around the corner so meh.

>monadic collection operations like map, select, etc

There is nothing 'monadic' about select. SelectMany yes, but not Select. That's equivalent to map in other languages.

Any language today that still requires to mark end of line with a semi colon, has in my opinion outdated syntax. Most people put one statement per line, so why is it required and not optional?

And some languages don't check types for you before running the code and it's almost 2014 now, can you imagine?

"Runtime generics" (they are called reified generics btw) is one of the things that keeps the CLR from being a multi-language VM like it was advertised, as at the bytecode level they are very hard to work around. That's one of the reasons for why dynamic languages on the CLR never took off and that's why F# has two generics systems in the same language. I'm much happier with the generics type system provided by Scala - it's more flexible, allows for more type safety (so there are far, far less instances in which one needs to do isInstanceOf checks), you also get reification by receiving TypeTags and Scala can also specialize the implementation for primitives if you want it. You get most of the benefits and more, without butchering the runtime. The easiness with which you can generate bytecode on the JVM has been one of the reason for why the JVM has been preferred by language designers.

Reactive Extensions are very nice. I'm experimenting with the Java port, RxJava. Actually I use RxScala, the Scala interface. However, for me they are of limited utility for my current usecase, because in comparison with Iteratees (a concept coming from Haskell, borrowed by Scala and championed in Play2), Rx Observables are very error prone to issues such as backpressure, whereas Iteratees are safe by design. So on one hand, Iteratees are better for handling streams, such as http requests/responses, handling big files and so on, while Rx Observables are better for publishing events to event listeners. I can see myself using Observables though. Erik Meijer is now contributing to RxJava btw.

The C# continuations are delimited continuations, or partial continuations. They are pretty cool, not arguing about it. But in Scala, the API for the standard Future, is much, much nicer than the API of Tasks in C#, therefore working with Futures directly is more comfortable. Plus, Scala's philosophy is to empower the developer to build on the same "magic" that the compiler uses, therefore instead of introducing LINQ or Async, Scala 2.10 introduced Macros. As a result, LINQ and Async are now possible as libraries. Here's DB LINQ (see the direct embedding tab): http://slick.typesafe.com/ ; and here's Async, which will be included in the standard library, but it's just a library based on macros: https://github.com/scala/async

On Value Types, there's nothing ground-breaking about it. On one hand they are great and it would have been cool to have value types on the JVM. There are proposals to include value types that people experiment with in OpenJDK. On the other hand, the JVM being more restrictive about managing memory, gave birth to the most advanced garbage collectors in mainstream usage. C#/CLR is great when a low overhead is required, such as on mobile devices, but in a server-side context no GC-enabled language can beat the JVM.

On syntax, it's true that Java is an abomination. However this gave birth to multiple languages that are flourishing and you can't say the same thing about .NET ... Scala, Clojure, JRuby, Jython, Groovy and Rhino are examples with flourishing communities and ecosystems. Similar efforts have been happening for the CLR, but they never made it or are moribund, except maybe F#.

I did want to use C# several times, as I view it as a mixed-bag language, as in a language with comfortable high-level features that also has some low-level stuff, which is pretty cool on top of resource constrained devices. And I definitely prefer C# over Java (thank God for Scala and Clojure). Unfortunately the platforms I build upon are mostly Unix and I prefer to build on top of open-source as I'm the kind of developer that likes being in control. And in spite of the best efforts of those people from Xamarin, or the recent moves from Microsoft to open-source some stuff, .NET doesn't really have an open-source community and it's very Windows/Microsoft oriented.

It's a pity because it could have been much more than it currently is. And maybe it will, as I'm seeing some encouraging signs, like Microsoft partnering with Xamarin.

We tend to treat languages like they are football teams. We really need to learn from each other and build on top of each other ideas. Cross-pollination is healthy. Conservatism is not. If we jumped between platforms more often, we wouldn't be separate communities.

In the past, I had the misfortune to work with MSBuild to setup a fairly large .Net project. This was before NuGet exist. NuGet helped a bit these days but integrating FxCop, FxStyle, auto run NUnit, generate the docs, and running code coverage as part of the build is very painful and a manual process from downloading the proper assemblies up to setting up paths and results. Not to mention packaging the whole things up and possibly deploying to local IIS all through the build script.

Preparing dev workspace means to include csproj in your repo which may contain hardcoded paths. Is that portable across to Mono? In Java, all you need is a Maven pom.xml file and the code. Any modern IDE can read pom.xml file and prepare the project consistently cross platforms.

CI server is the easy part.