6 ms·

On the one hand it's cool that they are improving but how do people keep up with all these additions? I find this really hard. Seems a lot of the changes are

On the one hand it's cool that they are improving but how do people keep up with all these additions? I find this really hard. Seems a lot of the changes are new stuff which you have to evaluate and see how they could actually be used productively. For example a while ago I tried the new nullable stuff and while in theory it looks straightforward it turned out to be very difficult to use nullable with existing APIs and code in a productive way. The same applies to a lot of the other new features. I feel .NET Core after a good start is falling into the typical Microsoft trap of constantly cranking out new stuff to do the same thing and leaving it to developers to keep up. That's how we ended up with several .NET desktop UI frameworks that are more or less in maintenance mode without a real upgrade path to the currently fashionable framework (which will most likely be abandoned soon too).

rr888 4y ago
I think this is pretty common with a lot of legacy code bases in popular languages. Lots of big systems on Java 8, Python 2, we wont talk about JS. :)
hardware2win 4y ago
>On the one hand it's cool that they are improving but how do people keep up with all these additions? I find this really hard. Very often they improve things in a way that you'll get an improvement regardless of whether you are aware E.g linq, collections, regexes, etc.
pjmlp 4y ago
We don't really keep up. I read with interest all these articles, and then go back coding our LOB stuff in .NET Framework 4.7.2 and similar. On the Java side, I am finally confident that all our servers have at least Java 11 on them. Only on private stuff do I happen to enjoy latest versions.
jabart 4y ago
Nullable's have been around for at least a decade and before .Net core existed? Are you thinking of the NotNull attribute argument checking instead(Likely the wrong term here)? Any change in a data type to an existing API or code will always be tough and a lot of work. Maybe an in32 to a in64 being the exception. Library developers are looking at these and following them to make enhancements. Developers working on business apps get the automatic performance improvements of these changes and the library dev changes to improve performance and allocations. I personally quickly go over these so when I get into a performance issue I have a little bit to know where to go find more information.
- nightski 4y ago
  Pretty sure they mean Nullable reference types which are much newer (although they have been around for a while at this point).
  - spaetzleesser 4y ago
    Yes, that's what I meant.
ewjt 4y ago
Can you name other development platforms of similar scale/depth that don’t have this issue? Compared to the whirring treadmill of frontend web development, I find .NET to be pretty easy to keep up with. Good IDEs (ReSharper or Rider) really help with the new language features (which are opt-in). Outside of that, the ecosystem is large enough that there are quality blogs/articles/podcasts to stay current without sinking a ton of time into doing so.
- asdajksah2123 4y ago
  Front end development may have a lot of frameworks, etc., but so much less magic than .Net. What makes .Net so much harder (especially ASP.Net) are the new features but also all the magic that makes discoverability so hard. Front end frameworks tend to follow similar patterns, and where they differ, they usually advertise the difference between the standards heavily. But also, since they are genuinely different frameworks, it's easier to search the differences etc. So, if I open a Vue application codebase, I know almost immediately that it's a Vue application and not a React one. I can google vue and figure out (most likely from their getting started page) exactly all I need to know to get started. If I enter an ASP.Net codebase, on the other hand, I have no idea whether I'm looking at ASP.Net Pages, .Net WebAPI, .Net WebServices, or more often than not, some combination of all of them. Throw in some Dependency Injection, with a combination of IOC containers used in the same project, and it's a massive lift to know what even to Google for.
  - metaltyphoon 4y ago
    I hear this word all the time “magic”. Can you describe what it means with concrete example for other stacks?
    - cerved 4y ago
      Http request handling in asp.net mvc. The uri, type and parameter serialization is a magic mess. How do you PUT { "foo" : { "bar" : "baz" }} to ping/pong/yolo? You create a controller class, PingController, you create a method PutPong, then you give up and proceed to cry blood
bob1029 4y ago
I don't try to keep up with absolutely everything. I've been to this particular buffet for a really long time and have developed tastes for certain things. For instance, I recognize AOT is elegant in theory, but I also notice it's a difficult thing to get right and has certain tradeoffs. Especially, for a complex application that may need to use legacy APIs. As a consequence, I have mostly avoided this in favor of focusing on other areas that do seem to deliver additional value for our product (and my side-projects). Examples of these being intrinsics (SIMD), UTF8 text/serializer, file I/O and more advanced GC techniques. Ultimately, it's a matter of experience to know when you should and should not chase a particular rabbit. My general policy right now is to observe the new shiny while it's in the odd-version, and then wait to see how it shakes down by the time the LTS comes around. You almost never want to try to grab a Microsoft-branded rabbit upon the very first sighting.
francisofascii 4y ago
Fortunately the upgrade path has not been too bad once you get to .NET Core. Usually one time changes to your Program.cs and Startup.cs files. The Top-Level statements addition is pretty jarring at first, but a cool addition. I did run into a breaking change from .NET 5 to 6 with an Encryption library not working right. But most everything else just works when upgrading. If it was just .NET additions life would be fine. It is the front-end churn that causes real stress. AngularJS, TypeScript, Angular, React, Blazor, WebPack, Vite, etc.
bestinterest 4y ago
I very much like the ethos of Golang for this reason. Still not had a reason to use it but like the idea of mastering the fundamentals in a weekend. Even if I lose the flexibility of LINQ or Java streams. It feels like a scale of language conservativeness Go all the way at the top, Java somewhat in the middle (a little above) and C# at the bottom. It is going the route with lots of features and complexity, which can be a great thing but not for grug devs https://grugbrain.dev https://grugbrain.dev like me. But saying all that Blazor looks really good for WebDev, I just worry it gets abandoned. It feels everything does in the C# space. C# also made a big mistake imo by going with async/await instead of lightweight threads which will add a ton of complexity in the future for if they decide to go the greenthread route like Goroutines/Project Loom.
- keltex 4y ago
  > But saying all that Blazor looks really good for WebDev, I just worry it gets abandoned. It feels everything does in the C# space. I've been maintaining a asp.net (WebForms!) framework codebase for almost 18 years now. Running on the latest Windows Server and Visual Studio 2022.
- whoisthemachine 4y ago
  > C# also made a big mistake imo by going with async/await instead of lightweight threads which will add a ton of complexity in the future for if they decide to go the greenthread route like Goroutines/Project Loom. Could you expand on this? Async/await is just syntax magic for Task continuations (in other words, Promises [0]), which have very little to do with the underlying threading model. This statement is equivalent to saying "Completable Futures add a ton of complexity to Project Loom." [0] https://en.wikipedia.org/wiki/Futures_and_promises#List_of_implementations https://en.wikipedia.org/wiki/Futures_and_promises#List_of_i...
  - blackoil 4y ago
    IIRC, the statement was from some Java blog about Loom. Idea is that with lightweight threads you can make everything sync and still be performant. While C# has gone ahead with making everything async
MarkSweep 4y ago
A lot of these things you will get the benefit from upgrading. Also see the last section of the post about analyzers. You can enable these and Visual Studio will identify and potentially automatic improve performance by using different APIs. There are a performance ton knobs you can turn both at develop time and deployment time. There are 4 ways to run Regexes in .NET 7! (Interpreted, compiled, the new non-backtracking interpreter, the new compile time source generator). I do agree with the assessment that it’s hard to keep up with.
vsareto 4y ago
Bookmark https://devblogs.microsoft.com/dotnet/ https://devblogs.microsoft.com/dotnet/ and read occasionally. https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-11 https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh... is good for a quick overview of language features depending on what version you're at. Most .NET devs only need to be peripherally aware of these changes, as most businesses using .NET will move slower than Core's new pacing. It's even less important for lower seniority devs as you typically need project changes to utilize new features, which is a call a senior would make, which involves approval/testing/deployment, so a slow process which gives you time to read up on the new features as they're needed. You're better at your "craft" the more tools you know about and how to apply them, but if your day job prevents you from following the new stuff, I wouldn't worry too much about it. >I feel .NET Core after a good start is falling into the typical Microsoft trap of constantly cranking out new stuff to do the same thing and leaving it to developers to keep up. Yeah, the pacing has increasing dramatically from .NET Framework days, but that's probably a good thing. I would just stick to learning about what you do in your day job. .NET has a huge ecosystem compared to other languages, so it's going to be very hard to keep up with everything MAUI is doing if you're doing regular ASP.NET core APIs.
kevingadd 4y ago
You really don't need to use any new features to get the benefit of improvements in many cases, because the standard library is updated to use them. So things like string and array operations just get faster. I've started using 'ref readonly' and stuff like that in bits and pieces of my application code, but the rest of it is basically written in a .NET 4.0 style and it's fine, there's no obligation to use the new stuff unless you want to. I've started using some of the newer syntax sugar to make things more concise, like local functions, value tuples, and short property definitions - but again that's totally optional.

rr888 4y ago

I think this is pretty common with a lot of legacy code bases in popular languages. Lots of big systems on Java 8, Python 2, we wont talk about JS. :)

hardware2win 4y ago

>On the one hand it's cool that they are improving but how do people keep up with all these additions? I find this really hard. Very often they improve things in a way that you'll get an improvement regardless of whether you are aware E.g linq, collections, regexes, etc.

pjmlp 4y ago

We don't really keep up. I read with interest all these articles, and then go back coding our LOB stuff in .NET Framework 4.7.2 and similar. On the Java side, I am finally confident that all our servers have at least Java 11 on them. Only on private stuff do I happen to enjoy latest versions.

jabart 4y ago

Nullable's have been around for at least a decade and before .Net core existed? Are you thinking of the NotNull attribute argument checking instead(Likely the wrong term here)? Any change in a data type to an existing API or code will always be tough and a lot of work. Maybe an in32 to a in64 being the exception. Library developers are looking at these and following them to make enhancements. Developers working on business apps get the automatic performance improvements of these changes and the library dev changes to improve performance and allocations. I personally quickly go over these so when I get into a performance issue I have a little bit to know where to go find more information.

nightski 4y ago
Pretty sure they mean Nullable reference types which are much newer (although they have been around for a while at this point).
- spaetzleesser 4y ago
  Yes, that's what I meant.

ewjt 4y ago

Can you name other development platforms of similar scale/depth that don’t have this issue? Compared to the whirring treadmill of frontend web development, I find .NET to be pretty easy to keep up with. Good IDEs (ReSharper or Rider) really help with the new language features (which are opt-in). Outside of that, the ecosystem is large enough that there are quality blogs/articles/podcasts to stay current without sinking a ton of time into doing so.

asdajksah2123 4y ago
Front end development may have a lot of frameworks, etc., but so much less magic than .Net. What makes .Net so much harder (especially ASP.Net) are the new features but also all the magic that makes discoverability so hard. Front end frameworks tend to follow similar patterns, and where they differ, they usually advertise the difference between the standards heavily. But also, since they are genuinely different frameworks, it's easier to search the differences etc. So, if I open a Vue application codebase, I know almost immediately that it's a Vue application and not a React one. I can google vue and figure out (most likely from their getting started page) exactly all I need to know to get started. If I enter an ASP.Net codebase, on the other hand, I have no idea whether I'm looking at ASP.Net Pages, .Net WebAPI, .Net WebServices, or more often than not, some combination of all of them. Throw in some Dependency Injection, with a combination of IOC containers used in the same project, and it's a massive lift to know what even to Google for.
- metaltyphoon 4y ago
  I hear this word all the time “magic”. Can you describe what it means with concrete example for other stacks?
  - cerved 4y ago
    Http request handling in asp.net mvc. The uri, type and parameter serialization is a magic mess. How do you PUT { "foo" : { "bar" : "baz" }} to ping/pong/yolo? You create a controller class, PingController, you create a method PutPong, then you give up and proceed to cry blood

bob1029 4y ago

I don't try to keep up with absolutely everything. I've been to this particular buffet for a really long time and have developed tastes for certain things. For instance, I recognize AOT is elegant in theory, but I also notice it's a difficult thing to get right and has certain tradeoffs. Especially, for a complex application that may need to use legacy APIs. As a consequence, I have mostly avoided this in favor of focusing on other areas that do seem to deliver additional value for our product (and my side-projects). Examples of these being intrinsics (SIMD), UTF8 text/serializer, file I/O and more advanced GC techniques. Ultimately, it's a matter of experience to know when you should and should not chase a particular rabbit. My general policy right now is to observe the new shiny while it's in the odd-version, and then wait to see how it shakes down by the time the LTS comes around. You almost never want to try to grab a Microsoft-branded rabbit upon the very first sighting.

francisofascii 4y ago

Fortunately the upgrade path has not been too bad once you get to .NET Core. Usually one time changes to your Program.cs and Startup.cs files. The Top-Level statements addition is pretty jarring at first, but a cool addition. I did run into a breaking change from .NET 5 to 6 with an Encryption library not working right. But most everything else just works when upgrading. If it was just .NET additions life would be fine. It is the front-end churn that causes real stress. AngularJS, TypeScript, Angular, React, Blazor, WebPack, Vite, etc.

bestinterest 4y ago

I very much like the ethos of Golang for this reason. Still not had a reason to use it but like the idea of mastering the fundamentals in a weekend. Even if I lose the flexibility of LINQ or Java streams. It feels like a scale of language conservativeness Go all the way at the top, Java somewhat in the middle (a little above) and C# at the bottom. It is going the route with lots of features and complexity, which can be a great thing but not for grug devs https://grugbrain.dev https://grugbrain.dev like me. But saying all that Blazor looks really good for WebDev, I just worry it gets abandoned. It feels everything does in the C# space. C# also made a big mistake imo by going with async/await instead of lightweight threads which will add a ton of complexity in the future for if they decide to go the greenthread route like Goroutines/Project Loom.

keltex 4y ago
> But saying all that Blazor looks really good for WebDev, I just worry it gets abandoned. It feels everything does in the C# space. I've been maintaining a asp.net (WebForms!) framework codebase for almost 18 years now. Running on the latest Windows Server and Visual Studio 2022.
whoisthemachine 4y ago
> C# also made a big mistake imo by going with async/await instead of lightweight threads which will add a ton of complexity in the future for if they decide to go the greenthread route like Goroutines/Project Loom. Could you expand on this? Async/await is just syntax magic for Task continuations (in other words, Promises [0]), which have very little to do with the underlying threading model. This statement is equivalent to saying "Completable Futures add a ton of complexity to Project Loom." [0] https://en.wikipedia.org/wiki/Futures_and_promises#List_of_implementations https://en.wikipedia.org/wiki/Futures_and_promises#List_of_i...
- blackoil 4y ago
  IIRC, the statement was from some Java blog about Loom. Idea is that with lightweight threads you can make everything sync and still be performant. While C# has gone ahead with making everything async

MarkSweep 4y ago

A lot of these things you will get the benefit from upgrading. Also see the last section of the post about analyzers. You can enable these and Visual Studio will identify and potentially automatic improve performance by using different APIs. There are a performance ton knobs you can turn both at develop time and deployment time. There are 4 ways to run Regexes in .NET 7! (Interpreted, compiled, the new non-backtracking interpreter, the new compile time source generator). I do agree with the assessment that it’s hard to keep up with.

vsareto 4y ago

Bookmark https://devblogs.microsoft.com/dotnet/ https://devblogs.microsoft.com/dotnet/ and read occasionally. https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-11 https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh... is good for a quick overview of language features depending on what version you're at. Most .NET devs only need to be peripherally aware of these changes, as most businesses using .NET will move slower than Core's new pacing. It's even less important for lower seniority devs as you typically need project changes to utilize new features, which is a call a senior would make, which involves approval/testing/deployment, so a slow process which gives you time to read up on the new features as they're needed. You're better at your "craft" the more tools you know about and how to apply them, but if your day job prevents you from following the new stuff, I wouldn't worry too much about it. >I feel .NET Core after a good start is falling into the typical Microsoft trap of constantly cranking out new stuff to do the same thing and leaving it to developers to keep up. Yeah, the pacing has increasing dramatically from .NET Framework days, but that's probably a good thing. I would just stick to learning about what you do in your day job. .NET has a huge ecosystem compared to other languages, so it's going to be very hard to keep up with everything MAUI is doing if you're doing regular ASP.NET core APIs.

kevingadd 4y ago

You really don't need to use any new features to get the benefit of improvements in many cases, because the standard library is updated to use them. So things like string and array operations just get faster. I've started using 'ref readonly' and stuff like that in bits and pieces of my application code, but the rest of it is basically written in a .NET 4.0 style and it's fine, there's no obligation to use the new stuff unless you want to. I've started using some of the newer syntax sugar to make things more concise, like local functions, value tuples, and short property definitions - but again that's totally optional.