Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance Improvements in .NET 6

devblogs.microsoft.com

Post reply on HN
Print view View original

221–230 of 256 posts

Re: Performance Improvements in .NET 6

#221

Post by zija »

Few gripes with c# (as a hobby developer):

-no sum types, Java 17, kotlin, scala, f#, typescript, rust, Swift, nim, ocaml etc all can modeling types better than C# - no option, no result, exceptions are invisible for caller (ex. Tracking effects in nim)

-NRT doesn't resolve all problems, "required" is better, but I don't know if c# 10 will get it

- no let/val like kotlin, scala, rust. only readonly

- no expression based like kotlin/scala (or required initialization like in rust)

- no exhausting pattern matching

- most community are consumers of Microsoft libraries. Want small rest API framework? use asp.net core, want full stack? Use asp.net core. No other framework, even for rails is Sinatra.

- i would like to see better documentation frameworks with top level comments, doc tests, runnable examples like in rust, nim, d, and unit framework like in d or rust.

- no free functions, top level for only one file in project is too restrictive.

- no easy repl based work ( or community accepted)

From my newbie perspective c# is still good for few things, enormous resources for everything, only java from 'application' languages have more, generics, records, value types etc

Re: Performance Improvements in .NET 6

#222

Post by xvilka »

zija wrote: post #221

Few gripes with c# (as a hobby developer): -no sum types, Java 17, kotlin, scala, f#, typescript, rust, Swift, nim, ocaml etc all can modeling types better than C# - no option, no result, exceptions are invisible for caller (ex. Tracking effects in nim) -NRT doesn't resolve all problems, "required" is better, but I don't know if c# 10 will get it - no let/val like kotlin, scala, rust. only readonly - no expression ba…

Why not use F# then? While being less flexible than OCaml, it is still a huge level up from C# while retaining the ability to use the same libraries.

Re: Performance Improvements in .NET 6

#223

Post by chunkyks »

phillipcarter wrote: post #212
chunkyks wrote: post #50

At work, I'm the maintainer of a 30k SLOC VB.NET codebase. Originally windows-only, when I took over I ran it under mono on Linux and OSX. The day that MS released dotnetcore, I jumped to that. Overall the experience has been really good. There are lots of complexities, but in short... .NET 5 gave it a 4% speed boost across the board, going up to 20% [!] in some cases. Mainly that was ascribable to the intersection o…

I think it's really cool to see a successful example of modernizing a VB.NET codebase so that it too can play with the cool kids. I never really understood the disdain for VB.NET in the developer community, since the language has all kinds of neat little tricks up its sleeve. Kudos for pushing the counter-narrative.

This tool started off as Excel VBA a million years ago, and has made trips through VB6 on its way to VB.NET.

The language is ... ehhhhh. I don't love it, but I don't hate it either. There are things I like, but occasional items that are awful. Sometimes at the same time.

shrug I've been doing this too long to get worked up about language. Of the tools I own nowadays, VB.NET is somewhere in the middle of the pack.

Re: Performance Improvements in .NET 6

#224

Post by throw_m239339 »

olau wrote: post #82
whoknowswhat11 wrote: post #73

Earlier quoted context omitted.

Couldn't agree more. Microsoft lost their minds on the UI / desktop app side - which was a core strength (historically). WinForms was fine / great / amazing. 90% of business / line apps could be handled with it. I have no idea how / why it's taken them so long and they STILL have not gotten their replacement story straight for it and they regressed the designer in .NET. Did they just lose their minds there? Hire a bu…

UI component design is extremely difficult. It's at the intersection between UI design and API design, both difficult disciplines in themselves. It doesn't help that it has traditionally been mired in OO hype sauce.

Yes, UI library design is hard because it a series of trade-offs one has to make when designing the API. Make the API too customizable and it's a horror to use with horrible performances, make the API to rigid and people will complain it's hard to customize. WinForm is far easier to use than WPF... except that WinForm makes creating custom components a pain. WPF is easy to customize... except that it performs worse than WinForm, this isn't even up to debate...

But also, all these moving parts are why a lot of developers chose to go with Web techs for their UI, for better or worse.

Re: Performance Improvements in .NET 6

#225

Post by throw_m239339 »

tralarpa wrote: post #119
olau wrote: post #82

Earlier quoted context omitted.

UI component design is extremely difficult. It's at the intersection between UI design and API design, both difficult disciplines in themselves. It doesn't help that it has traditionally been mired in OO hype sauce.

> UI component design is extremely difficult I don't see much difference between UIs of today and 20 years ago. Actually, I think UIs are nowadays less complex (more screen space available; and you have to worry less about CPU consumption). One would except that was enough time to figure out component design.

> I don't see much difference between UIs of today and 20 years ago. Actually, I think UIs are nowadays less complex (more screen space available; and you have to worry less about CPU consumption). One would except that was enough time to figure out component design.

Today, UI need to be responsive, because of all the different screen resolutions and formats and form factors. That wasn't really the case 20 years ago.

Re: Performance Improvements in .NET 6

#226

Post by pjmlp »

ripley12 wrote: post #198
pjmlp wrote: post #141

Earlier quoted context omitted.

I can vouch for it, given my failed attempts that IDL gets first class development experience given COM, UWP and C++/WinRT. It is up for the community to provide syntax highlighting for a 30 year old language.

That’s on the Windows team, not the .NET team.

Except .NET and Windows belong to same package and some APIs are only available in .NET as COM wrappers.

Re: Performance Improvements in .NET 6

#227

Post by pjmlp »

lloydatkinson wrote: post #210
pjmlp wrote: post #134

Earlier quoted context omitted.

Learn before commenting. WinUI is UWP stack, that is what Reunion is all about, merging both worlds with WinUI on top. Plenty of blog posts where to find such information.

How about before being a condescending person YOU do some reading? https://microsoft.github.io/microsoft-ui-xaml/about.html "WinUI 3 works with any app supported by the Windows App SDK. WinUI 3 can be used DIRECTLY as the UI layer for desktop apps, or starting next year, it can be used to modernize a Win32 app's UI gradually, using XAML Islands to mix and match with the following technologies: WPF WinForms MFC ComCtl…

My dear, if you read throughout the mess that was UWP marketing, UWP is basically IInspectable + .NET Metada instead of TLB + App identity.

I advise you to read about the low level WinRT and COM programming, instead of articles like those from Thurrot.

How much COM and WinRT programming, including XAML Islands have you done?

Start with the BUILD sessions from 2019, to see how everything fits together.

Learn how WinRT types get exposed to WinUI via XAML Islands, to split APIs from underlying OS version, all written in COM using the same WinRT types.

Re: Performance Improvements in .NET 6

#228

Post by ripley12 »

smackeyacky wrote: post #145
m_fayer wrote: post #143

Earlier quoted context omitted.

Hybrid Blazor apps are the solution to the desktop story. It's already happening, it's ready to go. It'll take a while to make it official though, too many faces in need of saving. Avalonia is also a very compelling secondary solution.

Hybrid blazor sounds like something I need to investigate. Thanks for the heads up.

It's somewhat early days, but workable. The search term you probably want is "Blazor Desktop". It's basically Blazor Server but served to a local webview instead of a remote client.

.NET 6 will have some convenient ways to do this in WinForms, WPF, and MAUI. But if you're willing to go off the beaten path a bit, it's not too hard to assemble the bits on your own (serve up Blazor on a background thread, consume it in your web view control of choice).

Re: Performance Improvements in .NET 6

#229

Post by teh_klev »

foepys wrote: post #45
throwaway13337 wrote: post #10

My favorite part of dotnet 6 is the focus on hot reloading not mentioned here. Being able to work on a webapp that rapidly reloads in under a second is huge. It allows me to maintain the state of flow as I'm bringing something to life. I had a unique use case wherein I had a separate worker thread that also needed reloading with the hotreload. I was able to hook into the hot reloading via "[assembly: System.Reflectio…

Even .NET Framework supports this in a limited fashion. Start an application in Visual Studio with a debugger attached, break at a breakpoint, change a line, save, and continue with the new code. No application restart necessary.

VB5/6 had that back in the 90's.

/gets housecoat, pipe and slippers :)

Re: Performance Improvements in .NET 6

#230

Post by ripley12 »

phillipcarter wrote: post #205
foepys wrote: post #39

WinForms and its Visual Studio designer are still broken, WPF is still riddled with bugs and was declared obsolete in ~2017 in favor of UWP, UWP is marked obsolete in favor of WinUI, and WinUI's OSS release was postponed just two days ago because it's not ready. Microsoft is marketing .NET 6 as the replacement for .NET Framework but you still cannot properly do desktop UI with it. I honestly don't understand why they…

Honestly, I don't know why anyone would want to write Windows desktop apps anymore. The browser is the ultimate UI platform and you can do incredible things with it that will work outside of Windows too.

A huge part of .NET's value proposition is that you can do things that aren't possible inside the browser sandbox, and it's nice to be able to build UIs on top of that.

I don't care if my UI ultimately gets rendered by a browser engine, but as things currently stand UIs that were relatively easy to build in WinForms/WPF/UWP are a bit of a pain with Blazor and friends.

(and yes, I'm aware of F# and SAFE but every time I try to get started with F# I run into too many tooling issues)

Post reply on HN