I like dynamic languages too, and often wish C# was looser in its typing (or at least less verbose in its typecasting). If it were practical to use Ruby/C to do my job, I probably would.

That being said, C# is a huge step above C++, at least with respect to application development. Garbage collection aside, it has first-class functions, well-implemented closures, an integrated query DSL, and decent (if a little awkward) reflection capabilities. It's not an exciting language, and I don't feel particularly cool saying I use it, but I think it gets a pretty bum rap.

I'm aware of the feature set, I just don't think it buys you that much over modern C++ (different story six years ago). If you're using boost correctly garbage collection isn't necessary, and higher order stuff is quite doable.

I have dealt with Java memory problems several times now and am convinced that garbage collection has no business near performance bottleneck code.

C++ makes programming slow in many ways. You have to specifiy (and and maintain) every function signature twice. Compile times are measured in minutes for any substantial code base, unless you spend considerable time decoupling layers of headers, which slows programming down even more. Finding bugs is much more difficult without a stack trace, etc.

I'm not saying C++ shouldn't be used because if it really adds to the quality of the result the additional effort may be worth it. It's a balance between the quality of the product and time to market.

There's one more issue that shouldn't actually play a role but does: I have rarely seen C++ code that isn't full of incredibly stupid errors like copying large collections three times in a single function call. Even smart professional programmers very often write C++ code that is complete crap and way slower than the most naive C# or Java implementation.

But as someone who writes very data intensive apps I have to say there's just no way around C/C++. C# and Java VMs have twice the memory consumption of C/C++. I don't know whether C code uses more memory than assembly, but I doubt that a factor of two will ever be negligible, particularly because it translates into a factor of 100 as soon as you run out of memory and have to hit the disk.

Unfortunately the combination of C/C++ and dynamic languages doesn't work for many of my own scenarios because of the GIL.

I mean look Rails (just as an example). A typical rails app runs in 16 processes, each consuming 150MB of RAM (after a while of running) just for the framework itself and a few controllers and views basically. Nothing but little helpers doing CRUD.

There's just no memory left to do anything interesting with data in-memory because all that data would have to be duplicated in each process. That's why dynamic languages driving a C++ core doesn't really fly for interactive apps. It works for batch processes like what google does.