I agree "get all the free Microsoft goodies when you start, and once you really need the paid versions you're probably successful enough that the cost doesn't matter much" is one fair conclusion to the article. However I don't believe that's the only conclusion. Mostly I want .NET to be a consideration as an option when building out the technology in a startup.
I'm concerned about vender lock-in as well, just less concerned then I used to be. Microsoft's gone to great lengths to reduce some of my concerns. The fact that you are using C# with Postgres demonstrates that there doesn't need to be complete lock-in.
Do you mind sharing more about what your C#/Postgres app looks like? This combination is one option I'll be looking at for my next venture.
We've recently started down this C#/Postgres route. One of the main decisions to use C# was static typing, so I wanted to keep this with the data access layer as well. I've decided to use dotConnect for PostgreSQL so I can use EF. I figure I can use dapper or another micro ORM after I get into performance issues.
Our biggest problem with Postgres is actually the lack of a good GUI. I'm using 0xDBE for the amazing auto complete and PgAdmin for everything else.
OK, here goes. I'm not saying that we made the right choice all over, but this is what we currently have:
For the API we use ServiceStack (v3, because v4 is paid and has a ridiculously high license fee). It is the best-designed REST API library I've ever seen, in any language. Its focus on data and not on verbs makes it easy to build well-designed APIs and difficult to build crappy ones.
The API is the executable, self-hosting an HTTP server (using ServiceStack's support for the .NET HttpListener). We'll probably switch to FastCGI soon. In any case, we have an Nginx in front to serve all static assets, which proxies API calls through to our API.
The database layer is very lean: we rely heavily on Postgres stored procedures for much of our data logic. This way, we avoid a lot of roundtrips to the DB and back. We go as far as using Postgres's multiple cursor feature to return hierarchical data without repeating lots of data in a giant single JOIN. We then use C# to tie the pieces back together (e.g. imagine a blog example, if we'd have a query for certain posts AND their top 5 comments, we'd get one cursor for posts and one for all comments, in order, and then we tie each post to a set of comments in C#-o-world while mapping it to DTOs).
The queried data goes from what the stored procedures return straight into the DTOs that ServiceStack returns, so we have no "domain model" class structure or a heavy weight ORM. We use Dapper for easily mapping stuff to simple classes.
We insert/update data with ServiceStack.OrmLite - just simply adding rows. Often, an API DTO matches a DB table close enough that this just works without any extra mapping.
I general, we're convinced that heavy-weight ORMs don't make sense for backends which are little more than data-stores for single-page web apps.
We manage DB schema changes (and all stored procedures) using hand-written SQL scripts, much like how the Play framework does this (1.sql for the initial DB, 2.sql for changes since v1, etc). This works amazingly great, and gives us far greater control than any ORM ever gave me.
We host it all with Docker containers: one for the DB data (Docker's "data-only container" pattern), one for Postgres itself, one for the backend (running Mono 3.2.something on ubuntu 14.04), one for Nginx, and one for our static assets (so we can redeploy frontend code without restarting the nginx container). Currently, we're host it all at http://orchardup.com but we're not too happy with their very slow (but friendly) customer support. Docker has given us a bunch of headaches (for example, that data only container pattern is a lot less easy to set up in practice), but none .NET/Mono related.
Our frontend is a single-page web app, optimized for mobile, built with React and TypeScript.
I've used Mercurial over Dropbox before and would caution against it. Somehow the repository got corrupted (I'm betting on a bad Dropbox sync) and then all the repositories got corrupted. Since then moved to bitbucket.
I support using JavaScript as a first language. If for nothing else there are millions of code snippets just a short "right click -> view source" away. Granted these may not be the most ideal examples, but it enables tinkering. One thing that always frustrated me about the "easy" languages to learn (Python, Ruby, etc) is you still have to figure out how to download something and then the first programs just write out text to a console window. It's hard to see at first how learning one of the "easy" languages translates into building cool stuff.
Having access to such a vast array of samples, plus something like Khan Acadamy teaching the "right way" is just awesome to me.
