I’ve been a C# developer for two (almost) decades, how do people even keep up with these rapid changes in the post Core world and what/when to use them? This is a serious question by the way.
I've honestly given up. The new "open" development style of .NET Core is not my cup of tea. It's now riddled with MVP features that are 80% complete, bug-ridden, and undocumented other than couple of blog articles.
The compatibility break with the .NET Framework also removed the biggest advantage I saw in C#, which was that any code that I wrote would "just work". Now there's more frameworks, standards, cores, and build flags than I care to learn, and there are all too many scenarios where it's flat impossible to do something that was trivial before.
This is the reason, for example, that PowerShell Core is past version 7 but is still missing many modules, including some key Microsoft ones. If they can't figure this out, what chance do I have? Why would I bother?
Lastly, I got fed up with Microsoft releasing yet another half-baked GUI framework. What's the latest one? MAUI? It's yet another attempt at having one framework to rule them all, which means that it'll inevitably be the lowest common denominator and not good at anything. Microsoft won't actually bother making it good enough to write a flagship application in it, and they won't write any of their own apps with it. It'll be dropped on the floor and replaced by the next incomplete GUI framework within just a few years, mark my words. That's if it's ever finished!
> The compatibility break with the .NET Framework also removed the biggest advantage I saw in C#
I'll be honest here. The migration from .NET Framework to .NET Core is a pain. I see why things were done the way they were done, but it's still a real pain.
That said: for green-field works NET Core is clearly superior.
> PowerShell Core is past version 7 but is still missing many modules, including some key Microsoft ones
Just like .NET Core's main mission was not to replace the entire .NET Framework, the same applies to PowerShell Core.
.NET Core was created to make developing .NET-based web/cloud-services easier, faster, using less space/resources at runtime, and to have a fully supported cross-platform story. And at that it has been a wild success.
Almost everything about .NET Core is better to work with than the traditional .NET Framework (at least for the workloads it was intended for), and I'm always depressed when I have to move back to work on the "old" stack.
In this regard PowerShell Core is (as I see it) not meant to fully replace regular PowerShell either, but to be a good platform to do your cross-platform dev-ops'y build and deployment scripts related to your .NET Core deliverables.
It may not be what you want it to be, but it has a clear mission, and it's delivering fairly well on that.
> Lastly, I got fed up with Microsoft releasing yet another half-baked GUI framework.
I think this applies to pretty much everyone, which is why they never catch on, and Microsoft inevitably trying to "solve" this by releasing yet another framework.
That said the MAUI-presentation on this year's Build looked pretty convincing. If I had time to spare and had some small projects/POCs I had to work on, I might had given it a spin.
The actual issue is this new Microsoft full of half-done projects and trying to reduce engineering costs. They even try to make others write the documentation for their products... MSDN is gone and now docs are a mess.
Ballmer was a mess, but at least he got the devs-first bit right. Nowadays it is devs-last, cloud-first.
>The new "open" development style of .NET Core is not my cup of tea. It's now riddled with MVP features that are 80% complete, bug-ridden, and undocumented other than couple of blog articles.
.NET Framework is a product, .NET Core is a OSS project.
When .NET 5 will ship it will be even worse since .NET Framework people will just expect things to work.
Everything is optional, you can still code in C# like you did years ago and there's nothing wrong with it.
I look at the new things and take what I like. For example I particularly dislike the async / await paradigm so I still use background workers (and they work absolutely fine for my needs).
Linq is sublime (I know it's already "old") : I wasn't convinced at first but now I wonder how people in other languages manage without it !
Some things are just syntactic sugar but are very practical : the ?? and .? operators, new MyOjbect { Property1 = 15}; etc etc
I'm sure there are a lot of things I don't know about the language but it's fine, i will find it when I need it.
Last week I needed to define a method body at the creation of the object and not in the class. After some lengthy googling because I didn't know how to put words on what I was looking for, I found that C# had Func and it solved my problem beautifully.
This is about being able to use the language/framework you already know to compile to pure native binaries (like Rust, but with GC). It's a big deal since it makes C# viable in places where it isn't currently, like a lot of Go's use cases.
I had been away from C# for nearly 6 years, but was able to pick up Core in a couple of days. If anything, things have gotten simpler and there's fairly good cross platform support. What rapid changes are you referring to?
C# has long supported it on UWP side, but now with .NET 5 there is an ongoing discussion if they will still support it or not.
The whole MDIL (Windows 8/8.1) and .NET Native (Windows 10) came from WinDev, not DevDiv, hence why it has its own idiosyncratics regarding .NET support.
Now with .NET 5, it seems they are gearing towards just a better NGEN, thus shipping a kind of AOT/JIT mixed mode image, which isn't being that well received and most likely the survey to feel the community.
That was a requirement twenty years ago when the framework wasn't bundled in the operating system and download speeds were much slower. It's really a non-issue now.
Although I don't identify with the "fire" part of that analogy, I agree it seems excessive to keep up with all the fine technical details of new features.
Programming language improvements can, at best, give us small decreases in accidental complexity.
Good software engineering practises (ruthless prioritisation, proper modularisation, continuous integration) etc. can have huge effects on both inherent and accidental complexity. It is much more important to spend time on those things. They are independent of specific programming language features.
Keep in mind that, although I partially agree with you, other platforms are way-worse than .NET. think about nodejs mess and client-side ecosystem, where things break almost at any minor release.
Dev world is going fast, and I think that the choice for .NET is to embrace change or die as an old platform.
My2Cents.
Your comment about the JavaScript client side ecosystem is fair, and I could even provide numerous examples of libraries introducing breaking api changes in minor releases.
However it is unfair and simply untrue to somehow also tar nodejs with that brush. Upgrading a nodejs project by a major version usually never needs any code changes
> how do people even keep up with these rapid changes in the post Core world and what/when to use them?
You wished that the dev world moved slower. Sorry, things move fast nowadays. The .NET team decided to stay relevant, by moving fast to keep up. That's just how it is.
As a desktop developer I really miss the Big Bang releases and slow pace yes. We are doing a 2-year transition between 4.7.1 and 4.7.2 now! What goes on beyond that is just a fog. Some of our third party dependencies are probably never going to be ported core while many others are starting to lose maintenance on netfx. Being in the position of having to maintain a netfx desktop app for the coming 10-20 years is looking bleak.
For the new language feature is usually look them up when there's a new release and try to use them in any new code I write. And since I'm a resharper user, it usually suggests code rewrite using new language features.
Asides from the obvious blog posts, Microsoft hosts many events such as Microsoft Ignite, where companies often send a couple of developers to get up-to-date with what is going on in the MS world, C# included.
another lazy "developer" who can't keep up with the newest trends. Real developers are working 365 days a year, around the clock, and don't waste time with girlfriends etc... You will never be one of them.
I don’t think anyone does. I think greenfield projects use the latest version but existing projects just stay where they are barring critical issues. I know my company is still on .NET 4.6 and has no plans to migrate to .NET Core 2 Duo.
Why should they, IL2CPP and Burst compilers is able to do C++ like optimizations that .NET is still far from being able to (they have actually two nowadays).
.NET 5 also doesn't run in all platforms that Unity targets.
Rich ecosystems only have to gain from multiple implementations.
> IL2CPP and Burst compilers is able to do C++ like optimizations that .NET is still far from being able to
This is a discussion about .NET AOT (CoreRT) which has been observed to have a considerable performance benefit over IL2CPP/burst (see the attached blog post in my original comment)
> .NET 5 also doesn't run in all platforms that Unity targets.
CoreRT supports C++ codegen, so in the worst case you can use that. But its first class platform support is growing. Though I suspect even then you may see some platform support differences but those can be ironed out. Given the benefits of switching to .NET CoreRT I suspect it would be worthwhile.
I built a high end desktop after exclusively using desktops for a decade because Unity WebGL builds are so awful. It is the slowest, most opaque and buggiest build chain I have used since I made Flash games.
I expect it would replace the need for the burst compiler, and likely reduce the complexity of the job system (especially its need for special types.) There is also an observed performance gain switching from IL2CPP to CoreRT, which would be 100% free.
Unfortunately reflection is so widely used in .Net libraries and core frameworks that code removal during linking becomes more or a less impossible without spending A LONG TIME decorating an xml file with code removal exceptions. I have done it on Xamarin iOS, it is not fun. So one of the prime dreams of having .net AOT of having an easy way to create a COMPACT self contained native exectuable dies when it hits real code.
Source generators may solve that going forward, but that is going to take years to filter out to nuget library land.
There are other advantages of AOT, sure, but I think R2R that is in .Net already covers a lot of those.
They need to solve the poor linkability of .Net code first IMO. I think Microsoft realise that, especially if they want Blazor client side to work.
> So one of the prime dreams of having .net AOT of having an easy way to create a COMPACT self contained native exectuable dies when it hits real code.
Reflection is not "unfortunate". Actually, it is quite helpful when used right. And there is a way to shove it with AOT.
I've tried to communicate that to some team members but got the impression they weren't so interested in solving that. Or maybe they are reluctant to take a solution from 3rd party, preferring to quickly come up with in-house code instead.
Well, this would clearly cost them at least 5 years of R&D given they are able to find the right PhDs in math and compiler theory who are able to crack that.
As for source code generators as a way to solve the reflection dilemma: they are not going to make a dent as they tied to the specific language (C#), and not to .NET platform as a whole. This makes them somewhat fragile and largely fragmented in the eyes of component vendors.
> As for source code generators as a way to solve the reflection dilemma: they are not going to make a dent as they tied to the specific language (C#), and not to .NET platform as a whole.
Slight correction: source generators are a _compiler_ feature not a _language_ feature. This may seem like a meaningless distinction, but you can use source generators in _any_ C# project provided your compiler is new enough. You can easily use generators in a .NET 3.5/C# 5 project if you want.
Readit News
The compatibility break with the .NET Framework also removed the biggest advantage I saw in C#, which was that any code that I wrote would "just work". Now there's more frameworks, standards, cores, and build flags than I care to learn, and there are all too many scenarios where it's flat impossible to do something that was trivial before.
This is the reason, for example, that PowerShell Core is past version 7 but is still missing many modules, including some key Microsoft ones. If they can't figure this out, what chance do I have? Why would I bother?
Lastly, I got fed up with Microsoft releasing yet another half-baked GUI framework. What's the latest one? MAUI? It's yet another attempt at having one framework to rule them all, which means that it'll inevitably be the lowest common denominator and not good at anything. Microsoft won't actually bother making it good enough to write a flagship application in it, and they won't write any of their own apps with it. It'll be dropped on the floor and replaced by the next incomplete GUI framework within just a few years, mark my words. That's if it's ever finished!
I'll be honest here. The migration from .NET Framework to .NET Core is a pain. I see why things were done the way they were done, but it's still a real pain.
That said: for green-field works NET Core is clearly superior.
> PowerShell Core is past version 7 but is still missing many modules, including some key Microsoft ones
Just like .NET Core's main mission was not to replace the entire .NET Framework, the same applies to PowerShell Core.
.NET Core was created to make developing .NET-based web/cloud-services easier, faster, using less space/resources at runtime, and to have a fully supported cross-platform story. And at that it has been a wild success.
Almost everything about .NET Core is better to work with than the traditional .NET Framework (at least for the workloads it was intended for), and I'm always depressed when I have to move back to work on the "old" stack.
In this regard PowerShell Core is (as I see it) not meant to fully replace regular PowerShell either, but to be a good platform to do your cross-platform dev-ops'y build and deployment scripts related to your .NET Core deliverables.
It may not be what you want it to be, but it has a clear mission, and it's delivering fairly well on that.
> Lastly, I got fed up with Microsoft releasing yet another half-baked GUI framework.
I think this applies to pretty much everyone, which is why they never catch on, and Microsoft inevitably trying to "solve" this by releasing yet another framework.
That said the MAUI-presentation on this year's Build looked pretty convincing. If I had time to spare and had some small projects/POCs I had to work on, I might had given it a spin.
The actual issue is this new Microsoft full of half-done projects and trying to reduce engineering costs. They even try to make others write the documentation for their products... MSDN is gone and now docs are a mess.
Ballmer was a mess, but at least he got the devs-first bit right. Nowadays it is devs-last, cloud-first.
Even with its half broken implementations, .NET and Java are still the best options in tooling and managed runtime capabilities.
.NET Framework is a product, .NET Core is a OSS project.
When .NET 5 will ship it will be even worse since .NET Framework people will just expect things to work.
I look at the new things and take what I like. For example I particularly dislike the async / await paradigm so I still use background workers (and they work absolutely fine for my needs).
Linq is sublime (I know it's already "old") : I wasn't convinced at first but now I wonder how people in other languages manage without it !
Some things are just syntactic sugar but are very practical : the ?? and .? operators, new MyOjbect { Property1 = 15}; etc etc
I'm sure there are a lot of things I don't know about the language but it's fine, i will find it when I need it.
Last week I needed to define a method body at the creation of the object and not in the class. After some lengthy googling because I didn't know how to put words on what I was looking for, I found that C# had Func and it solved my problem beautifully.
I had been away from C# for nearly 6 years, but was able to pick up Core in a couple of days. If anything, things have gotten simpler and there's fairly good cross platform support. What rapid changes are you referring to?
The whole MDIL (Windows 8/8.1) and .NET Native (Windows 10) came from WinDev, not DevDiv, hence why it has its own idiosyncratics regarding .NET support.
Now with .NET 5, it seems they are gearing towards just a better NGEN, thus shipping a kind of AOT/JIT mixed mode image, which isn't being that well received and most likely the survey to feel the community.
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
Programming language improvements can, at best, give us small decreases in accidental complexity.
Good software engineering practises (ruthless prioritisation, proper modularisation, continuous integration) etc. can have huge effects on both inherent and accidental complexity. It is much more important to spend time on those things. They are independent of specific programming language features.
However it is unfair and simply untrue to somehow also tar nodejs with that brush. Upgrading a nodejs project by a major version usually never needs any code changes
You wished that the dev world moved slower. Sorry, things move fast nowadays. The .NET team decided to stay relevant, by moving fast to keep up. That's just how it is.
Be happy you are not a Rust developer then ;)
https://docs.microsoft.com/en-us/dotnet/standard/choosing-co...
C# 9 is next on the list.
Edit: interesting, someone wrote about this a couple years ago: https://xoofx.com/blog/2018/04/06/porting-unity-to-coreclr
I wonder if there’s movement on this internally at Unity.
.NET 5 also doesn't run in all platforms that Unity targets.
Rich ecosystems only have to gain from multiple implementations.
This is a discussion about .NET AOT (CoreRT) which has been observed to have a considerable performance benefit over IL2CPP/burst (see the attached blog post in my original comment)
> .NET 5 also doesn't run in all platforms that Unity targets.
CoreRT supports C++ codegen, so in the worst case you can use that. But its first class platform support is growing. Though I suspect even then you may see some platform support differences but those can be ironed out. Given the benefits of switching to .NET CoreRT I suspect it would be worthwhile.
I agree the the Users of Unity may or not see gains in the short term
Source generators may solve that going forward, but that is going to take years to filter out to nuget library land.
There are other advantages of AOT, sure, but I think R2R that is in .Net already covers a lot of those.
They need to solve the poor linkability of .Net code first IMO. I think Microsoft realise that, especially if they want Blazor client side to work.
They are working on improving that: https://github.com/dotnet/designs/blob/master/accepted/2020/...
I've tried to communicate that to some team members but got the impression they weren't so interested in solving that. Or maybe they are reluctant to take a solution from 3rd party, preferring to quickly come up with in-house code instead.
Well, this would clearly cost them at least 5 years of R&D given they are able to find the right PhDs in math and compiler theory who are able to crack that.
As for source code generators as a way to solve the reflection dilemma: they are not going to make a dent as they tied to the specific language (C#), and not to .NET platform as a whole. This makes them somewhat fragile and largely fragmented in the eyes of component vendors.
Slight correction: source generators are a _compiler_ feature not a _language_ feature. This may seem like a meaningless distinction, but you can use source generators in _any_ C# project provided your compiler is new enough. You can easily use generators in a .NET 3.5/C# 5 project if you want.
There's just easier languages to do it in if you really need AOT.
Dead Comment