I'm a die-hard C++ guy but years ago I wrote a few 10k's of C# and found it quite productive. Here's what I liked about it:

* Garbage collection

* Lightning fast compilation

* Pointer-safe subset good enough for most common uses.

LINQ is also considered a huge win by many, though I suspect it could also be done in C++.

Now if they just used the same compiler backend across their C++ and C# toolchains.

Well there is the managed C++ backend, if you're into that sort of thing. I've been known to use it once or twice. :-)

I did use it a few times, back when .NET was still beta. So I went through Managed C++ and C++/CLI transition.

I also find it nice that with C++/CX VC++ is offering what C++ Builder does for years in terms of C++ RAD development.

Nowadays most of the consulting projects I work on are in JVM and .NET land.

What I really wanted to say it that I would like to see NGEN and .NET JIT offer the same type of optimizations as VC++ does, like SIMD, auto-vectorization and such.

When targeting Windows Phone 8, .NET gets compiled to native code with such type of optimizations using a cloud based AOT compiler. Maybe those improvements will eventually be brought into the standard framework.

In C# you need to go pretty far out of your way to implement an exploitable codepath. (It's not _hard_, and I even found one due to the JIT.) But for almost all apps, the better security (and tooling), better turnaround, and, without opening an escape catch, verifiable type safety - that's pretty fantastic.

Can you please elaborate on the exploitable codepath you found that was due to the JIT? That sounds interesting!

This was in a early version of .NET, over a decade ago. Basically, certain calls in the CLR are marked in a special way so they can be done by internal CLR code instead of running managed code like any other function. I think Array.Copy is one example.

If you created a delegate (function pointer) to such a special function that hadn't been called yet, it'd point to the wrong place and let you do things that shouldn't be possible.

The neat thing is that the code was valid and verifiable (so it'd run in low-trust), but you'd still end up owning a function call to the wrong point of memory due to a runtime bug.

Like practically every CLR vuln, it's the loading platform that is affected, not the applications. I think it's only important when relying on the complicated sandboxing restrictions (CAS).

I'd like to publish a working example, but haven't had the time to figure out which old OS allows the specific old .NET version to replicate the behaviour. I only found it by accident and was more concerned about finding a workaround to not crash.

Did you report it and did it get fixed?

Yeah I had some friends and did an internal report. It's long fixed :)

Awesome, thank you.

I disagree with the "Microsoft platform" bit. The Mono/Xamarin guys have been coming up with a very nice competing/complementary platform. I've built personal and production projects running on Linux using Mono.

While I haven't used, the Xamarin iOS/Android development platforms look quite interesting. I suppose it has the stigma of a somewhat pricy per seat license but its likely worth it if you want to go with a shared codebase for iOS/Android/WP/Win8.

There's also MonoGame[1] which targets developers of MS's former XNA game dev kit.

[1]http://www.monogame.net/about