We are using Windows, the .NET Framework, IIS,
ASP.NET, and Visual Basic .NET. We're on
the .NET Framework 4.0 and see no reason to
move to 4.5.

For C#, not interested: The syntax borrows from the
deliberately idiosyncratic syntax of C, and
the Visual Basic syntax is more verbose,
easier to learn, teach, and read, and, thus,
less error prone, is as a programming language
in its semantics, features, and functionality
essentially equivalent to C#, that is,
the difference is mostly just syntactic sugar,
and apparently is about as
good as C# or anything else at getting at
the CLR and the .NET Framework.

For F#,
people back to Backus have been working on
functional programming, and, for
more than just curiosity, and certainly
for the work of our start-up, we're not
impressed or interested, in that or
logic programming, rule-based programming,
or standing on our heads in the corner
programming, etc. -- sorry 'bout that;
we can agree to disagree, and YMMV.

We're quite pleased with Visual Basic
.NET. A hat tip to the Microsoft
Visual Basic group.

Main gripe: For
the documentation, actually for all the
documentation on MSDN, especially for
SQL Server, please, please,
please, get a least a C in
technical writing 101. Our biggest problem
in our start-up, far and away, much, much,
much more difficult than everything else
combined, literally, is the low quality of
the technical writing at MSDN.

For JavaScript, Microsoft's ASP.NET writes
some for us, but so far we have yet to write
a single line of it and will delay doing
so as long as we can, hopefully forever.

For ASP.NET, we are using just the basics,
that is, with

Sub Page_Init
Sub Page_Load
Sub Page_PreRender
Sub Page_Unload

etc. We have heard of MVC, looked at it
a little, can see no reason for it
or advantage in it, and
intend to have nothing to do with it.
Maybe better technical writing at MSDN
would let us take MVC more seriously.

We type into our favorite text editor and
make no use of an IDE nor do we want to.

For developing code for Web pages,
ASP.NET and Visual Basic work nicely together
-- it works fine. Actually, it's nice.

For a session state store, we wrote our
own using just instances of one class,
de/serialization, TCP/IP raw sockets,
and two collection classes. On an 8
core processor at 4.0 GHz, our session
state store should be good for 11,000+
transactions a second; transactions
is appropriate because the code is
single threaded. Yes, on an 8 core
processor we would run several
instances with sharding.

As we go live, our server will be just
a single full tower case with an 8
core processor, 32 GB of main memory,
some SSDs for a special purpose
particular to our start-up,
and some disks, with Windows
Server, SQL Server, IIS, ASP.NET, our
Web pages, our session state store,
and some specialized back-end servers.
The software and architecture are
scalable via just simple sharding.
We have little or no intention of using
the cloud soon or ever.

As we go live and grow,
after the issue of the MSDN documentation,
no doubt, and closely related to the
documentation issue, our biggest concern
will be Windows Server, SQL Server, and IIS
installation, configuration, updates,
security, monitoring, management,
performance, administration, reliability,
backup, and recovery -- little things like
those. But from some of the just astounding
successes Microsoft has running server
farms with their software, clearly
terrific results are possible; maybe we
will be calling for some high end technical
support.

That's what we are doing!