With .NET going open source, I'd like to see what is out there for web services. Are there any linux-compatible .NET web servers/routers that I can use that have a similar feature set and performance to the Spray/Scala stack? C# or F#, but preferably F#. I've tried a couple (suave, nancy), but some simple benchmarks showed they were about half as scalable as spray.
Were those simple benchmarks running on Mono? .Net is certainly going open-source, but it hasn't arrived yet. It might be worth rerunning those benchmarks once .Net proper is available for *nix.
Yes they were on the latest version of Mono, which in my experience outside of web programming is just as fast as the JVM. I think the gap has more to do with the libraries than the VM, but I'd be willing to wait it out to see. I'm not migrating soon anyway...although it would be nice to know how far out it is.
Benchmark: C# (Mono) - 1052.041381 ms, Java - 597.9874 ms
My machine: C# (Windows) - ~475 ms, Java - ~552 ms
Even considering that Mono is using maximum precision available (so instead of floats it's using doubles), when I swapped all floats to doubles it still ran in ~525 ms on my box.
So while Mono might be 'getting there', sometimes it's still lagging behind. It's just something to keep in mind :)
+1 on this - getting ASP.NET working really well on Linux/Mac, with first-party framework and VM, is the main goal for all of the in-flight .NET Core CLR open source stuff. That + console apps are literally all that's going to be supported, at least initially. Microsoft cares a lot about making this good.
In this case half as scalable really doesn't clarify what you mean. If I can through twice as many servers at the problem and it runs as fast, then to me it's just as scalable.
* Do you mean half the performance per connection?
* Throughput falls off at half the connections?
* Will start trailing off at half the number of servers?
In my mind there's a cost to development time, architecture thinking as well as developer cost to maintain/adapt/enhance. If you can throw more runtime resources at a problem, and that costs you a fraction of a man-year of labor over the next five years vs. taking longer to develop, or fewer developers skilled enough to make modifications, these are real concerns. It really depends on context.
