My code is much better than an MVP. Instead what I have does essentially all I have in mind for the users now; other features I have in mind stand to be minor and only for the future. And the code I have now should be about as solid as code nearly any production code is. It's good code; nothing wrong with it. On the way to $1T the code should have some additional features for system monitoring and management, but such features would be useless now. And there should be some redesign efforts for scaling to 1000s of times more Web pages per second, that is, a lot of parallelism and graceful handling of parallel components currently not working (can't expect that all parts of a server farm with 1 million square feet of space and full of racks will all be working all the time). But such parallel considerations are for the future. Besides, Microsoft runs some really big server farms, so I'm sure that when I'm a customer for several thousand licenses for Windows Server and SQL Server, their system monitoring, automated deployment, etc., I'll be able to get some high end Microsoft consulting on how to use their products for such computing.

Yes, there have been language wars for decades. They never made much sense and still don't.

Here is a resolution for my work now: The first choice is between Microsoft and Linux. Clearly it's possible to be successful with either of them. Like a lot of large sites, I picked Microsoft.

On Microsoft the main language choices were between VB.NET (the newer one, not the old Visual Basic 6.0) and C#. Between those two, for production code, about the only difference is just syntactic sugar. I just happen to prefer the flavor of that sugar in VB.NET. Then, for writing production code, VB.NET is essentially as good as C# or anything else on Windows. For the current state of computing, there's NOTHING wrong with the choice of VB.NET for high end production software.

More generally, so far there's no big magic in programming language deign; essentially all the ideas are 20+ years old, sometimes 40+ years old, e.g., for capabilities and access control lists, security rings, software handling of interrupts, back to Multics and PL/I in the 1960s. Heck for HN, IIRC Lisp goes back to 1959 or so. Concurrency? Dijkstra semaphores are not much used. What does get used is still simple. Sure, buried in SQL Server might be some really nice and tricky concurrency work, but only programmers specializing in SQL internals see that stuff. For algorithms and data structures, still AVL trees or red-black remain about the most advanced used. For just k-D trees, they are obscure enough that they get used only in rare special situations. For concurrency versions of some of the common algorithms, those, too, are rarely used and for narrow special situations. Sure, there's a version of the heap data structure that gives better locality of reference when using virtual memory, but, again, that need is rare.

The good news is how powerful the usual stuff, e.g., just VB.NET, actually is. We shouldn't neglect the good stuff right in front of us when, as usual, it is plenty powerful enough for the work to be done.

The main control structures remain if-then-else, do-while, and call-return. Co-routines? Not much used. Even scope of names as in PL/I has been cut back to the simplistic approach of just C. The super nice structure addressing in PL/I (we're talking 1960s here) has been replaced with the too heavy use of pointers (by the compiler) required by objects. The PL/I structures were nearly as useful as objects and much faster in the addressing. Net, in programming language design for production code, there's isn't a lot that's new and really important. So, really, in practice, just VB.NET is about as good as it gets.