The first 2 points shows such fundamental misunderstanding of garbage collection that it's hard to take this article seriously.<p><i></i>Every<i></i> garbage-collected language has this "problem". The "problem" (objects are reclaimed an unspecified time after they have been determined as unreachable by GC) is a fundamental property of garbage collection (at least the most frequently used, non-ref-counted GC).<p>It's also well accepted that when it comes to releasing resources other than memory, programmers should be doing it more explicitly and not rely on GC and that's why C# has using statement and IDispose interface. It's no worse than in non-GC languages where you have to do such manual management for everything and it applies to all GCed languages, not just C#.<p>He's complaining about C# crashing on broken code (where program used an unsafe operation to get at raw memory of the object without telling GC that the object cannot be reclaimed). C#, of course, is to blame, not the programmer who wrote broken code.<p>The rest is just a bunch of "I know better" opinions.<p>C# was actually designed but some of the best, thoughtful language designers (like Anders Hejlsberg <a href="http://en.wikipedia.org/wiki/Anders_Hejlsberg" rel="nofollow">http://en.wikipedia.org/wiki/Anders_Hejlsberg</a>).<p>I'm sure if they had a chance, they would fix a thing or two but it's exceedingly easy to spend a few minutes thinking about an issue, decide it's broken and broadcast one's beliefs in a blog post.<p>The hard part is thinking about trade offs in alternative designs, unintended consequences etc. I'm pretty sure C# designers had good reasons for most of the things a guy who blames language for crashing on broken code criticizes.