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.
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.
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.
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.
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.
.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.
> 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.
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.
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....
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.
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.
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.
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.
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.
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.
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.
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.
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/
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.
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.
-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
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?
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.
[+] [-] smackeyacky|4 years ago|reply
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.
[+] [-] foepys|4 years ago|reply
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.
[+] [-] chunkyks|4 years ago|reply
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.
[+] [-] plasma|4 years ago|reply
[+] [-] phillipcarter|4 years ago|reply
[+] [-] throwaway13337|4 years ago|reply
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.
[+] [-] amezmo1|4 years ago|reply
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
[+] [-] joshuaissac|4 years ago|reply
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.
[+] [-] TriNetra|4 years ago|reply
[+] [-] FartyMcFarter|4 years ago|reply
Hasn't Mono existed since 2004? Any Unity game has been running C# on many platforms by using Mono.
[+] [-] VadimPR|4 years ago|reply
I'd recommend it to a Windows dev who wants to go crossplatform, but never to a crossplatform dev.
[+] [-] kumarvvr|4 years ago|reply
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".
[+] [-] 3np|4 years ago|reply
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....
[+] [-] oaiey|4 years ago|reply
[+] [-] ComputerGuru|4 years ago|reply
[+] [-] DoingIsLearning|4 years ago|reply
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.
[+] [-] ComputerGuru|4 years ago|reply
[+] [-] notanaverageman|4 years ago|reply
[+] [-] bobcostas55|4 years ago|reply
[+] [-] Foomf|4 years ago|reply
[+] [-] vp8989|4 years ago|reply
Would you rather have an A language/runtime with a D open source ecosystem or a B for both?
[+] [-] aoetalks|4 years ago|reply
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...
[+] [-] MikeTheGreat|4 years ago|reply
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.
[+] [-] stevefan1999|4 years ago|reply
.NET is so incredibly underrated...
[+] [-] Rapzid|4 years ago|reply
My sense is that things are improving though.
[+] [-] Merad|4 years ago|reply
[+] [-] ryanjshaw|4 years ago|reply
[+] [-] bob1029|4 years ago|reply
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.
[+] [-] eitland|4 years ago|reply
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.)
[+] [-] jfbaro|4 years ago|reply
[+] [-] zigzag312|4 years ago|reply
[+] [-] ripley12|4 years ago|reply
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/
[+] [-] pjmlp|4 years ago|reply
[+] [-] f32jhnjk33jj|4 years ago|reply
namespace Honlsoft;
and that's it.
[+] [-] Xevi|4 years ago|reply
[+] [-] woggy|4 years ago|reply
[+] [-] Lobosque|4 years ago|reply
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.
[+] [-] ripley12|4 years ago|reply
[+] [-] mjul|4 years ago|reply
[+] [-] coldacid|4 years ago|reply
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.
[+] [-] zija|4 years ago|reply
-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
[+] [-] xvilka|4 years ago|reply
[+] [-] alberth|4 years ago|reply
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?
[+] [-] azibi|4 years ago|reply
[+] [-] aoetalks|4 years ago|reply
[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...
[+] [-] gnabgib|4 years ago|reply
[+] [-] robertwt7|4 years ago|reply
[+] [-] zvrba|4 years ago|reply
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.
[+] [-] theshadowknows|4 years ago|reply