Live data from Hacker News

.NET Core 3.0

devblogs.microsoft.com

121–130 of 183 posts

Re: .NET Core 3.0

#121

Earlier quoted context omitted.

I think it's a combination of monopoly effects plus the benefits of open source: back when .NET was closed-source and only available on Windows, the only way to ship a performance improvement was if an individual developer at Microsoft could convince his boss it was worth it. And it was rarely worth it, because .NET only ran on Windows, its only customers were .NET-only enterprise shops who weren't about to move to a…

The "proprietary" .NET was very performant. It's the new "open" one that has to catch up.

You have posted something along these lines twice, it is not correct. .NET Core has been better performing than Framework from the start. You may be thinking of Mono.

Re: .NET Core 3.0

#122

When I was in University people loathed .NET and idolized Java. Back then I choose C# instead of Java for my main language/toolset; People thought I was crazy. That was 10 years ago. So happy to see how much C# ecosystem has improved and keeps improving; Only thing missing for me is an official full featured C# to C++ transpiler; Only way, right now, of reaching game console platforms is by converting from C# to C++…

Or use Unity?

Re: .NET Core 3.0

#123
post #96

Is anybody using Blazor for anything that isn't a toy? I'm interested in using it at work but because it appears that the payload is relatively large I wouldn't want to use it for anything that wasn't internal facing.

Client-side Blazor is not production-ready with Asp.NET Core 3.0. It's coming in a later release and only server-side Blazor is launched today.

We've been using the server-side components for lots of internal apps. It's very fast and productive to work with, and a great option for internal/enterprise/LOB apps that don't have a lot of users and can handle an occasional reconnection/interruption.

Re: .NET Core 3.0

#124
It's nice to see Alpine on the list of supported operating systems. The image mcr.microsoft.com/dotnet/core/runtime:3.0.0-alpine3.9 is 86.7MB.

Re: .NET Core 3.0

#125
post #96

Is anybody using Blazor for anything that isn't a toy? I'm interested in using it at work but because it appears that the payload is relatively large I wouldn't want to use it for anything that wasn't internal facing.

>it appears that the payload is relatively large Not knowing much about Blazor, what are you referring to here? The size of the WASM blob for your own code, or does Blazor have an associated runtime that's large? And what is considered "large"?

I guess I was hoping the WASM/IL trimming would be more aggressive. My comparison isn't very scientific, I'm mostly comparing things like https://fsbolero.io/TodoMVC/ which is done with Blazor vs https://yew-todomvc.netlify.com/ which is done with Yew. The former is nearly 6MB in total, the latter is 135KB.

Re: .NET Core 3.0

#126
post #5

What's crazy is that this is what C# should have always been. I was into Mono way back because I thought niavely it was going to be more successful, but I think if C# had gone this route earlier -> the whole python / go etc popularity boom might have been softer and MS would have had a first class player that would have increase # of folks easily able to build in windows. That and I never got to develop successfully…

I’ve thought about this but I doubt it. The big change has been the perception shift. .NET was always really solid tech. Microsoft has always had stellar developer technology. But the love affair with open source and the super villain role that Microsoft played, is what kept people away, not the tech itself. I remember wanting to give a talk about how amazing C# was to a ruby group. I never did it, but it was definit…

The ecosystem is what drove me away from C# (as well as not wanting to do enterprise work). I started dabbling with Ruby and Node and the sheer number of free third party libraries blew my mind. C# simply didn't compare.

Re: .NET Core 3.0

#127

Earlier quoted context omitted.

>it appears that the payload is relatively large Not knowing much about Blazor, what are you referring to here? The size of the WASM blob for your own code, or does Blazor have an associated runtime that's large? And what is considered "large"?

I guess I was hoping the WASM/IL trimming would be more aggressive. My comparison isn't very scientific, I'm mostly comparing things like https://fsbolero.io/TodoMVC/ which is done with Blazor vs https://yew-todomvc.netlify.com/ which is done with Yew. The former is nearly 6MB in total, the latter is 135KB.

Blazor client-side works by using the Mono runtime which is compiled and run as WASM. Your application is still delivered as standard DLLs and interpreted by that runtime.

They're working on making the runtime smaller and faster to start still a lag since your code has to be parsed and interpreted everytime, although the DLLs are pretty small already and easily compressed.

Re: .NET Core 3.0

#128
post #76

Earlier quoted context omitted.

Re: I would say the learning curve is pretty high If you had to rank and list the top rough spots in the transition, what would they be? Entity-Framework changes are often cited, but what else is different enough?

It depends where your starting point is. Core bundles a lot of stuff together that was previously separate or just good practice. If you are familiar with MVC / WebAPI / EF / OWIN and already doing DI / Logging etc. then it's not much of a leap.

This is correct. I did not use DI before moving to Core and that was probably the toughest. Once learned, DI is great.

MVC 5 to Core should be a pretty easy transition if you know DI.

Re: .NET Core 3.0

#129

Earlier quoted context omitted.

Chromium is naturally bloated and heavy, what would be the goal in comparing it to WPF

The goal would be to challenge your belief. If you were knowledgeable, you would know for example that chromium 2D rendering engine (skia) is the current state of the art. Benchmarking fps, vsync stability, input latency, etc would be enlightening. There are order of magnitude more engineers working at optimizing chromium than WPF.

I think the OP meant "bloated and heavy" in terms of the sheer size of the thing, not the performance of it. And it is. It's very difficult to use _just_ the 2D rendering part of Chromium, you bundle the whole thing, warts and all.

Re: .NET Core 3.0

#130

C# (the default .Net lang) has so much ceremony, boilerplate/scaffolding and IDE dependence (IDE programmers) and OOP overhead that it requires 5x more lines of code than the same app in Python or Go. Every time my interest peaks, I take a look leave with the same feeling that it's a dated/bloated OOP relic and would take all the joy out of programming. I've also noticed that most C# programmers don't usually know an…

I'm not sure about the comparison to Go as that can get very verbose. Same with Python. And JS is an absolute mess compared to C#/.NET which has a fantastic standard library and many conventions to get going fast.

.Net (and Java) run the Fortune 1000 so there will of course be lots of devs specialized in that. There's nothing wrong with being very good with 1 language and stack when you're paid to be productive for the company. Also you can definitely write C# with a simple text editor if you have to, and VSCode is pretty slim already, but why would you want to when there's such a powerful IDE available?

This sounds like a purity argument about how to be a "real programmer", but I would much rather work with people who are good at what they do and get things done instead.

Post reply on HN