Announcing .NET Core 1.1 | Hacker News Reader

Announcing .NET Core 1.1

blogs.msdn.microsoft.com

163 pointsbenaadams47 comments

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.

[1] https://www.techempower.com/blog/2016/11/16/framework-benchm...

[2] https://www.techempower.com/benchmarks/#section=data-r13&hw=...

  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.

The pessimist's take: there was a lot to improve.

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?

PHP to Hack

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]:

* Rounds 1 through 8: i7-2600K workstations

* Round 9 through 12: 2x Xeon E5-2660v2

* Round 13: 4x Xeon E7-4850

[1] https://www.servercentral.com/

[2] https://www.techempower.com/benchmarks/#section=environment

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.

Could someone explain why "ASP.NET Core 1.1" Kestrel webserver decided to use LibUV DllImpor [1] instead of .NET Asynchronous Server Socket (System.Net.Sockets) [2]. Does that mean that the managed implementation of Async socket is broken and was too slow? [1] "https://github.com/aspnet/KestrelHttpServer/blob/dev/src/Mic.... [2] https://msdn.microsoft.com/en-us/library/bew39x2a(v=vs.110).....

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.

[1] https://github.com/dotnet/corefxlab/tree/master/src/System.I...

Disclosure: In case it wasn't already obvious, I work for Microsoft on Kestrel.

Are there any plans for RIO?

In the long term yes. When we switch to System.Net.Sockets it will be done with an emphasis on transport agnosticism. [1]

ATM, it looks like Sockets will be the priority since it's a cross platform API more similar to what libuv currently provides.

[1] https://github.com/aspnet/KestrelHttpServer/issues/828

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.

Half of HN front page today is Microsoft, .NET, Visual Studio, Connect.

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.

And this isn't the first time I've given it a go.

For working on small bits of code with quick results, https://dotnetfiddle.net/ is a great online solution.

It's their developer event today.

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.

is this bad, good, neutral? i personally love it.

I counted 12 out of 30 links just now, seems like MS PR is in overdrive right now

It happens for any major developer conference... same things happen with google and amazon at their confs.

Yeah and I've noticed any day a lot of tech releases this happens, whether it is google, apple, microsoft, etc.

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).

.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].

[1]: http://ironruby.net/

This explains it much more concisely yet thoroughly than anybody could in a post here:

https://en.wikipedia.org/wiki/.NET_Framework

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.

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.

I know with previous versions of .NET you could, using MSBUILD. That's how we actually built things on the CI server.

There were .csproj files and other XML files to deal with, but you can edit those by hand if you feel the need to.

I wouldn't want to have to do things that way though.

Our CI build server has been building .NET 4.5, 4.6 and .NET CORE components via msbuild.

It's still in preview, but you can build .NET Core apps with the .NET CLI tool: https://www.microsoft.com/net/core#windowscmd

Right on the dotnet core getting started page: https://www.microsoft.com/net/core#linuxredhat

  dotnet build
  dotnet run
  dotnet test

updated: formatting

Thanks, I don't understand why people were recommending csc.exe and msbuild if this was a thing...

Microsoft is deprecating project.json and recommending to move back to msbuild xml files: https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-t...

Or maybe they deprecated this deprecation later? It's all very confusing.

It is quite confusing (sorry) but the format of the project files won't change the command line interaction -- you'll still do

   dotnet build
   dotnet run

Installed .NET core 1.1.0 and it still looks for project.json (and not uses msbuild files).

  $ dotnet build
  Couldn't find 'project.json' in current directory

  $ xbuild
  XBuild Engine Version 14.0
  Mono, Version 4.6.1.0
  Copyright (C) 2005-2013 Various Mono authors

  Build started 17.11.2016 18:08:11.
   ...

  Build succeeded.

Also it creates project.json when creating new project.

.net core 1.1 is the runtime (coreclr + bcl)

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.

It's a good point, and i think now is fixed.

Really few people just call the compiler directly.

before there was the msbuild but was ugly from command line:

- msbuild /t:Build /p:Configuration=Release

That's why the created the .net core sdk (http://github.com/dotnet/cli).

it's always the compiler all the way down.

but you can do

- `dotnet new -t console` for template

- `dotnet build -c Release` to compile

- `dotnet run` to build+run

- `dotnet pack` to build+ create a package

- `dotnet publish -r osx` to build+create standalone version

- `dotnet test` to build+run tests

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.

for f# on .net core (preview2), see https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-...

you'll see the experience about cli and sdk. All docs about .net core sdk works.

- `dotnet new -l fsharp`

- `dotnet run`

- `dotnet new -l fsharp -t lib`

- `dotnet build`

- `dotnet pack` for nuget packages

Ide works in vs code works with Ionide plugin, if you open it after first `dotnet build`

Good blog post as intro "F# Suave app on dotnet core on Kubernetes on Google Cloud"

That's f# and .NET Core console app (who host suave web), published in a docker container and run on k8 on google cloud

http://blog.2mas.xyz/fsharp-suave-app-on-dotnet-core-on-kube...

Was really hoping for System.DirectoryServices in this release but they pushed it to 1.2.

Reply on news.ycombinator.com