Here's a pretty interesting note on .NET Core 1.1's performance improvements from round 13 of Techempower's framework benchmarks [1] (linked from the announcement above):
> Thanks to Microsoft’s herculean performance tuning effort, ASP.NET—in the new cross-platform friendly form of ASP.NET Core—is now a top performer in our Plaintext test, making it among the fastest platforms at the fundamentals of web request routing. The degree of improvement is absolutely astonishing, going from 2,120 requests per second on Mono in Round 11 to 1,822,366 requests per second on ASP.NET Core in Round 13. That’s an approximately 85,900% improvement, and that doesn’t even account for Round 11’s hardware being faster than our new hardware.
Here are the benchmarks in question [2].
There are a few caveats attached, like that it's still not quite at the top and the best improvement is under the plaintext benchmark in particular, but nonetheless a very impressive effort on the part of the .NET team.
TechEmpower also reports that the performance of ASP.NET Core
running on Linux is approximately 760 times faster than it was
one year ago. Since TechEmpower started measuring benchmarks
in March 2013, they have never seen such a performance
improvement as they have observed in ASP.NET Core over the last
year.
My exposure to C# and .NET is small enough that I'm not sure what this means in terms of PHP. Is this like a PHP4 to PHP5.3 or more like PHP5 to PHP7 change?
They're not exactly performance improvements as .NET Core doesn't share any implementation ancestry with Mono (the runtime that was previously benchmarked).
.NET Core's just a better engineered and optimized runtime for running Server Apps on Windows, Linux and OSX.
Basically .NET Core is now the future for running .NET Server Apps on Linux.
The most interesting thing to me is the difference between the results from a year ago. The top scores are 1/3rd of what they were a year ago.
They changed the test rig from an i7-2600K to a Dual Xeon ES-2660v2. Those 4 cores at 3.4ghz destroy the 20 cores at 2.2ghz.
Cloud performance in comparison is terrible. That i7 hits 290k fortunes compared to the cloud VM hitting 30k. You need ~$1500 of VM a month ($0.23 / hour / 30 days / 9) to match a desktop computer from 2011.
After Round 12, we had to find a new physical hardware environment. ServerCentral [1] stepped up and provided some (older) physical hardware for the project. However, the new hardware doesn't match the performance of previous rounds.
The physical hardware for each round has been [2]:
It means that development on Kestrel started before work on making System.Net.Sockets cross-platform was completed. The programming model for libuv and .NET Sockets is different enough (mostly in terms of threading) to make the transition non-trivial.
Some recent basic testing show .NET Sockets perform at least as well as libuv. We are strongly considering transitioning Kestrel to Sockets at the same time we migrate from Streams to Pipelines. [1] Pipelines are basically push based Streams that require less total allocations to use. This is because Pipelines allow better memory sharing between producers and consumers.
Oh thank <insert deity> you distinguish readers and writers by their own interfaces. The kitchen-sink functionality available in System.IO.Stream has always been a nuisance to me.
Lots of news coming out of Microsoft's Connect event. C# is a great language, .NET Core makes it available cross-platform, and now the tooling is being announced (whether it's on par with what's available on Windows is TBD)
IMO The ecosystem of tools on Windows for C#/.NET is what makes it special stack. Resharper and LinqPad are two notable tools that I consider vital to my everyday workflow that just simply don't exist for macOS.
At home I use macOS primarily and I'm trying to ramp up on .NET Core for a few personal projects and I'm having a tough time trying to find a suitable dev environment that provides me with the same speed/comfort that I get on a Windows machine and so far it's tough. Project Rider on macOS is coming along nicely but that still leaves no LINQPad which is super handy for working on small bits of code with near instant results. The feedback loop is so short when using Linqpad it's insane.
You haven't needed linqpad since vs 2015, which has a C# repl in it.
I also don't get the point of resharper. Apart from being slow as molasses, it's ridiculously over opinionated to the point where is makes existing code a mess of squiggles. And it's intellisense is super dumb as it redlines while you're still typing, which is very distracting.
The only great part of it, the quick find, is now in vs 2015. Ctrl-,. I think it literally just came in with the last patch.
I wasn't aware of the enhancement in VS2015. I'll definitely look at that functionality.
VS2015 has made up a lot of ground for what R# lacked but the static analysis still isn't there. You have to learn what errors/notes mean and how to interpret the results because they are very meaningful. Point blank - writing code with Resharper will lead to higher quality code.
And yeah, some part of my Resharper love is just an old habit. I've been using R# since VS2005 when the IDE lacked a lot of critical features that R# plugged. Now a lot of it is just habits and keyboard shortcuts and it's only a few hundred dollars for a license which still pays for itself throughout the course of the year.
I simply disagree about higher quality code. One of my junior colleagues once did a "let's apply a bunch of resharper recommendations". It was not pretty. Its suggestions are almost always pedantic and puerile that don't improve code quality in any meaningful way, at least in the out-of-the-box config.
It's nice when it picks up some stupidity like an always false condition, but the out-of-the-box instance has so many stupid rules that after turning more and more off it off, I gave up on it.
I'm a Windows guy. I love Windows, but I wasn't even going to read any of these because I don't use .net core and I don't use .net on Linux at all. If I build something cross platform it's with node or electron python, etc.
However after reading the top comment on this post, about how ASP.net core is one of the fastest performers, that may have all changed. I might actually look at .net core now.
I have never developed outside of OSX/Linux. My languages are Ruby, Javascript, and the things in that domain. Can someone ELIaRubyDev what .NET is? I used to think it was a language, but I've since been told that the language I think of as ".Net" is actually C#.
.Net is both a run time and an echo system. C# is one of several programming languages (VB, F#) that get compiled into CIL (common intermediate language) and executed on the .Net run time CLR (common language runtime). Think of Java being compiled and executed on the JVM (java virtual machine).
It's a (in theory) OS-neutral platform. It's a huge software stack with many different languages on top of it, all of which target a VM (in the Java sense, not the VMWare sense) that makes it theoretically platform-independent. It allows the different languages to share a common standard library, and that standard library is vast.
That being said, my impression is that most people who write code for the .NET platform use C# to do so.
It's been around for almost 15 years now [!]. I can't believe it's been that long.
.NET is a framework. C# is language. .NET will give you stuff like IO, collections, stuff (FCL) who will run into a VM (security, memory management, etc (CLR). [You can use .NET with Ruby in fact][1].
Ok, it's another release so let me ask this again: can you manage .NET projects without dealing with an IDE like Visual Studio or MonoDevelop or whatever? And for whatever solution you recommend, do people actually use it in the wild or is it just a technical preview thing?
I'm really looking for something like `cargo build` or `go build`, but it looks like .NET just loves their IDEs and XML based configuration files.
the .net core sdk (tooling, the cli command line) is 1.0.0-preview2 and use `project.json`
your xbuild is from mono installed on your system, not .net core
if you download and use the .net core sdk `1.0.0-preview3` you will see the msbuild based csproj
in preview3 (run `dotnet new`).
msbuild based mean `dotnet build` is calling the msbuild library with `/t:Build` argument.
To explicity run msbuild, you can do `dotnet msbuild`
It's really hard to not be snarky when you could build .NET applications before there even was a Visual Studio that supported .NET. I mean, how hard have you looked? My first C# program was written using Notepad or whatever Windows text editor I had lying around and the C# command-line compiler. I wrote it sixteen years ago when C# was still in alpha. IIRC, something like csc foo.cs.
So, yeah, you can create .NET applications without an IDE, and you've been able to for a long time. Was there something specific you wanted to know?
EDIT: in giving the benefit of the doubt, I considered that maybe things had changed since I last written anything for .NET. Maybe the obvious search doesn't return anything. So I tried .NET command line build. I got a full page of what looked to be useful results, including the top result: https://msdn.microsoft.com/en-us/library/78f4aasd.aspx. Now I wish I hadn't wasted the keystrokes on a rhetorical question that I surmise was asked just to be snarky.
I guess the downvoters think I'm being snarky, but this was an honest question. I use Go and Rust mainly and balked every time I looked at C# because of the emphasis on IDEs.
Your link is a great example of what I don't want, though, and this is what I was afraid of. Compare the experience of using `csc.exe` with `cargo`, for example.
I mean, obviously there is some executable that does the work of building your programs, but you wouldn't suggest someone use `gcc` to manage C projects, would you?
I guess the downvoters think I'm being snarky, but this was an honest question.
Okay, well, glad I didn't down vote the comment, then.
Compare the experience of using `csc.exe` with `cargo`, for example.
But, to my knowledge, Rust doesn't have an IDE (forgive me if my ignorance of Rust is showing), so if Cargo did not exist it would be necessary to invent it. C# has an IDE, it could be argued that something like Cargo is not required. I posit that your problem is solved, just not in the manner you would like.
but you wouldn't suggest someone use `gcc` to manage C projects, would you?
No, I'd suggest that they use the IDE. But I've done it, because I'm not shipping bits to customers that were built by a developer hitting the F5 key and pulling the output from their local drive.
I used xbuild, but from Mono, not .NET Core (maybe .NET Core has it too). It builds standard Visual Studio 'msbuild' files (.sln, .csproj, .fsproj). It works okay and these XML files are editable by hand but still somewhat creepy. I tried only F# so I used .fsproj build files and was able to do everything even without Visual Studio Code (in Emacs).
There's also tools called Paket and Fake which look like .NET counterparts of Ruby's Bundler and Rake, created by F# community. Paket patches .fsproj/.csproj files and it looks like hack but still better than putting absolute paths to preinstalled dependencies.
For creating new projects from template, Yeoman (installable from npm) is quite popular.
Build process in .NET looks like is in transitional state from Visual Studio-first to build tools-first and is still painful and confusing. I didn't try project.json / dotnet tooling yet, because F# website doesn't mention it. I tried only F# and Monogame.
> Thanks to Microsoft’s herculean performance tuning effort, ASP.NET—in the new cross-platform friendly form of ASP.NET Core—is now a top performer in our Plaintext test, making it among the fastest platforms at the fundamentals of web request routing. The degree of improvement is absolutely astonishing, going from 2,120 requests per second on Mono in Round 11 to 1,822,366 requests per second on ASP.NET Core in Round 13. That’s an approximately 85,900% improvement, and that doesn’t even account for Round 11’s hardware being faster than our new hardware.
Here are the benchmarks in question [2].
There are a few caveats attached, like that it's still not quite at the top and the best improvement is under the plaintext benchmark in particular, but nonetheless a very impressive effort on the part of the .NET team.
[1] https://www.techempower.com/blog/2016/11/16/framework-benchm...
[2] https://www.techempower.com/benchmarks/#section=data-r13&hw=...