7 ms·

How is it nicer? It's a .NET shop but devs are free to use linux as their OS?

by nobody271 8y ago

SolarNet 8y ago
Also not tied to visual studio to build. `dotnet` is an node style command line tool.
- lkitching 8y ago
  You haven't needed Visual Studio to build .net projects for a long time, project files are MSBuild files.
  - hermitdev 8y ago
    You've never needed Visual Studio to build .Net projects. They have supported MSBuild from v1.0, you just needed to write the project files by hand - a very tedious process. It's just that building from Visual Studio is by far the most convenient method.
    - pjmlp 8y ago
      MSBuild was introduced around .NET 2.0 after Ant's introduction in the Java world. Before there was a project format, callable with devenv command line tool.
  - rblatz 8y ago
    Speaking of the project files, the new csproj format is my favorite thing. We used to always get conflicts in them, and now we basically never do.
  - svick 8y ago
    But there was no good way to edit .csproj files without an IDE and you needed to edit them for every source file you added (or moved). Now you don't have to edit them as often (wildcards for files), they're easier to edit by hand (because they contain almost no clutter) and there are also command line tools to edit them (like dotnet add package).
    - SuddsMcDuff 8y ago
      Wildcards have been supported for source files for many years. <Compile Include="**/*.cs" /> I was doing this back in the .NET 3.5 days. But nitpicking aside your point is well taken, the developer experience is far better with dotnet core.
      - svick 8y ago
        As I understand it, if you ever opened such project in VS, it would replace the wildcard with the current list of files. So the usability of that approach was very limited.
        moogly 8y ago
        Correct. It wasn't really usable.
        SuddsMcDuff 8y ago
        Ah, I see. I wasn't using VS (which is why I found the wildcard trick). It seems like VS was the issue then, and one of the reasons donet core has a better experience is because it's much less bound to VS.
sorrymate 8y ago
It also makes running Docker a whole lot easier. I know there is Docker for Windows, but it feels like a red headed step child compared to Docker on Linux.
- coreyh14444 8y ago
  ^ that's now how Docker works. aka, the whole point of Docker is it doesn't matter what the host OS is.
  - nchie 8y ago
    That's not really true, OS definitely matters with Docker, both on the host and the container. Docker for Windows uses a VM to run Linux containers.
    - danielhlockard 8y ago
      > OS definitely matters with Docker, both on the host and the container. What OS in the container? A docker container is not a VM. Most of my containers are on the order of 10s of MB, and just contain a single binary.
      - nchie 8y ago
        I'm not disagreeing to any of that, what I'm saying is that to run a Linux Docker container on Windows, you'll need a Linux VM which runs Docker, which is exactly what Docker for Windows does for you using HyperV.
        danielhlockard 8y ago
        You're right on that, but there's no "OS" inside of a container to speak of.
        nchie 8y ago
        A 10mb Linux container will still share the Linux kernel with the host, hence it's still running on Linux, even if it doesn't have any dynamic dependencies. There's no OS "inside" the container, no, but it's still dependent on an OS. I think we agree. :)
tluyben2 8y ago
And Mac OS X, also a lot of work was done to make Core nice; it builds fast, low latency for ASP.NET and more. I use vim under Linux and I could not be happier. I was always against the choice for .NET because of the lock in; now that that is gone, it is great.
mr_overalls 8y ago
One improvement that doesn't get enough attention, IMHO, is that Asp.net core is now performant as hell. https://www.techempower.com/blog/2016/11/16/framework-benchmarks-round-13/ https://www.techempower.com/blog/2016/11/16/framework-benchm...
- ksec 8y ago
  Well it has always been performant. The whole Stackexchange is built with ASP.net, and it render things 10x faster than Ruby Rails while requiring 10x less hardware resources. [1]https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...
  - mr_overalls 8y ago
    From the Techempower blog post I linked to above: "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. That is not a typo, it's 859 times faster! We believe this to be the most significant performance improvement that this project has ever seen."
    - svick 8y ago
      In the past, TechEmpower benchmarks only ran on Linux, so their benchmarks for .Net actually used the Mono project's implementation of ASP.NET, which was slow. That's why the increase was so significant. If they were comparing ASP.NET Core with .Net Framework on Windows, the difference would have almost certainly been much smaller.
      - mr_overalls 8y ago
        I see - good point.
      - nicoburns 8y ago
Someone1234 8y ago
It is a completely different architecture from the ground up, completely re-written with modern development in mind. For one example it has native support for dependency injection, and in general testability has massively improved since it was a core design goal. They've also de-coupled several layers, which is hugely powerful since you can write your own middleware. For example check out this article on "Handling Errors Globally with the Custom Middleware"[0]. If you want to see how different it is from .Net Framework look at this diagram: https://msdnshared.blob.core.windows.net/media/2017/06/062217_2209_ThenewNETAp12.png https://msdnshared.blob.core.windows.net/media/2017/06/06221... [0] https://code-maze.com/global-error-handling-aspnetcore/#builtinmiddleware https://code-maze.com/global-error-handling-aspnetcore/#buil...
- sk5t 8y ago
  The diagram (and your comment) appear to be about ASP.NET and don't tell anything about .NET Core compared to, say, .NET Framework 4.5.
  - Someone1234 8y ago
    Frankly because nothing outside of the .Net Core's Web/Asp.net/MVC/WebAPI improvements actually matters. And the changes there are massive and significant. While you can technically create Forms, WPF, and UWP applications using .Net Core on Windows, that isn't really the direction or focus of the framework. Just a niche for legacy software or people who continue to need Windows specific desktop applications. https://trends.google.com/trends/explore?q=%2Fm%2F02_qnn,%2Fm%2F03f8ny,Windows%20Presentation%20Foundation,uwp,%2Fm%2F07sb4tb https://trends.google.com/trends/explore?q=%2Fm%2F02_qnn,%2F... Console applications might have a future for cross-platform headless sever loads. But outside of that it is a web framework that happens to support non-web projects on the side. It is competing primarily with e.g. Java, Ruby on Rails, Node.js, PHP, etc.

How is it nicer? It's a .NET shop but devs are free to use linux as their OS?

SolarNet 8y ago

Also not tied to visual studio to build. `dotnet` is an node style command line tool.

lkitching 8y ago
You haven't needed Visual Studio to build .net projects for a long time, project files are MSBuild files.
- hermitdev 8y ago
  You've never needed Visual Studio to build .Net projects. They have supported MSBuild from v1.0, you just needed to write the project files by hand - a very tedious process. It's just that building from Visual Studio is by far the most convenient method.
  - pjmlp 8y ago
    MSBuild was introduced around .NET 2.0 after Ant's introduction in the Java world. Before there was a project format, callable with devenv command line tool.
- rblatz 8y ago
  Speaking of the project files, the new csproj format is my favorite thing. We used to always get conflicts in them, and now we basically never do.
- svick 8y ago
  But there was no good way to edit .csproj files without an IDE and you needed to edit them for every source file you added (or moved). Now you don't have to edit them as often (wildcards for files), they're easier to edit by hand (because they contain almost no clutter) and there are also command line tools to edit them (like dotnet add package).
  - SuddsMcDuff 8y ago
    Wildcards have been supported for source files for many years. <Compile Include="**/*.cs" /> I was doing this back in the .NET 3.5 days. But nitpicking aside your point is well taken, the developer experience is far better with dotnet core.
    - svick 8y ago
      As I understand it, if you ever opened such project in VS, it would replace the wildcard with the current list of files. So the usability of that approach was very limited.
      - moogly 8y ago
        Correct. It wasn't really usable.
      - SuddsMcDuff 8y ago
        Ah, I see. I wasn't using VS (which is why I found the wildcard trick). It seems like VS was the issue then, and one of the reasons donet core has a better experience is because it's much less bound to VS.

sorrymate 8y ago

It also makes running Docker a whole lot easier. I know there is Docker for Windows, but it feels like a red headed step child compared to Docker on Linux.

coreyh14444 8y ago
^ that's now how Docker works. aka, the whole point of Docker is it doesn't matter what the host OS is.
- nchie 8y ago
  That's not really true, OS definitely matters with Docker, both on the host and the container. Docker for Windows uses a VM to run Linux containers.
  - danielhlockard 8y ago
    > OS definitely matters with Docker, both on the host and the container. What OS in the container? A docker container is not a VM. Most of my containers are on the order of 10s of MB, and just contain a single binary.
    - nchie 8y ago
      I'm not disagreeing to any of that, what I'm saying is that to run a Linux Docker container on Windows, you'll need a Linux VM which runs Docker, which is exactly what Docker for Windows does for you using HyperV.
      - danielhlockard 8y ago
        You're right on that, but there's no "OS" inside of a container to speak of.
        nchie 8y ago
        A 10mb Linux container will still share the Linux kernel with the host, hence it's still running on Linux, even if it doesn't have any dynamic dependencies. There's no OS "inside" the container, no, but it's still dependent on an OS. I think we agree. :)

tluyben2 8y ago

And Mac OS X, also a lot of work was done to make Core nice; it builds fast, low latency for ASP.NET and more. I use vim under Linux and I could not be happier. I was always against the choice for .NET because of the lock in; now that that is gone, it is great.

mr_overalls 8y ago

One improvement that doesn't get enough attention, IMHO, is that Asp.net core is now performant as hell. https://www.techempower.com/blog/2016/11/16/framework-benchmarks-round-13/ https://www.techempower.com/blog/2016/11/16/framework-benchm...

ksec 8y ago
Well it has always been performant. The whole Stackexchange is built with ASP.net, and it render things 10x faster than Ruby Rails while requiring 10x less hardware resources. [1]https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...
- mr_overalls 8y ago
  From the Techempower blog post I linked to above: "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. That is not a typo, it's 859 times faster! We believe this to be the most significant performance improvement that this project has ever seen."
  - svick 8y ago
    In the past, TechEmpower benchmarks only ran on Linux, so their benchmarks for .Net actually used the Mono project's implementation of ASP.NET, which was slow. That's why the increase was so significant. If they were comparing ASP.NET Core with .Net Framework on Windows, the difference would have almost certainly been much smaller.
    - mr_overalls 8y ago
      I see - good point.
    - nicoburns 8y ago

Someone1234 8y ago

It is a completely different architecture from the ground up, completely re-written with modern development in mind. For one example it has native support for dependency injection, and in general testability has massively improved since it was a core design goal. They've also de-coupled several layers, which is hugely powerful since you can write your own middleware. For example check out this article on "Handling Errors Globally with the Custom Middleware"[0]. If you want to see how different it is from .Net Framework look at this diagram: https://msdnshared.blob.core.windows.net/media/2017/06/062217_2209_ThenewNETAp12.png https://msdnshared.blob.core.windows.net/media/2017/06/06221... [0] https://code-maze.com/global-error-handling-aspnetcore/#builtinmiddleware https://code-maze.com/global-error-handling-aspnetcore/#buil...

sk5t 8y ago
The diagram (and your comment) appear to be about ASP.NET and don't tell anything about .NET Core compared to, say, .NET Framework 4.5.
- Someone1234 8y ago
  Frankly because nothing outside of the .Net Core's Web/Asp.net/MVC/WebAPI improvements actually matters. And the changes there are massive and significant. While you can technically create Forms, WPF, and UWP applications using .Net Core on Windows, that isn't really the direction or focus of the framework. Just a niche for legacy software or people who continue to need Windows specific desktop applications. https://trends.google.com/trends/explore?q=%2Fm%2F02_qnn,%2Fm%2F03f8ny,Windows%20Presentation%20Foundation,uwp,%2Fm%2F07sb4tb https://trends.google.com/trends/explore?q=%2Fm%2F02_qnn,%2F... Console applications might have a future for cross-platform headless sever loads. But outside of that it is a web framework that happens to support non-web projects on the side. It is competing primarily with e.g. Java, Ruby on Rails, Node.js, PHP, etc.