Performance Improvements in .NET 6 | Hacker News Reader

Performance Improvements in .NET 6

devblogs.microsoft.com

362 pointspjmlp252 comments

I'm going to pile in too late and sing the virtues of .NET core or whatever its called now. Deployment of web apps to containers is a breeze, the language is modern feeling. Roslyn is about the most awesome thing I have played with. Razor pages are a breeze compared to the giant piles of dependency hell that client side SPAs or node have become. It feels lean and mean and I can be sitting at a debian box or a windows laptop and the experience in VSCode is identical including deploying code to production on AWS.

But like everybody has said, the desktop UI story is garbage. Fingers crossed Maui turns out to be useful because winforms and UWP are hot garbage. Such a shame from the guys who revolutionised gui development with Visual Basic.

Maui is built on top of UWP, in what concerns Windows backend.

Have to agree with the desktop development chaos, look like not wanting to take an hard decision.

Forms and WPF continue, because they are the golden eggs, the ones that most .NET desktop devs actually care about.

WinUI looks like last attempt to rescue UWP, while at the same time in typical Microsoft fashion ignoring the tooling issues surrounding .NET Native and C++/WinRT.

MAUI, well they have to do something with Xamarin, and .NET still lacks an official cross platform so Xamarin be it. On macOS they are basing the backend on Catalyst, what I find completely insane, as most iOS devs know Catalyst apps don't feel at home in macOS.

I think React has shown how UIs can be done in a better way. That's why we have Flutter, Jetpack Compose and SwiftUI now.

React is UI fashion, uses lots of memory, stresses the GC in managed languages and it was already present in Haskell, it just lacked JavaScript way of pushing frameworks.

JetPack Compose was created by React devs, and Swift UI still pales in capabilities to AppKit. Listen to this week rant on Apple's UI Frameworks at ATP podcast.

> Maui is built on top of UWP, in what concerns Windows backend.

No it is not, how is that going to work on Mac? It is it's own thing, and on Windows it will use WinUI not UWP.

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 ComCtl32"

Or here: https://www.thurrott.com/dev/206351/microsoft-confirms-uwp-i...

Oh and look here: http://allaboutwindowsphone.com/flow/item/24274_WindowsUWPde...

And finally from the last link: "You can use WinUI 3 as the entire UI layer for your desktop app, replacing your current main UI framework."

You are probably thinking of XAML which is common to all.

Please do your own research before shitting on someone.

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.

All upcoming UI frameworks by MS are still hung up on XAML. I get that their existing userbase is heavily invested in XAML, but in my experience XAML doesn't add much value, just unnecessarily layer of complexity, that lacks expressiveness of a programming language and makes interoperability between UI and code more convoluted.

There is some "experimental" support for code based UI composition in MAUI, but since XAML is it's primary focus, XAML probably leads design decisions.

I would question how invested the existing customers are in XAML. I have worked at about 6 companies that all use .Net exclusively and I don't think we used XAML once except for maybe an experiment or PoC.

I think the XAML stuff relates more to trying to make things move between devices more easily by using generic ideas like stretching, grid layouts, flows etc. I guess MS are still holding onto the write-once use anywhere ideal which has never made it particularly well in any stack.

So they write their WPF applications in pure C# and VB.NET code?

What's wrong with XAML and what could have replace it?

Maybe HTML?

I haven't used it that much, but from my experience it was incredibly difficult/verbose to create any custom designs, compared to HTML/CSS. It put me off so much that I just picked another language to develop my applications in.

Coming from Windows development since Windows 3.0, I have the exact opposite opinion.

With XAML I can make my ideas fly, with Web, despite doing Web since 1998, I rather let our designer do their magic with HTML, CSS, JavaScript, turning <div> into animated drop downs.

C# with hot reload.

Issues with XAML:

- verbose

- static (not good fit for dynamic UIs)

- templating is unnecessarily complex

- contains code-like constructs (behaviors, convertors)

- being a separate language forces constant mental context switching when developing, which is bad for productivity. Tooling is more complex and breaks more often (like Intellisense issues)

The only good thing that XAML does is separates UI from the model, but you really don't need a separate language to do that.

What would you say are the benefits of XAML that warrant using another language for UI?

>What would you say are the benefits of XAML that warrant using another language for UI?

I think the main reason is they wanted a declarative language along side their imperative language. You don't necessarily need to recompile anything to get a layout drawn in an editor with XAML.

There's nothing "wrong" with XAML, at least nothing "more" wrong than what folks are _really_ comparing it to, which is HTML/CSS/Javascript concoctions.

I like it because it's relatively easy to make half-decent-looking UI's that have excellent functionality. If you need bigger guns, there's some powerful libraries you can use for more polished UI's or you can roll your own with a lot of effort and a long learning curve. For corporate in-house apps, it's hard to beat WPF/XAML.

The same is simply NOT true for anything web-based. I see it is getting better with CSS grid. At least layout is becoming sane-r than the days of tables, flex-box, and bootstrap-everything. But you still have house-of-cards javascript library dependencies on a boat-load of complexity. I realize that the folks who do web-apps day-in-day-out see it differently.

I also remember the winform days when people could make ridiculously elaborate high-function UI's with breath-taking speed. These would look ugly and dated by today's standards (especially on today's high-resolution monitors), but that development speed, the ability to just execute what you want quickly, is sadly missing today. WPF/XAML comes close but that winforms speed is just gone. Unless you want to do winforms-- which you CAN if you really want to, along with wearing double-knit polyester pants with bell-bottoms.

You have never been required to use XAML, however. XAML is just a tool to allow you to describe UI API calls using XML in a way that flows well for both humans and external tooling. If you don't like XAML, just call the same exact API with C#.

I don't even understand why you say "hung up on", XAML is probably the only compiles-to-code UI API I've ever used that actually does what it says it does; I've used similar tools for other UI toolkits (Glade comes to mind), and they're trainwrecks, and I'd rather just use the API straight.

UI development tools aren't for programmers, they're for UI designers: UI designers are generally are bad programmers but good designers, but need to program somehow as part of their job, and UI design tools allow them to be part of the team without having to feel like they're second-class citizens.

You know what happens when we don't have working UI toolsets? UI designers do insane stuff like slap together some HTML, CSS, and JS, and don't care that the usability of that from either the end-user perspective or the programming perspective is absolutely awful.

Would you rather use Electron or would you rather use XAML? At least with XAML, it works, and when it doesn't work, it can be made to work. Electron is eternally unfixable.

When I was using it, all documentation samples (and nearly all other resources) were for XAML which made it unnecessarily hard to use API in pure C#.

IMO, UI development tools are often not good for anybody. Designers are much more productive using specialized UI design applications like Sketch, Figma, Adobe XD etc. Who is responsible implementing the design depends on the company/workflow.

> XAML is just a tool to allow you to describe UI API calls using XML in a way that flows well for both humans and external tooling.

Not in my experience. XML feels very unnatural to me. XML being natural for humans was a hype from twenty years ago that was never particularly true in practice. XML feels less natural (to me) than using a normal programming language to make same API calls. XML based UI development tools are also often very unreliable and clumsy.

>specialized UI design applications

Like Blend?

Not the biggest fan of XML either. My primary objections against "simple" XML is repeating element names in open and close tags, the noise of <>, and (in the context of a UI tree) confusion over whether to put element modifiers as XML attributes (strings only) or nested elements (verbose, looks like an object rather than an attribute). And when you bring in namespaces, it gets more verbose and unreadable.

I've actually managed to make "UI in code" somewhat manageable by laying out my UI code in a tree mirroring the widget tree. One issue is waiting for rebuilds, another is difficulty navigating the "big picture" of my code, mapping between on-screen UI and code mentally or through an Inspect Element equivalent.

What do you think about QML?

To manage mental mapping of what is being drawn, I keep methods that create widget trees short. My rule of thumb is that whole method has to comfortably fit the screen at once. For each section of the main tree I create a static function that returns a branch of the tree. These functions have descriptive names that help you visualize what element each function builds. If a tree inside a function is long, it is broken down in the same way.

There are some fluent extensions (for Xamarin.Forms and probably future MAUI) that help you build UI in declarative fashion with C#. Same extensions could be created for other frameworks.

https://devblogs.microsoft.com/xamarin/c-sharp-markup-for-xa...

https://github.com/VincentH-Net/CSharpForMarkup

For reusable custom widgets that can't be done with a static function, I create new classes with their own widget trees. Try to keep widgets composable and avoid inheritance if possible.

Hot reload is coming in .NET 6, so waiting for rebuild will soon be history.

I have no experience with QML so I can't really comment on that.

XAML has always just been an option, for both Xamarin and MAUI. I've always done UI in code and not had any issues.

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

I've been in and around platform development in the .NET space for over a decade (not as a developer, I stopped programming for the web in like 2002 because I couldn't stand the the entire front end paradigm).

My biggest issue with .NET has always been how slow it is compared to <insert any popular server side scripting language here>.

Is there hope?

lol

It has always out performed Python and Ruby. While it usually falls behind Java in general performance. It seems to win in startup time which is important for scripts.

I've always found that someone complaining that XXX is slow is just writing very bad code.

C# is blazing fast, but there's plenty of ways to write boneheaded-slow code.

> But like everybody has said, the desktop UI story is garbage.

Strange, I find WinForms very similar to Visual Basic 6.

The UI designers are very similar. The API is very similar. C# is just a much better language than VB 6.

I personally really like WinForms, but I haven't done anything in it in about a decade.

Microsoft should either use Flutter or make a C# version of something like Flutter. Its simple to understand and doesn't have any magic xaml tag to make things work.

Isn't this just .NET MAUI?

Flutter is somewhat similar to UWP, it includes a cross-platform rendering engine.

MAUI is similar to old Xamarin, it exposes whatever native controls are available on the platform.

Useless for me because I sometimes develop GUI for embedded platforms which don’t have any native controls at all.

Even ignoring the embedded use case, I believe that’s not the right approach overall. Native controls are too different across platforms. Commercial success of Electron demonstrates people don’t give a crap about native controls, they want good UX identical across the platforms, in large part because it saves development costs for cross-platform stuff.

> sing the virtues of .NET core or whatever its called now

I think this is the only criticisms I can level at Microsoft, their branding is just a complete mess!

Core has been dropped from .NET naming but we still have ASP.NET Core MVC (I think?) and we still have EF Core.

"ASP.NET Core MVC" is such a mouthful.

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 are pushing more and more features when they cannot complete the ones they started years ago. Not to mention that porting WinForms from .NET Framework to .NET 6 requires a rewrite for anything more complex than a Hello World.

The UI story on Windows is completely broken but that has been the case forever.

Has MS basically released anything sustainable on the UI side since MFC?

It feels like they’ve constantly provided a new new replacement every few years that replaced the new replacement from a few years ago since then.

That's definitely true but they did a good job supporting their tech once it was released.

My company has been using WinForms on .NET Framework for over 10 years now and it's working really, really well. Microsoft even added HiDPI support to it.

When Microsoft announced they wanted to bring WinForms to .NET Core 3, we were initially very happy as it meant we could switch to .NET Core. But then they did all kinds of shenanigans with it and completely rewrote the designer for .NET Core in Visual Studio, which is now riddled with bugs and crashes constantly. You cannot even load your own custom controls into it. I mean, you can, just get Microsoft to let you sign an NDA to get access to the APIs...

> My company has been using WinForms on .NET Framework for over 10 years now and it's working really, really well.

Despite WPF being preferred amongst developers, WinForms solves most use-cases well.

I’ve not really kept up with Microsoft UI developments but I’d be interested in seeing any cross-platform UI toolkits they develop now or in the future just as an alternative to gtk/qt

The problem is that many features in Forms like data binding or layouts, have bugs, which happen to be only fixed on WPF, because that was the new boy in town.

So when you move beyond VB6 style of applications, there are several head scratching moments.

Sadly this is their policy across the board. Even though things like dotnet core 3.1 is supposed to be LTS, when you report a bug, you are most likely to get the response, "we will only fix it in .Net 5" as if upgrading everything is a 5 minute exercise.

For a company who turns over an enormous amount of money and employs 10s of 1000s of people, you would have thought they could support these separate frameworks with dedicated teams of 10-20 reasonably high calibre devs.

They had to rewrite the designer for .NET Core since the designer runs your own controls' code right during design time (pretty horrifying on one end, but also enables a fairly integrated experience with custom controls). Since Visual Studio is based on .NET Framework the designer had to move out of process, as the only alternative would have been no designer at all.

So that's a twenty-year old codebase, perhaps on both ends (Windows Forms Designer and Visual Studio alike) that now somehow has to be moved to different processes and different runtimes.

Perhaps you have more luck with JetBrains Rider, although from what I've seen they simply host the very same designer in pretty much the same way as Visual Studio and thus are unlikely to fare any better here.

The other option is the still-recommended workaround of keeping the .NET Framework project files around and do designer stuff with those. Also annoying, admittedly, but that's what I've been doing for now (well, for other reasons as well, as we sell a .NET UI component that still has to work in .NET Framework as well).

No they didn't.

Take a look at what happened to silverlight or UWP.

You just happen to be working in the one tech they actually carried on supporting.

UWP is still supported, that is what WinUI is built on.

The problem is that they now seem to somehow carrying that flag forward on top of XAML Islands, with an endless list of bugs.

I had a lot of problems adding HiDPI support to a moderately complex WinForms application. It was a huge time sink.

Is there a UI story that doesn't suck?

Maybe, if you change your perspective. From buddhist teachings i learned that we react emotionally to the labels (our judgements) we attach to what we perceive, not realitty itself which just is.

I'm mostly doing my UIs in Qt and I'm always happy, sure it's not perfect but it consistently allows me to do what I want in a cross-platform way with minimal effort (especially when I compare with the royal empirical pain that is webdev)

For windows what's your hello world workflow / stack. I've wanted to get into QT, but there seem to be a bunch of different flavors out there. I'm more a winforms guy then an HTML/XAML/CSS type person.

On Windows, there are two easy ways to get started: Qt Creator and the Qt Addin for Visual Studio. Qt Creator is easier, I think. Personally, I use Qt Widgets a lot and ignore Qml, because the later has seemingly much less powerful widgets out of the box.

I'll be honest I don't think that doing C++ on windows is a good idea. The language needs to do a lot of file access for includes, and on NTFS those are super slow, my builds on Linux are something like 1/3 of the time on windows (building the same software with the same commit of clang 12 and lld, same computer, same SSD).

But if you don't want to install a Linux partition, then just use aqt to install Qt: https://github.com/miurahr/aqtinstall

You want win64_msvc2019_64 as a platform.

Way too often I see everyone clicking on everything in the installer which amounts to a 30gb download, but for the immense majority of Qt apps you just want the core libs for your platform which is like a couple hundred megabytes (and even then in practice you're going to use only a small part of those unless you have uncommon needs such as serial port, modbus or NFC communication, XML parsing, ...)

C++ builds are only bad when you use too many templates, which Chrome famously does. If you use MSVC you get some additional speedup as well because it tries to avoid disk IO.

I would say Qt on Windows is probably a worse idea than just using .NET as it ties into the OS. If you need cross platform and normally use Windows it's not a bad idea.

> C++ builds are only bad when you use too many templates,

if that was the case I would see the same build times when building the exact same project with the exact same compiler on Linux versus on Windows. Yet Linux is really much faster.

No, you're right, NTFS as implemented in the Windows kernel is very slow. But for most work it's decent enough if you have a properly set up build system. The issue for some large projects is the build system is not set up well.

Disable Windows Defender before your next build.

Chromium uses templates very sparingly. Working with this code day to day, most days you don't see a single template. What it does use a lot of is class inheritance, delegates upon delegates, AbstractFryingInterfaces and whatnot.

>The language needs to do a lot of file access for includes, and on NTFS those are super slow,

I'm not sure I'd blame NTFS as such - but you can massively improve build times by creating a precompiled header .pch include file in your projects.

I already use PCH but can't put everything in them either otherwise it becomes a negative

> and on NTFS those are super slow

Usually it's less to do with NTFS and more to do with Windows Defender Real Time Protection, which murders build times because it synchronously scans files before letting applications open them.

You can disable on a per-folder basis, and it will change your quality of life drastically.

The command line. (Hey, you said UI, not GUI.)

Or for all its faults on macOS, SwiftUI on the iPhone is pretty good.

And depending on your angle of view, depending on the kinds of UI you're attempting to make, you could argue that the UI story of HTML5 is able to not suck if you have the self-discipline to avoid the sucky things.

> The command line

I can think of no shortage of frustrating CLI experiences.

There is no perfect library that solves for all possible problems. Pros and cons and all that. I'm pleasantly happy with all modern UI frameworks across major OSes and HTML5 options. I have so many things to be thankful for complaining about.

I don't think anybody is expecting perfection. Personal I just don't want so much needless churn, especially on the .Net side. WPF in particular seemed to offer so much promise but was abandoned at birth.

I now treat UI stuff from Microsoft the same way I treat services from Google, something to be avoided because it will probably be abandoned within a short period.

There's a major difference though: when Google abandons a service it is gone and you have to look for an alternative. When Microsoft 'abandons' WPF your 15 old application still builds and runs today and receives occasional updates like proper HDPI support.

That would be just about OK if it wasn't half baked in the first place.

I made a GUI using cljfx - that's a react style wrapper around javafx

It was wonderful and runs an all desktops (and I guess theoretically mobile through Gluon). None of that Electron lag. There is a bit of a learning curve - esp if like me you've never done any react

Very Clojure-y, quite low coupling and very composeable

I feel like right now flutter is about 1/10th the level of popularity it will eventually reach. It has a great story for UI from multiple angles (cross platform, developer experience, tooling etc).

It’s still very young v2 only came out a couple of months ago so it’s not entirely without issues at the moment but there are a LOT of apps that I think could easily use Flutter in production across all platforms today and that story is only getting better.

I've been using Xojo (https://xojo.com) for about 15 years now to make cross-platform GUI apps. The language is similar to VB6 but it's been constantly updated. No affiliation, just a happy customer.

> Has MS basically released anything sustainable on the UI side since MFC?

MFC is nothing more that a C++ GUI library wrapping the Windows Win32 GUI layer.

The problem with that Win32 GUI is it has not changed for several decades, which is why any application using that Windows GUI layer looks old and outdated on modern Windows.

Since Microsoft is not updating the Win32 GUI layer, it is basically obsolete.

However so many Windows applications still use that GUI layer and that then makes the Windows UI a complete mess.

Win32 GUI supports theming, that's what Windows XP's Fisher Price UX was all about. "It looks outdated on modern platforms" is a non-issue and total BS.

MFC was kind of a weird beast in general. In some ways it was just a C++ GUI API for Win32, but it did have distinct traits and behaviors that have MFC apps a subtle feel that many found unappealing.

Actually not even MFC was that good when it appeared into the scene.

Borland C++ and Delphi/Turbo Pascal frameworks have always been top notch, and Qt follows their way.

MFC was re-created too low level, because the C guys at Redmond wouldn't use it, the Afx prefix comes from that first attempt.

I do like Forms and WPF a lot, so I fail to see what is broken about them, other than the missing love from doubling down on WinRT since Windows 8.

Ironically, MFC is the best framework for doing C++ GUI on Microsoft stack.

With C++/CX they could have had a C++ Builder like experience, instead politics made C++/WinRT replace it, while whoever is in charge doesn't care about Visual Studio tooling.

So using C++/WinRT is akin to being back in Visual C++ 6 alongside ATL, editing IDL files with a Notepad like experience.

WinForms was definitely very fun to code with when I used it around 10 years ago. MFC on the other hand was a real pain. Some strange thing came afterwards which I never understood why, but then I already moved into Backend/HTML/JS.

Is WinForms really something that is outdated? Or is this new thing one just their attempt at unifying OS and Mobile UIs? I think Windows 10 uses this new framework and I absolutely dislike what I see, specially the entire new configuration system Windows has, compared to Windows 7.

It's not easy to write good reflowing UI in WinForms. You have anchors, but they aren't enough for the more complex layouts. And you have actual layouts, but it's a real pain to set up anything non-trivial with them.

However, there's also WPF. Which is also kinda in the same spot in terms of support and future development, but it's a lot more modern and flexible compared to WinForms.

As for MFC, the main reason why it's such a pain is because it's a relatively thin abstraction layer over Win32, and it doesn't even try to hide most of that underlying complexity (or limitations)

MFC was sustainable?

Agree the UI story has been rough. .NET MAUI seems promising, yes?

Outside of JavaScript, what other (good) multi platform UI frameworks are out there? And I’m hesitant to call JS good, with the amount of slow, laggy, resource intensive apps I’ve come across.

.NET MAUI seems promising unless you're a VB developer.

The writing has been on the wall for VB.Net for a long time now.

Only due to mismanagement and apathy by Microsoft. It could and should be as popular as Python is today.

Why not just learn C#? Same framework, tooling, target, libraries etc, just a different syntax.

I know C#, and I've worked in it. I prefer VB. (To be specific, beyond language differences, VB's app platform is inherently faster to work in, a lot of it is just built-in that take a lot of scaffolding to replicate in C#. You'd be surprised how much of VB isn't directly available to C# developers.)

Should be possible to write fast Electron apps with Svelte, Solid or maybe Imba no?

FreePascal with Lazarus is fantastic. It is so dead simple to use, and mostly just works (e.g. coding up an app on windows, opening it on Linux and hit the compile button, and Done!)

Compared to most prominent JS platforms, WinForms or WPF are awesome. We just got used to the sheer complexity and dev cycle of HTML, CSS, JS and JS UI frameworks especially.

Not that I would not agree that the Windows UI space is a mess but it is rarely about the tech but the management of it.

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 bunch of idiots caught up in fads instead of folks who've been around for a bit.

It honestly is mind blowing. By now they could have had a cross platform WinForms story or something. The new WinForms designer is so annoying at times. "Oh, we support winforms" - no you don't.

And pretty much the stuff after it has been garbage.

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.

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.

> Did they just lose their minds there? Hire a bunch of idiots caught up in fads instead of folks who've been around for a bit.

No, they just took the focus off the Windows UI.

They went cross-platform with .Net Core, which enables it to run in the cloud on Linux boxes. This was the focus.

I hope they come back around to a proper .Net WinForms designer under .Net Core, but for now the full framework can be run and will be supported. There are a massive number of WinForm applications in use. I was recently maintaining a massive 20-year-old .Net WinForms application, it still runs fine.

It is funny how much they have strived for one platform to rule them all when it would have been easier and cheaper just to maintain windows, web and mobile separately and kept the frameworks suited to their particular platform.

I actually think they could have gotten winforms x-platform by now if they'd tried. Or some kind of x-platform story if they wanted.

The endless other crap has just eaten dev time like crazy.

Easy, they did to .NET the same as IE.

When Sinosfky and his team, brought .NET ideas to COM via WinRT, which was kind of Ext-VOS revival anyway, I bet they fired everyone on Forms and WPF, or moved to other teams.

Otherwise how to justify they had to ramp up Forms and WPF teams again, and we have already seen several PMs take ownership of the projects since Core started.

> Microsoft lost their minds on the UI / desktop app side - which was a core strength (historically).

Exactly, was a core strength. They saw the writing on the wall though, SaaS and cloud was where the money was and is at the moment, and that's where .NET now excels.

Would agree with you on Winforms, it's a pretty good GUI RAD development environment, and I wish they'd just stop trying to replace it with something 'better'.

WPF I found to be constantly irritating and produces weird looking GUI apps, but maybe others have a better experience.

What are you talking about? WPF is still supported and a viable way to implement UI components. Same for WinForms. UWP never replaced them. What they are doing with WinApp SDK and WinUI is to extract features that were packaged with UWP to make them available to any type of Windows application.

Xamarin is also still a thing, MAUI will be a thing in the future, Uno is another option, Avalon too. There is a lot of options for .Net GUI, most of them are mature and maintained.

While true in spirit, the GitHub and developer voice tickets kind of show the actual state of affairs, which kind of saddens me.

It feels like desktop teams are running into all possible solutions to see what sticks, instead of fixing what we had.

I would agree with your last sentence, that's a very Microsoft way to handle things: "Hey, look at all of this! You can implement your application USING YOUR FAVORITE TOOLS! Isn't that great that we give you the opportunity to evaluate 36 different framework to see which one is THE BEST for your UNIQUE situation?!".

It's a complete mess and the whole thing feels direction-less but I cannot agree that no good tool exist to implement GUI.

I'm still confused by their React Native for Windows. Very happy to see development in this area, React Native is a fantastic framework, but I cannot understand if it is a toy or something they actually want to commit too. Blazor Desktop is also really confusing and makes no sense IMHO.

Blazor Desktop makes a lot of sense to me. Basically: Blazor Server is getting pretty good and it’s easy to serve it up to a local webview so why not make that an officially supported use case?

Yes, I want to believe in MAUI but the current state and dev process are very concerning. I don't get a good feeling that theres a clear understanding of how Xamarin "failed" (which it had to at some level for it to be replaced) in order to avoid the same issues. I'm also really concerned how soon the cutover is supposed to be (with only 1 year of Xamarin support after) and the current state of MAUI.

As far as UI in .NET in general goes they seem to be throwing stuff at the wall to see what sticks, and no one project seems to have a lot of resources dedicated to it. I imagine this is because it’s simply not a priority for the .NET team. Maybe it’s undervalued a bit, or maybe it’s making the best with the resources they have.

As I mentioned in another comments, I feel that they disbanded everyone as of Windows 8 and UWP, as many businesses did not follow along, they were forced to reboot Forms and WPF teams.

Then you now have Blazor trying to be everywhere, with Xamarin being redone as MAUI (you are expected to rewrite your Xamarin code).

So not so rosy for the time being.

For what it’s worth, WPF and WinUI are owned by the Windows team not .NET.

I suspect it’s less “not a priority” and more “building a good cross-platform UI framework is a colossal amount of work”.

"Azure, Azure, Azure!" is the new "Developers, Developers, Developers!". Microsoft is going to focus where the business growth is, and I'm guessing they don't see improving desktop development as a big money maker for them.

> Not to mention that porting WinForms from .NET Framework to .NET 6 requires a rewrite for anything more complex than a Hello World.

We sell a fairly complex custom control, both for Windows Forms and WPF. There were zero changes necessary for the migration to .NET Core 3 back then. We still build both .NET Framework and .NET Core assemblies from exactly the same source.

Depending on how many 3rd-party dependencies are used and what other weirdnesses one does in code there may well be projects that are impossible or really hard to convert. But overall my experience was that for a lot of applications there are few, if any, changes necessary.

Sign of the times. In the last 5 or so years working as a consultant for large corporates I can't recall ever having to work on new desktop app/features. Everything is moving to the web even for internal uses so I'm not surprised that desktop app dev frameworks are collateral damage somewhat.

Windows Forms and WPF both work with .NET 6. They only work on Windows right now though.

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)

I'm definitely a fan of SAFE, but also it's not hard to discount just regular 'ole JS/TS talking to a .NET backend. There's an incredible array of ecosystem libraries and tools that are much more mature than Blazor.

Y'know, I've been building up my own "regular 'ole JS/TS talking to a .NET backend" solution lately: https://github.com/rgwood/MinimalWebView

It's nice and lightweight but the friction of .NET-JS interop is constant. Blazor Server (hosted in-proc and served up to WebView2) is the nicest solution I've found so far but I'm very open to other suggestions.

It's all about Azure now, which makes for an emphasis on server- side capabilities.

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 of GC improvements and kinda-degenerate cases in the model.

For this particular codebase, very little in that article will be that significant [the VB.NET code uses a pretty limited set of stuff in the core libraries]. But their trajectory, and a million tiny improvements, really gives me a lot of optimism.

What I originally considered a pretty cynical stab at Oracle when they released .NET's source has really turned into a wonderful, performant, developer-friendly, and pleasantly-cross-platform ecosystem.

Wanted to mention in case it was interesting to you, but there’s a Roslyn powered plugin that can convert VB to C#, see https://marketplace.visualstudio.com/items?itemName=SharpDev...

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.

> Sometimes at the same time.

This is how you know you're really working with something :)

A really great article by a friend of mine (and ex-VB.NET PM) is here. Really cool to go through it from time to time: https://anthonydgreen.net/2019/02/12/exhausting-list-of-diff...

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.Reflection.Metadata.MetadataUpdateHandler(typeof(MyHotreloadClass))]" and quickly solve my issue. I was pretty surprised to be able to modify that so easily.

The focus on performance and programming ergonomic makes me optimistic about the future of the platform. As someone who deploys to linux and is generally way outside of MS' ecosystem, this seems like a pretty big deal.

The thing I like the best with dotnet (core) is how great is the cross platform support (for console and web applications). I use macOS most of the time, to build Linux containers and this works perfectly. I recently found a bug in the SDK... which impacts Windows only. Other OS than Windows are really supported.

> My favorite part of dotnet 6 is the focus on hot reloading not mentioned here

Does this work, for example, to reload method changes and so on? I miss this coming from JVM.

It really works!

"dotnet watch" and go. It watches your C# files for changes and reloads when it notices on save.

I use VSCode not visual studio which has some deeper integrations there I guess. But it's still fine.

It's only available in 6, though, as far as I know for real sub-second hot reloads. As it's a preview release right now, it's not as fun to set up but it's not too bad.

5 and below has reloading on code change that isn't quite instant (takes maybe a few seconds) but still works with the same command.

Fun story: back in 2009 at the jvm language summit, Thomas Wuerthinger demo’d full hotswap.

Method signature changes, class hierarchy, all of it.

He wasn’t a sun employee at the time and the sun folks kept telling him what he was doing was impossible. We ended up using his stuff, the dcevm, internally for a long time.

He was eventually hired by sun/oracle to work on other stuff and Java still doesn’t have proper hotswap.

That’s the tech world for you.

His stuff is still around, maintained and very useful via: https://github.com/TravaOpenJDK/trava-jdk-11-dcevm

They say, that java on graal should have full hotswap. https://www.graalvm.org/reference-manual/java-on-truffle/hot...

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.

Visual C++ had that years ago (2005, reading https://blog.codinghorror.com/revisiting-edit-and-continue/)

IIRC, that required a debug build that didn’t run very fast and was a bit fickle. Managed languages maki it a lot easier to implement this kind of features.

Not since async was added. You can’t make changes to any async methods because they haven’t figured out how to update the state machine.

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

/gets housecoat, pipe and slippers :)

Everything old is new again. ;-)

.NET 5.0+ drops the 'Core' from the name. The whole .NET platform has improved incredibly within the past 5 years. Previously, to run a C#/.NET app you would need Windows, Visual Studio, and a license for IIS.

These days, you can run .NET entirely on Linux, without ever touching Windows or Visual Studio.

(Founder here) At Amezmo [0], we've supported .NET for sometime now, and recently added .NET 6 as an option for our managed app hosting platform.

https://www.amezmo.com/platform/dotnet-core

You can, but if you actually start .NET on Linux without Windows and Visual Studio, you're not going to have the best experience. Lacking the background knowledge of the old .NET framework and how VS works was a consistent pain - both when reading outdated documentation and when getting help on something.

I'd recommend it to a Windows dev who wants to go crossplatform, but never to a crossplatform dev.

As someone who was encouraged as part of a merger to start looking at dotnet who was entirely Linux based previously I've found this experience to be better than I expected.

It's confusing if you have to deal with legacy applications running old versions of the frame I concur, but if you're on a greenfield project working with dotnet 5+ the experience is pretty good.

I work with vscode on nixos which is probably one of the most challenging Linux environments, and have experienced no blocks. I have had to install mono manually to work around some bugs and write a couple of patches as vscode can't write things where it wants to the read-only nature of nixos, but this is just part of the usual nixos experience.

TLDR: For me, if you're using linux and you wanna give dotnet a go, try it, you might also be pleasantly surprised.

This is simply not true. I have developed years .NET Core C# solutions on Linux with zero friction. My choice for IDE in Linux is Jetbrains Rider, which I actually think is in many ways supperior to VS.

Got this "Access denied | www.amezmo.com used Cloudflare to restrict access" (from India)

> Previously, to run a C#/.NET app you would need Windows, Visual Studio, and a license for IIS.

Hasn't Mono existed since 2004? Any Unity game has been running C# on many platforms by using Mono.

> Previously, to run a C#/.NET app you would need Windows, Visual Studio, and a license for IIS.

Only the .NET Framework (for Windows) or Mono (for Mac and Linux) was required to run .NET apps. Since the early 2000s, development could be done with SharpDevelop (Windows) or its fork MonoDevelop (Mac/Linux) instead of Visual Studio as well.

Don't forget Notepad.exe +

    csc.exe /out:HelloWorld.exe /target:exe Program.cs

For large enterprises, that use AWS / GCE / Azure, these improvements directly translate into huge savings in server capacity.

I have always loved .NET and it keeps getting better and better.

They have shown remarkable flexibility to throw away ideas that don't work and have modernized.

A large part of that is due to active involvement of the community.

This could be a new model moving forwards, a software worlds equivalent of "the customer is always right".

I’m thorn on that. As someone who has had intermittent periods of .NET, it’s a complete mess every time I’ve come back after a couple of years off and figuring out what new APIs are the new thing to use, which have been deprecated and when looking for a solution of something involving e.g. configuring stuff in the web server request handing stack it’s a real confusing mess.

Docs of course aren’t all up to date and are some times contradictory. Maybe it's better today but I've had plenty of 404s on official docs as well.

It’s way worse than React in this regard (if not only by its sheer size and larger scope)

The rapid changing allows them to do good stuff like you say, but it’s like the only way to write modern .NET properly is to have throughly read every release notes since about v4....

> It’s way worse than React in this regard (if not only by its sheer size and larger scope)

FWIW, I've used React for 18 months now. Except Java and classic core PHP it is one of the most stable platforms I've developed on.

So, in my view being less stable than React isn't a big problem.

Yeah, I'm talking about having used React extensively since its inception 8 years ago with a couple of 1-3 years periods of being out of that ecosystem and coming back again.

I'm sure it's a completely different game these days.

Especially I recall that with lifecycle methods, previously idiomatic patterns would be deprecated with stern runtime warning within a year. Like this: https://reactjs.org/blog/2018/03/27/update-on-async-renderin...

Granted React team has been way more effective at communicating than the .NET team, again facilitated by a much smaller scope.

As for the ecosystem:

Anyone else remembers when react-saga was The One Way To Manage Effects? Or going through all the major versions of react-router?

I agree, React itself can be remarkably stable because they found the right abstractions early on and have been able to evolve just small variations of those central patterns over time.

All the stuff people expect to use around react, on the other hand. That sees huge amounts of churn.

Luckily, if you can get everyone to accept it you can often manage just fine without.

I'm lucky to be on a team that agreed that redux etc wasn't necessary somewhere before I arrived, and coming from other places that insisted on latest fads it has been blissful.

React itself is incredibly stable, for sure, but its third party dependencies (core libraries most use) are a little less so

For what it is worth this is one thing the team I work on did before I arrived there and that I now tell new team members:

we actively avoid dependencies, especially redux.

React actually works fantastic without if you do it correctly and we rarley have any hard debugging problems that get my head to feel it will explode.

I had one big debugging job during the last few months and that quickly turned out to be on the backend.

Major version releases have breaking changes. I don't see the issue. I've been doing .NET development since the original version was in beta (20 years now?) For the most part I have no complaints about the docs - and hey you're free to submit a PR against the docs if you want to contribute, have at it: https://github.com/dotnet/AspNetCore.Docs

There has been more churn than usual during+following the .NET Framework -> .NET Core migration. Some of it was necessary due to the migration, some of it is making up for lost time after being tied to Windows (and very constrained in their ability to make changes) for so long.

I understand your pain but I think most of the recent changes are necessary for the long-term health of the ecosystem, and I would not expect the breakneck pace of the last 5 years to continue forever.

Worse than react? I honestly never complained about react at all. It's great, the community, the docs, the way they release new features. Not sure what's bad for you

I think the transition from .NET Framework to .NET Core was inherently difficult, but was made worse by poor naming strategies and extremely poor communications.

But now that MS is largely over that hump, I think they’ve been doing a really good job.

They still have problems with listening. It got much better but they often do not hear or understand when it does not fit into the world picture of their product managers. This is human (and in that level not bad or malicious) but they are a bit too proud for it.

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.

The languages are all owned by Scott Hunter. Including e.g their Java support etc. The windows sdk not. Where exactly the language projections are, no idea. IDL and COM however sounds indeed more like Windows team and not language and runtimes team.

Yeah, classical Microsoft where externals have easier time talking across divisions than internal employees, only interested on their own silos.

I know of cases where externals where tasked with fetching information due to that culture.

It’s an amazing write up. I posted this yesterday but it only had a few votes - I’m so glad to see it get attention. It’s a treasure trove of historical info, benchmarks, introspection into Win32 and .NET design decisions, and architectural trade-offs. It took me a long time to read through it, but I wonder how long it took Stephen to write.

On the topic of WPF apps in .NET core:

Can anyone who has successfully migrated WPF apps to .NET core, in production, chime in on what was the experience like? Any major pitfalls or pros/cons to consider?

I have a prospective client, running a WPF app in a soon to be deprecated windows embedded machine. They have a lot of domain knowledge in the app so are unwilling to re-write or port.

I was thinking if it is feasible at all to migrate this WPF app to .NET core and then migrating the target to a higher longevity Linux machine.

WPF is still Windows only. It will not work on a Linux machine.

Indees it seems to be a dead end.

https://github.com/dotnet/wpf/issues/48

Thanks for clarifying.

For a WPF-like development experience that's also cross-platform, perhaps take a look at Avalonia: http://avaloniaui.net/. It's not a drop-in replacement, but very, very similar.

One of the pitfalls I've encountered is the need to use the tray icon api, which as of now still is not in .NET core.

Some minor stuff with dispatching to the UI thread, nothing serious. Oh and you'll need a new package to get the System.Windows.Interactivity stuff.

The resulting binaries are huge if you publish self-contained. If you don’t, you’ll need to include the redistributable installer so it’s still huge. Tree shaking is still in its primacy.

Making JIT 4% (or whatever) faster is cool but it would probably have higher ROI for the .NET ecosystem if Microsoft assigned some of these high caliber people to instead work on improving or simply rewriting some of the atrocious open source libraries that are available.

Would you rather have an A language/runtime with a D open source ecosystem or a B for both?

I think that you're making a good point, and at the same time I think that tasking MS Devs with rewriting parts of their ecosystem is a bit of a minefield for any company, but especially Microsoft.

Long-term they need people to make good contributions to the ecosystem and I imagine it would be hard for third parties to sustain interest if it was a known risk that MS would rewrite whatever they were contributing.

I think you're spot on about the ecosystem being as important (or even more important?) than the core technology, and I'd love to hear peoples' thoughts on how to encourage such an ecosystem.

Couldn't they just submit patches (even if they were large ones) rather than truly rewriting under the MS banner? That seems like less of a risk to me. If an open source community is happy with their D code (to make a huge generalization), that's their prerogative.

What are some of the libraries you're thinking of?

I'd like to see them to roll their own identity platform after IdentityServer went close source.

Identity server is still open source, it just has a much more restrictive license and is paid.

https://github.com/DuendeSoftware/IdentityServer

ok, not closed, but restricted use. I think Microsoft should do (or buy Duende) their own platform. I've swapped to using keycloak, which is really nice, but it's a whole different world than .net

That's not open source. The term "open source" (in the context of computer software) refers to a specific set of criteria (with some disagreement on philosophy and minor details[1][2][3]) that include the right to modify, redistribute and to use for any purpose. The term originates from the open source movement which branched off from the free software movement.

If open source meant simply that the source code is available, Windows would also have to be considered open source, as Microsoft makes the code available to some of its customers. This is not how the term is generally understood.

[1] https://www.gnu.org/philosophy/free-sw

[2] https://opensource.org/docs/definition.html

[3] https://www.debian.org/intro/free

IdentityServer is still Apache 2.0, that has not changed.

Who is "them"? Microsoft? https://docs.microsoft.com/en-us/azure/active-directory/deve...

that lets you connect to identity platforms.

I agree. However a very difficult space. From one side they have commercials offerings (Active Directory and the variant within Azure). On the other the identity and authorization space has dozens of standards and the security space is changing primitives every day. It is extremely expensive and is permanently blocking resources from doing other things. That is also the reason IdentityServer is now under commercial license.

.NET already has an identity platform (ASP.NET Identity) that provides authentication/authorization with various backends. IdentityServer is a token server that speaks OAuth/OIDC and provides federation to other user directories (ASP.NET Identity or Azure Directory or anything else).

IdentityServer4 is still open-source and available. There's a new version by Duende with commercial licensing, or various alternatives like OpenIddict [1]. OAuth/OIDC is a well-supported standard so you can also use servers in other languages like Ory [2].

Microsoft's team did consider making their own token server but there was considerable pushback from the community because it would have a negative effect on open-source, and wouldn't add anything new compared to existing projects while taking resources from other framework features.

1. https://github.com/openiddict/openiddict-core 2. https://www.ory.sh/open-source

IdentityServer is not closed source, it is still Apache 2.0.

The Confluent.Kafka one, the AWS .NET SDK (though this is improving), the old MySQL one was really bad.

My impression from reading the code and GitHub issues is that they're not maintained by real ".NET people" who are plugged in to all the fine details and best practices of the framework and the runtime.

StackExchange.Redis is a good example of one that is independent of MS but still very high quality.

I'm the author of what you might call the "new" MySQL ADO.NET library: https://github.com/mysql-net/MySqlConnector

I agree with your impression that developers of the other library don't seem to be "plugged in to" the .NET ecosystem. As an independent developer (not affiliated with Oracle or Microsoft), I've been able to influence GitHub PRs that shape the ADO.NET API for .NET 6.0, just by showing up and contributing; I haven't seen anyone from the Oracle MySQL team participating. Meanwhile, they violate basic principles of the .NET Framework Design Guidelines that have been around for over a decade (https://docs.microsoft.com/en-us/dotnet/standard/design-guid...), which makes their library feel alien to a .NET programmer (regardless of the quality issues it might have).

Yeh I should have mentioned MySqlConnector as another example of a high quality .NET library, my apologies.

We ripped out the Oracle MySQL library at work and put MySqlConnector in. The high quality documentation made it really easy to understand and make adjustments for the differing behaviors between the 2 libraries. Any time I've poked into the code to try to understand some fine detail of it, I've always found it very easy to quickly understand what could be going on. It's great.

There’s work beyond the runtime, too.

They wrote a gRPC library [1],and a high performance JSON library [2]. Granted, these are .NET libraries, but still.

[1] https://github.com/grpc/grpc-dotnet [2] https://docs.microsoft.com/en-us/dotnet/standard/serializati...

A lot of the library ecosystem still feels dominated by companies who make their money selling library code. If more successful, open-source friendly companies adopt .Net to create higher-level products and services one would hope that would help contribute to a more well maintained and more friendly licensed ecosystem.

My sense is that things are improving though.

I'm not entirely sure where you get that 'feeling' from if you work on anything .NET related. If you're on the outside looking in, there's 270,000 packages listed on NuGet.org

That's progress, but it's also about the same number as maven central had in 2010.

I took the reply to mean that from the outside the sheer number of Nuget packages looks encouraging, but the situation from the inside is different. Although it reads a bit ambiguous.

dotnet ecosystem is.. I think it's coming along, but there are some quality gaps in certain areas that are odd compared to say Python or Golang. dotnet is MS baby so you would think there may be official SSH and WinRM libraries? Not so fast. There is a community SSH lib now that is looking good is has been active, but nothing from MS as far as I can tell. WinRM? I THINK the powershell project has this functionality inside it but it's nothing official that's published separately.

I'm planning on starting an OSS project using dotnet in the fall that is very system oriented so libraries like these are important to me. Also keeping an eye on asp dotnet, blazor, and etc.. Been lurking dotnet for over a decade.

This is not a MS project, but this thing called Hot Chocolate here (https://github.com/ChilliCream/hotchocolate) is very incredible. It is the best GraphQL framework I've worked on with excellent /EF(core)?/ support (even better than that of Hasura and dgraph) on the .NET ecosystem and overall software engineering. Maybe I can even swap the data source out with MongoDB as well, since it actually accepts IQueryable as the resolver source.

.NET is so incredibly underrated...

IIRC correctly, you may run into service scope issues if you just use a Mongo collection as an IQueryable directly, but there is a first class integration for Mongo from Chillicream: https://chillicream.com/docs/hotchocolate/integrations/mongo...

Agreed. It's ridiculous that .NET still doesn't have XPath 2 support after so many years. I really wish they'd hire a PM with enterprise experience, as they seem heavily focused on public facing web technologies e.g. the new native JSON serializer has all kinds of weird limitations based on 'security risks' that don't actually exist outside of public facing websites.

XSLT/XPath/XQuery 2.0+ has little first party support in general, in all programming ecosystems that I can think of. I think the problem is that it's all much more complicated than the originals, and meanwhile XML has become legacy tech - not that it's going away anytime soon, but it's kind of like the COBOL of data.

.NET caters to the enterprise, or at least it used to. It's irrelevant what other ecosystems prioritise. What makes you say that XML is legacy tech? In the financial industry XML is used extensively. For example, FpML underpins a massive part of global finance, and it is a regularly updated standard. COBOL has been superceded by other languages; I'm not aware of any technology that can replace the XML-based FpML schema.

> .NET caters to the enterprise, or at least it used to.

.NET is for enterprises who don't treat tech as frozen in time the instant it gets adopted now.

"Legacy" is perhaps not the best word to describe it; what I mean is that new technologies, protocols etc being developed generally avoid XML. So new products and libraries don't have to deal with it that much. And older ones are already written relying on older versions of XPath etc, so there isn't a strong incentive to upgrade there. Even if we're talking about libraries that are still getting updated to reflect changes in the standards.

The comparison with COBOL is fairly straightforward. There's still plenty of COBOL code running in prod around the world - but you don't see much clamoring to add new features to it.

Oh, and .NET doesn't really cater specifically to the enterprise these days. It was definitely true back when it was first released (remember all the emphasis on SOAP?), and for a while after. But .NET Core was an attempt to broaden its scope, and it very much succeeded.

I should add that I'm not particularly happy about this. I did a lot of XSLT 2.0 and XQuery 2.0 back in mid-00s, using Saxon, and I still miss many aspects of it. The new "best thing" seems to be JSON, but, while the syntax is certainly nicer, the tooling ecosystem around it is still nowhere near what we had back then.

The .Net road map has been incredible for us. We have carried the same product across 7 different major framework upgrades, 3 of which were the old school windows only variant.

I don't know of many ecosystems where backwards compatibility is this good while also providing tons of upside on the future path.

We are definitely getting more out of the Microsoft stack today than we thought we would 8 years ago when we started this journey.

If you told me our product would magically become cross platform capable while we were still sitting on 3.5 I would have laughed you out of the room. Granted, the conversion to .net core wasn't entirely painless, but it wasn't bad either.

For those who haven't already made the jump to Linux in production:

There might also be significant performance improvements to gain by chnging to Linux, especially on startup time (this is true for Java and Node as well and in my limited tests it was absolutely true for dot net core a couple of years ago.)

Congratulations! .NET is increasing the lead. It was already (generally) faster than JVM. One thing that I find really crucial is the COLD START times, this is a super important factor when using .NET as a primary platform for FaaS (Serverless Architecture), like Lambda, Azure and Google Functions. I think that's an important characteristic of languages VMs for the next years.

Some very nice improvements! I hope that this trend with focus on performance continues in the future and that NativeAOT becomes first class citizen soon.

Becomes again, Native AOT is the only way on WinRT since Windows 8, but has been stuck in C# 7 and .NET Standard 2.0, which contributes even more for the little love UWP still has.

Not just stuck - it was buggy and poorly maintained. We were forced to switch to Desktop Bridge after dealing with all the UWP performance and productivity crap and constraints just to have .NET Native one day stop compiling things right and leaving us stuck.

UWP was doomed to fail from day 1 because of how it was tight to UI framework and distribution model. Having a separate, incompatible implementation of the .net framework was another big smell.

If I remember correctly, WinRT doesn't use Native AOT. Native AOT has never been released before, and to me is the most exciting feature since generics in .Net 2.0 (circa 2005).

It will be interesting to see how well trimming and AOT (closely related technologies) turn out. I’ve already been able to build useful trimmed self-contained CLI apps with .NET 5 and 6, and based on what I’ve seen of NativeAOT I think it’d work for those.

OTOH things get dicier the further you get away from the core .NET libraries, and some of the enabling technologies are so new that they haven’t seen much adoption yet (example: the venerable COM interop system vs the new ComWrappers).

If you’d like to keep up to date on NativeAOT, Andrey Kurdyumov is doing some top-notch work in the area: https://codevision.medium.com/

In the next C# version, you don't need to use brackets for namespaces anymore. Just write

namespace Honlsoft;

and that's it.

I've been wishing for that for so long. The current state of nested code is so ugly in my opinion.

Now they just need free functions without a static class...

seems you want top level programs

The problem with .NET Core is that while the runtime is truly multiplatform, the development experience is not.

The performance improvements on each release are trully impressive, but I think at this point the focus should go towards a better development experience.

Developing on VS Code is such a hurdle thanks to the Omnisharp language server that constantly crashes, and the project does not seems to be among MS top priorities for .NET platform.

Restarting the IDE every few minutes is very frustrating and hardly justifiable from a productivity point of view.

You don't have to restart the IDE. Usually you can just tell Omnisharp to reanalyze your solution and wait a few seconds for that to complete. If Omnisharp has actually crashed, this will start up a new instance, too.

It would definitely be nice if more resources were put towards making Omnisharp smarter and more stable, especially as it seems to be the premier implementation of an LSP server.

Even that does take a huge amount of time in our solution which is around 300kloc

Agreed that OmniSharp is inexplicably terrible. But Rider is a very good cross-platform alternative.

JetBrains Rider is an amazing cross-platform IDE for .NET, with many more features than VS Code.

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

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.

What ever happened to IronRuby?

It hasn't been updated in 10 years and IIRC, Microsoft even hired the creator of IronRuby.

Is anyone running a Ruby on Rails app on .NET Core? If so, are you using IronRuby or something else? The folks at https://www.discourse.org know .NET super well from there StackExchange days - is Discourse a vanilla RoR app are they using the .NET runtime?

Impressive work (and blog post)! Somebody noticing real world performance impact after upgrading to latest .NET Core versions?

Microsoft did - in both Azure AD [1] and Bing [2],[3]. 1 and 2 from .NET Framework to .NET Core, but [3] is to .NET 5.

[1] https://devblogs.microsoft.com/dotnet/azure-active-directory... [2] https://devblogs.microsoft.com/dotnet/bing-com-runs-on-net-c... [3] https://devblogs.microsoft.com/dotnet/migration-of-bings-wor...

Saw impressive performance jumps on a full Core 3.0 -> Net 5 upgrade in 2020.. looking forward to testing out 6 (post preview).

and we're stuck with Java. Sad, I hope that bigger companies and startups choose to use .NET for the future. I love it but can't it seems like 80% of the big tech companies here are using java

I like the uniformity of Java language. I like the "inner class" feature that has to be manually emulated in C#. I also like that I can implement anonymous abstract class-interface ad hoc in Java. I wish that internal visibility in C# was tied to a namespace instead of assembly, like package visibility in Java. Method co-/contravariance in C# is tied to interfaces. I prefer it tied to individual methods, like in Java.

Yes, Java is more verbose to write, but it's easier to read. E.g., == in Java is always built-in equality. In C# it can be overloaded. Equality in C# is a mess (IEquatable, IEqualityComparer, the obscure way in which generic collections "discover" equality on the type...)

Then async/await hack and how it interoperates with Task infrastructure. It's so badly documented it's not even funny. An often-asked question is how to synchronously wait on an async method. The usual answer is "don't do it" like it solves anything. But async methods return a Task and the official examples for tasks tell you explicitly to use Wait() method to wait on a task. Which gives?? (A long story about synchronization context.) Java and Project Loom are doing it right, IMO.

Nullable reference types are another hack. I tried to convert a project to NRTs and gave up, reverted everything. I haven't seen a NRE in years :p NRTs introduce a lot of edge cases, with a lot of syntactic noise to cover them and still guarantees nothing (unlike a proper Optional type would).

Java takes longer time to push out features, but my impression is that when they do, the features are better thought out than their counter-parts in C#.

So right now the only thing I'm unhappy with in Java is streams not supporting checked exceptions. I actually _like_ them and Oracle should have invested in making them more usable in some way. What they did with streams kind of signals that they want to deprecate them in the long run. It's a missed innovation opportunity.

>In C# it can be overloaded.

I know it only confirms your point, but Rider highlights the overloaded operators so you spot them right away.

After working with dotnet for pretty long time and coming to Java world (mostly Spring with Kotlin), I was extremely disappointed to find there's no real alternative to LINQ. What's your solution to this common problem: you have a table (HTML table) with 30 different filters, you need to apply all of them if they're set. Some filters require simple field comparisons, and some filters add very complex conditions.

With LINQ and EF, it's very easy to do, and the result is clean and easy to read. I don't think there's any alternative in Java that does not require adding yet another library and re-implementing data access layer, or writing a lot of boilerplate.

> With LINQ and EF, it's very easy to do

I know of LINQ, but what's EF?

EF is ORM, basically wrapper over communication with database

It really, really speeds up the work, but there's a lot of to learn about how does it work, its limitations and conventions

EF = Entity Framework. (1)

It's an ORM (Object-rational Mapper) for querying SQL databases into objects. Somewhat the same space as "Hibernate" in Java. (2)

Some prefer e.g. Dapper (3) as it's much more light-weight. EF is very much a big thing, but some people need and want that.

1) https://docs.microsoft.com/en-us/ef/

2) https://hibernate.org/

3) https://dapper-tutorial.net/

Don't get me started on EF/EFCore. Using it in a large project is _the_ technical decision I regret the most. As for Java, I wrote a mini-ORM in a week. No big deal. And then I can use SQL as it was intended. EFCore dumbs down the database to being a stupid object store.

> An often-asked question is how to synchronously wait on an async method. The usual answer is "don't do it" like it solves anything. But async methods return a Task and the official examples for tasks tell you explicitly to use Wait() method to wait on a task.

This is mostly the fault of the TPL documentation being written eons ago. I'd recommend David Fowler's async guidance for a modern take: https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b...

`.GetAwaiter().GetResult()` is generally considered the best way to do it if you must do sync over async, but in modern code it should almost never be required.

> I tried to convert a project to NRTs and gave up, reverted everything. I haven't seen a NRE in years :p NRTs introduce a lot of edge cases, with a lot of syntactic noise to cover them and still guarantees nothing (unlike a proper Optional type would).

I've been working on updating a number of libraries to support NRTs with success. I find it's a good for developer ergonomics so you know what can return/be null and what cannot without needing it laid out within xml comments or documentation. ASP.NET Core 5+ will also automatically validate request payloads depending on a type being nullable or not. NRTs will be enabled in project templates by default with .NET 6.

> I'd recommend David Fowler's async guidance for a modern [...] .GetAwaiter().GetResult()

Yeah, you should add to that `ConfigureAwait(false)`.

That you need a long webpage about `async` and that the official documentation on Task doesn't apply kind of drives the point home. They've botched the design of async. Yes, it works "well enough" in 95% of cases, but the remaining 5% is a mine-field.

> (...) What they did with streams kind of signals that they want to deprecate them in the long run. It's a missed innovation opportunity.

Do they? They kept evolving the Stream API after Java 8 well into Java 16 (Stream::multiMap, Stream::toList, etc.), it doesn't really seem to me like this is true.

"them" refers to checked exceptions.

As a counter example: As someone that worked for years in .Net and started trying to develop some projects in the Java ecosystem... what a fucking mess.

Days of work to try and get projects to BUILD. Do I have to use Gradle, Maven, or something else? Which IDE to use? The IDE isn't working with whatever version of Gradle or Maven I'm using. Dependency hell. Restarting my IDE repeatedly, re-downloading dependencies, trawling through the horrible Maven site trying to work out what version of a certain dependency I need. Keeping massive amounts of notes because I'm sure in two weeks I'm going to forget which arcane command I need to keep my Java build environment working.

The horrible verbosity of Java making it way harder to read then C#. Realising that there's no standard equivalent of tasks and async and I have to work out which of the 10 3rd party implementations is the "good one" and then realising that the recommended one is again verbose, ugly, and more complex to write and understand than Tasks and Async in .Net.

Having to work out which Java runtime environment I need. Having to register on the Oracle website to download their runtime, then finding out that maybe an open source runtime is better, then finding out nothing is supported for ARM macs. Then realising that this runtime means my IDE ends up breaking. Multiply all these problems if you decide to write Scala instead.

The Java and JRE environment in general is a huge mess in comparison to Microsoft's .Net platform. .Net "just works." There is no confusion of how to build, what IDE to use, what package manager, everything works together seamlessly. I can get a new engineer setup to write and deploy .Net in minutes. Our company literally has to have three engineers gather around someone's computer for half a day to get a Java or Scala environment working correctly and often it ends up working seemingly by magic, i.e. we can't deterministically understand why it ended up working.

Java was actually my first programming language in college but Oracle has radically mismanaged it. I would not recommend it unless you really need some specific library that only exists in the Java ecosystem.

Oracle has done wonders for Java. It has kept it from languishing like it was under Sun.

Most of this just sounds like complaints from someone who doesn't know the ecosystem and doesn't want to learn it. Someone who thinks your choice of IDE matters for a project, when in fact it doesn't.

> Keeping massive amounts of notes because I'm sure in two weeks I'm going to forget which arcane command I need to keep my Java build environment working.

    gradle build
    mvn package

> Having to work out which Java runtime environment I need

Do you not have to figure out which version of .net core, .net framework, .net whatever for each project?

> Having to register on the Oracle website to download their runtime,

    brew install openjdk@<YOUR_VERSION>

> I can get a new engineer setup to write and deploy .Net in minutes

Here's what I do, and it takes 3 minutes:

    my_package_manager install openjdk_version_i_need
    my_package_manager install maven
    my_package_manager install vscode
    code --install-extension vscjava.vscode-java-pack
    code /path/to/the/project

> recommended one is again verbose, ugly, and more complex to write and understand than Tasks and Async in .Net.

This is probably your only valid criticism until Loom is launched.

I use eclipse. Never had problems with it. As for building, I figured out how to use maven to download dependencies to a separate folder and then I use eclipse features to add jars to the project. (Eclipse has maven plugin, but I couldn't get it to work. Something or else made trouble, so I gave up.) Quite pleasant setup.

> Realising that there's no standard equivalent of tasks and async

There is: Executor and CompletableFuture.

Where should someone start if they wanted to get familiar and proficient with .NET?

For somebody who already knows how to program, and enjoys getting a comprehensive data dump, C# 9.0 In a Nutshell.

Yes, it's a truly fantastic book for beginners and veterans alike. It's too big for most people to read cover to cover, but as a reference book it's invaluable (and much better than C# in Depth IMO). It covers just about everything in C# and is remarkably up-to-date.

Joe Albahari has had to work with just about every feature in C# (he's the author of LINQPad) and it really shows in the book.

c# in Depth (4th edition) is also a good book for data dumping how things work in c#, though I think it only covers through c# 8.

I'm not a big fan of C# in Depth as a reference book. It follows a very chronological path (here's what was introduced in .NET Framework v1, here's what was introduced in version 2...), which can be interesting but I don't think it's a useful framing for most people.

There is so much to it that you have to pick where to start. If you have never done C#, definitely start there. But then you can branch off to web development, service development, back-end data access development, and much more.

This YouTube channel is pretty good.

https://www.youtube.com/user/kudvenkat

Install the SDK. Open a terminal, create a folder and run "dotnet new console" inside it. "dotnet run" (prints Hello world) then start playing around by adding code to Program.cs.

https://dot.net

Check out F#, the bastardized yet legitimate child of MSFT.

If you like functional languages or would like to try it, give it a whirl!

https://dotnet.microsoft.com/learn/languages/fsharp-hello-wo...

If you use vscode, highly suggest to use Ionide extension. You’ll be quickly amazed at how smooth it all works.

F# is cool, but definitely not where to start. C# is by far, by far, by far the most popular .net language

Depends on what OP is familiar with. If they know/like functional programming, I'd recommend F# highly. If not... Yeah go with C#.

Then later learn F# because it's absolutely kick ass :)

An experienced functional programmer can learn F# in a minute, which is fine for console programs. But I tried to write a basic GUI program in F# on Linux and gave up after I reached my googling limit.

Have you tried https://github.com/fsprojects/Avalonia.FuncUI?

To add to the other comment, how about Fabulous?

https://github.com/fsprojects/Fabulous

C# is more popular but actually harder to learn IMO (although this does depend on your prior experience). C# is huge, but F# achieves more with fewer language constructs. F# can also be transpiled to JavaScript, which is a huge advantage.

I love F#, it's my #1 favorite language by far. But I code in C# at my day job and I gotta say, while I haven't exactly kept count, it's hard for me to agree that F# has fewer constructs. To be fair, much of that comes from the fact that F# has to do nearly everything C# does for compatibility, and have its own stuff too. It leads to a lot of "wait, which tool do I use for this problem?" questions for newbies.

* [<Extension>] methods vs `type X with member ...` extensions

* let-bound functions vs static methods vs instance methods

* operator overloads vs let-bound operators

* curried functions vs multi-parameter functions

* modules vs static classes

* `exception MyError of string` vs `type MyErrorException(msg) inherit Exception(msg)...`

* polymorphic data: interface vs abstract class vs discriminated union

* Async vs Task

* seq { ... } computation expression vs chain of Seq module operations vs. LINQ methods

* Option vs Nullable vs Result

* Statically resolved generic vs runtime generic (`^a` vs `'a`)

* `for i = 0 to 10` vs `for i in 0..10`

* `upcast` vs `:>` and `downcast` vs `:?>`

* `function` vs `fun x -> match x with`

* .fsi files and the syntax for declarations in them

* `let mutable` and `<-` vs `ref` and `:=`

* sprintf vs interpolated strings with "%d"-style format specifiers vs interpolated strings with FormattableString format specifiers vs String.Format

* Code quotations vs linq-style Expression<Func<...,...>>

I am very comfortable with F# today and feel I have a solid grasp on how I like to do things. But when I was introduced to it, I was a little overwhelmed, even though I already had familiarity with C# and with Haskell.

This is a fair point! Although I was more talking about the language constructs that are used for 90%+ of code, which from my own experience is:

  * let
  * discriminated unions
  * records
  * lists
  * seq
  * async
  * fun

Like all languages people actually use, F# has a long tail of advanced features!

I'd also argue that C# is a worse language to start with than F# if you're coming from Python.

.net is very easy, I have more than 11 years of experience in .net doing gaming and web development and believe me is a very easy language with a very powerful ide and a lots of documentation.

If you want to write a game, there’s Unity.

Or you could make some kind of REST API with ASP.NET Core or gRPC.

Hi, I'm on the .NET community team. Here's what we see as the happy path for .NET:

- .NET website (https://dot.net) - High level info on different workloads, 5 minute in-browser tutorials, links to live shows and community

- MS Learn (https://aka.ms/mslearn-dotnet) - Interactive tutorials with learning paths built from 30ish minute learning tutorials

- Docs (https://aka.ms/msdocs-dotnet) - More in-depth documentation on specific tasks and features, e.g. API documentation, performance optimization, security guidance, etc.

While you can go directly to any of them, the dot.net site will link you to Learn modules that will link you to docs, so hopefully you can start on the dot.net site and it will help you find the right place.

One thing I really like (and I'm totally biased because I've helped set it up) is https://live.dot.net. Those are all our live shows with the PM and dev teams. We've got a show every day of the week, and there's always really good Q&A in the chat.

Hey, thanks for your work, love .NET.

I guess this is as good of a chance as I'm gonna get - the docs experience in non-anglosphere countries is dreadful, the website keeps pushing a localized version with absolutely garbled machine translations which are never going to be even passable for technical documentation. It's just a completely miserable experience without the "FFS MSDN" browser extension.[1][2]

At least that was the situation a year or so ago - all my computers are now 100% English locale so I have no quick way to check.

Just let us use the website in English.

[1]: https://addons.mozilla.org/en-US/firefox/addon/ffs-msdn-in-e...

[2]: https://chrome.google.com/webstore/detail/ffs-msdn-in-englis...

Hah, I hadn't realized there was a dedicated browser extension for this. I've been using the Redirect plugin for Firefox to regex-rewrite the URLs - because obviously, the machine translated documentation is useless at best (and harmful at worst).

Indeed ridiculously annoying though. For some reason, Google also started to show the titles of English-language YouTube videos in machine translated German for me, usually completely garbling the meaning - and the video is in English anyway! It's not like I could watch it if I didn't already understand the original title!

Who would have thought that managers in primarily monolingual cultures (i.e. the US) don't understand the actual needs of an international, polyglot audience? The techbro-ism behind these decisions is palatable. "That's a technological solution to what I, without actually asking any of the people affected, imagine to be a problem, so it must be good, right? I mean, it has ML?"

Thanks for letting me know, I'll check in with friends in docs and try to get this sorted out. Sorry for the frustration.

Anyone using .NET for cross-platform desktop development, like Avalonia?

Reply on news.ycombinator.com