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.
Other threads are accusing astroturfing. I don't want to start a witchhunt, but looking at the user accounts, we've got one that has a nearly 2 year gap between their last comment and this week when they started posting, an account 1 day old, another account with a huge commenting gap to date, and a fairly normal looking account.
I guess it's up to the community whether they care someone was paid to submit the article they're reading and commenting on. It's not like we haven't been having interesting discussions, and one way or another these things would have made it to the front page of HN considering the connect() event is today.
There seems to be little question that Microsoft has targeted HN. The other morning I saw a banal MS post go up at 4am Eastern Time and amass almost 500 upvotes in half an hour. I seldom see truly cross-cutting, interesting stories see that rate during prime time.
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?
>The pessimist's take: there was a lot to improve.
This is the rational take. The prior results were completely out of scale with competing solutions, running two magnitudes slower. Someone finally fired up a profiler and probably found some dramatic issues, fixed them, and boom people who relied upon the project before, it turns out, were having a grossly under-delivering result. And at the new 859x faster speed, it's still 1/2 the speed of a competitor.
So I'm not sure what the take from it is. It is held as a positive, but to me it sounds more like it's a token project.
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]:
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.
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.
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.
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].
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.
51 comments
[ 3.6 ms ] story [ 95.0 ms ] threadAt 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.
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.
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.
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.
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 guess it's up to the community whether they care someone was paid to submit the article they're reading and commenting on. It's not like we haven't been having interesting discussions, and one way or another these things would have made it to the front page of HN considering the connect() event is today.
There seems to be little question that Microsoft has targeted HN. The other morning I saw a banal MS post go up at 4am Eastern Time and amass almost 500 upvotes in half an hour. I seldom see truly cross-cutting, interesting stories see that rate during prime time.
> 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=...
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?
This is the rational take. The prior results were completely out of scale with competing solutions, running two magnitudes slower. Someone finally fired up a profiler and probably found some dramatic issues, fixed them, and boom people who relied upon the project before, it turns out, were having a grossly under-delivering result. And at the new 859x faster speed, it's still 1/2 the speed of a competitor.
So I'm not sure what the take from it is. It is held as a positive, but to me it sounds more like it's a token project.
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.
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
.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.
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.
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
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.
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.
Or maybe they deprecated this deprecation later? It's all very confusing.
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`
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.
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?
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.
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
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.
you'll see the experience about cli and sdk. All docs about .net core sdk works.
- `dotnet new -l fsharp`
- `dotnet run`
or
- `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`
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...
[1]: http://ironruby.net/
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.