Performance-Wise, C# Trumps Java
datacenteracceleration.com
datacenteracceleration.com
Working on C# OSS means stealing licenses from your employer, buying an MSDN subscription on your own dime, or evangelizing enough to get an MVP award so you get all the tooling for free. The free Express editions of the tools have built in limitations that don't make them viable for building Big Data projects. Other options exist, but pale in comparison to Visual Studio so they don't get much use.
As for mono, the uptick for the OSS stuff just isn't there and even Xamarin is leaning on commercial offerings to become a viable business. Maybe as they get more successful they can sponsor some C# server projects, but that may be a ways off.
This is all unfortunate, as C# really is a great language.
In addition, I've moved to vim as a text editor and tried to avoid IDEs where possible.
The biggest thing to do is break your addiction to Visual Studio and the luxury tooling. That's harder for some programmers to do, but it opens a lot of doors with other stacks.
* Multi-unit testing framework and refactoring support
* Third-party extensibility support
The biggest roadblocks to .NET development/adoption are not toolchain related IMO, they are platform related. If you want to bring up a farm of windows boxes, you're gonna pay.
* Testing can be done through other tools such as Nunit.
* With VS2012, you get extensions developed by Microsoft, such as NuGet.
With that said, most .NET developers probably prefer their .NET OSS projects to have visual studio files so its easier to link into their projects.
Tech people who have to handle that kind of data and that kind of volume generally don't want to pay a Microsoft tax. In theory there are a lot of other alternatives. However all of the popular ones are Unix based and either are native to, or ported to, Linux.
There are exceptions. For example eBay decided for political reasons to go the Windows/Java route some years ago. (And reportedly paid a factor of 2 cost differential for it.) But Google, Facebook, Amazon, etc see no reason to be dependent upon Microsoft, or to pay that level of tax to a potential competitor.
Furthermore, I doubt straight-line execution performance is really the biggest concern when choosing a language to use for a task like this. You probably want to prioritize being able to find people who know the language - or, if you're using existing staff, you pick something they either know or can learn easily. C#'s not hard to learn but the odds are better that your typical CS graduate knows Java. In particular, if you want high performance, high performance C# isn't particularly easy to write - you'll have to know the language well, just like in any other environment.
The CLR doesn't have a well-tuned JIT compiler and a fast garbage collector? Give .NET 4.5 a try -- it included some improvements to the garbage collector that were quite well-received (and the JIT was already quite good from .NET 4).
Last I checked the JVM is more aggressive about inlining, can do escape analysis on reference types, and has a more scalable parallel collector. There are also alternative JVMs that go even further - Azul has a theoretically pauseless collector, which is certainly not something .NET offers (though pause times are pretty short for gen 1/2 collections, at least!)
The lack of aggressive inlining in many scenarios is arguably a big issue for .NET due to the more pervasive use of IEnumerable and properties, both of which add the overhead of additional method calls. In particular, when those additional method calls don't get inlined and you're passing structs around, each one involves a full copy of your struct, because the people designing the standard library didn't use 'ref' anywhere.
Which is okay because Linq queries are easily refactored into proper classes and methods.
Make it fast then make it fast.
I've been doing my part to work on #2. I've sent in some improvements to VI mode (https://github.com/mono/monodevelop/pull/247) because I think it's critical to convince myself to work in MD. It also needs a lot of work on the debugger end. If we can successfully get people to work on Linux, C# might actually become prevalent.
Not having structured value types was the most consequential mistake in programming language design since 1970-01-01 00:00:00. It's probably the most important reason why Java never took off on the desktop and why C++ is still widely used.
Can you even set up a bunch of windows server nodes without running into a licensing headache?
Also a lot of big data farms have some hardcore kernel optimisations which are not as easily done on Windows (if at all).
Also Java runs pretty much everywhere and is supported. C#/.NET is not (and Mono is not a decent response, if it isn't first party supported it isn't supported).
I've had good experiences with Mono and MonoDevelop, and given that Xamarin provides commercial support for Mono, I don't think it makes sense to automatically discard that option.
Its not for C#.
Also to say that its not first party support is a little disingenuous as ultimately one would never say pick a messaging queue that implemented AMQP because it wasn't first party. C# is an ECMA standard. AFAIK the mono compiler has no issues implementing it as well as the Microsoft msbuild/csc.
For me as to why I wouldn't, its simple. Mono isn't as fast as the JRE on linux for most operations, at least I've not heard it is, and its so far removed from my interests and work to test it. http://reverseblade.blogspot.co.uk/2009/02/c-versus-c-versus... I know the mono team have done a lot over work over the last 4 years, but still. I think that is the crushing blow.
Whilst F# support, or TPL or LINQ might make development nicer, I don't think the performance concerns can be adressed.
However, C# has one big thing going for it, unlike java its never tried to install the chuffing "Ask toolbar". Oracle are going to the special hell.
I 100% agree with you on JRE performance.
The Ask Toolbar thing is a pain in the ass. Although it was Sun who started it so blaming Oracle is a bit unfair. It does not excuse Oracle not removing it ASAP though. They don't include it as part of the offline installer, only the stub installer so it can be avoided at least.
Windows Enterprise is not needed for compute clusters; AFAIK Microsoft doesn't actively sell any OS products at all for building a compute cluster (only for failover), rather expecting you to do something at the application level.
Anyhow, I'm not arguing that Windows is a fit for folks who need to spin up more instances on demand without a nearly linear increase in OS license costs, but Windows Enterprise and VS Ultimate are pretty unrelated to the concerns of heavy computing.
If you want to check it out: http://tryfsharp.org
TL;DR Don't look at data, look at the principles. Ignore reality, think about how the world should be. I think as an industry we can't aim lower than this quote:
"In fact, C# is a better fit than Java for high-performance requirements. I'm not referring to VM stats that change every year. C# has been designed from the ground up with efficiency in mind."
And a side note:
"Both C# and Java have generational mark and sweep collectors."
No Java hasn't.
It seems most of the things are done in a very convoluted way and using 6 levels of inheritance.
At least that's my impression when coding C# vs Java, and no, I'm not an expert in any of those, but trying to accomplish something in C# is usually easier and straightforward.
However, I clicked on this article expecting to see some performance benchmarks to justify the title. Rather, I see some theory about why it MIGHT be faster and also some opinions about what features might make a developer more efficient in C# than Java. I worry that any actual benchmarks would not validate the title. Certainly the web application benchmarks I've seen elsewhere do not align with the title.
Ultimately, it seems to partially conflate performance with developer efficiency. Developer efficiency I am willing to concede: C# may be more developer friendly as a language, putting platform aside.
The first version of C# was a 'meh' - Microsoft's Java(I already know Java; why bother?). C# got interesting(and a better Java IMO), but it took time. C# didn't have package management concepts till late(nuget is still in its infancy), and small to non-existent open source ecosystem. For a long time, it didn't run on anything else but Windows. Hobbyist who weren't willing to buy Windows(doesn't matter much if it comes with your system) and VS licences(express edition came late and explicitly disallows commercial use) didn't try C#.
I've had legal copies of VS for years through this.
"Eligible Web development and design Companies and/or Individuals can participate in WebsiteSpark for up to 3 years."
To the comparison with JAVA - C# is not really cross-platform. I wish for C# on the JVM. Hope that becomes true someday.
And when I wish for C# on JVM, I wish that JVM gets the things to support C# in its entirety as a first class language.
Windows has many problems but one of the worst is poor file system performance. On Windows you waste a lot of time moving large files around when you would hardly notice these times on Linux.
Moving a file is a O(1) operation on Windows just like on any other reasonable operating system. If you're referring to copying between volumes, there's nothing magical about how Linux copies 1GB of data between volumes - Windows does the same thing. It's true that the Windows I/O stack has some performance deficits (the stat() equivalent is slower, for one) but don't be ridiculous, moving files is not a bottleneck.
As for Mono the last thing I want as a developer is to be investing my time in a language with second rate support.
Note that I certainly don't advocate Java for big data either, C++ is the way to go until something better comes along (and I'm not holding my breath).
The most obvious example of this phenomenon is version control software like svn or git. If you profile them you'll see a ton of time spent just querying the attributes of files on Windows.
The problem is that there is no community behind it. The vast majority of C# programmers are do-the-bare-minimum-contractors who hang up their keyboard at the end of the day and go home to their Top Chef and NFL on TV. Those people don't contribute to anything in any community, let alone the open source community.
There are a lot of ways to be able to do C# for free, both as in libre and as in gratis. Mono has about as big of an OSS community behind it as you will find in C#, and it even has support from Microsoft. The language itself is an EMCA standard, and much of the CLR VM and runtime library are, too. The parts that aren't OSS in the library have very reasonable alternatives, in fact, even if OSS wasn't a concern for you, those alternatives are so good you should probably be using them anyway.
And it's in almost every package repository out there, certainly all of the ones I've tried. I personally think setup is a sight easier than Java. I've personally found it a little easier to get setup with Mono that with Java; there is some fragmentation in Java that, while not insurmountable, is still a small annoyance.
Yes, you're not going to get a great IDE for it yet. MonoDevelop is buggy in weird ways. You could cheat and run VS Express in WINE, but I have a feeling some people are going to have a problem with that for no good reason other than to have a reason to complain.
I'd say, if you're the type of developer that is capable of putting together her entire toolchain from the ground up, C# is one of the best languages out there and it's a shame more people don't consider it. If you need hand-holding, then yes, it's really hard to do C# well on anything other than Windows. It's getting better, and will continue to grow, so don't discount it completely.
Your problem is that you're not aware of "the community", not that there isn't one.
A: MS Tax to run it.