Hacker News Reader

Comment by hkarthik | Hacker News Reader

I agree, he could easily be using a JVM-based stack to get the same or better efficiency out of his 1-server configuration.

Also there's some clearly naivety when bragging about his "low cost" $200/month setup. His SQL Server licenses alone will probably triple or quadruple his costs when his Bizspark status runs out.

View on HN

>"I agree, he could easily be using a JVM-based stack"

Maybe but believe it or not, there are people who HATE Java (that would includes me)

I'm not a huge fan of Java either, but sometimes it's important to get past that and either try and work with a language that's extremely effective for some deployments, or consider that the JVM supports quite a bit more platforms than just Java.

There's always Scala, clojure, groovy, etc.

Oh you're not alone. I dislike Java as well, but there's no denying the power of the JVM and the ecosystem around it. If you really dig into it and look at it as a polyglot platform with choices like Groovy, Clojure, JRuby, and Scala, it becomes more palatable.

Regardless this post is not about .NET tooling, more about server efficiency and cost. Two areas where I think the JVM is a little further ahead.

Well, AFAIK he can easily switch to MySQL for instance, under the same ORM.

MySQL is possibly the single hardest database to port to/from, because it supports nothing.

In that case porting FROM it should be simple. TO it would be hard if you're using all those fancy features of your current DB. That's why I eschew all the sirens from Oracle DBA's of "oh... but Oracle can do that too!" Keep database activities in the database and application activities in the app.

In my experience, MySQL lets you get into a state where questions like "hang, on - what's the difference between a DATE of '0000-00-00' and NULL?" are commonplace. This makes porting from it... not simple.

Although I have no experience with MySQL, this kind of problems have to be resolved by using LINQ to SQL since every db type is automatically mapped to its .NET counterpart. The DateTime .NET type then has only one representation of null.

Or what you're saying is that if you store a date of zero VALUE to MySQL it could be magically replaced by NULL internally? That would be really crazy.

I seem to recall it is actually the other way around, and storing a null results in a nonsense date.

Added bonus: some versions will segfault if you pass an un-formattable date value.

The problem is that MySQL deviates from the standards (all of them) in surprising and uncomfortable ways. porting from MySQL is fun, when, for example, your target database actually ENFORCES the constraints that MySQL accepted but silently ignored. MySQL doesn't have that feature, but it won't bother to tell you.

Postgres, Oracle, MS SQL all support a (very large) common subset of features, so if you avoid stored procedures and db-specific features, you can port among them easily. This is not true for MySQL.

Reply on news.ycombinator.com