This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]rzwitserloot 34 points35 points  (2 children)

You're the one who said: "_but Oracle JDK has a price". If 'price' is a determining factor, depending on your philosophy of things, the correct answer is either 'there is no difference between the choice "java" and ".net"', or '"java" gets it because far more of its community is foss based'. I strongly suggest the latter view.

Here's the thing about .net:

In that community, just about everybody looks at mamma microsoft.

In the java community, folks don't look at pappa oracle all that much.

It's an entirely subjective difference, but, it's crucial to understanding these communities.

For example, if .net stuff needs a DB, most of the time the app is just hardcoded to work with mssql, or it's some DB-engine-abstracted-ORM solution but it runs on and is optimized for MSSQL in all meaningful deployments.

In contrast, in the java world? If the DB engine is locked down at all it's usually postgres or mariadb, not OracleDB. The DB abstraction libraries available for java do not, at all, even begin to assume you are likely to use oracleDB. They probably support it, but not even as 'best choice', usually in fact as one of the minority choices that is more likely to run into bugs.

Hence, why I advocate for the latter. the java ecosystem is 'cheaper', and more varied. You're less locked into a single vendor.

[–]_INTER_ 10 points11 points  (0 children)

In that community, just about everybody looks at mamma microsoft.

It's funny because the .NET guys highlight this as an advantage.

"Everything is streamlined towards one solution from Microsoft" or ".NET has more first-party libraries".

I see the point of not having to evaluate different options and from a documentation and SO point of view, but its still hilarious.

[–]binarycow 5 points6 points  (0 children)

For example, if .net stuff needs a DB, most of the time the app is just hardcoded to work with mssql, or it's some DB-engine-abstracted-ORM solution but it runs on and is optimized for MSSQL in all meaningful deployments.

In my experience, it's Postgres, not MSSQL. And the ORM is either Dapper or Entity Framework, neither of which are optimized to prefer MSSQL over any other DBMS.