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.

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.

I hear this word all the time “magic”. Can you describe what it means with concrete example for other stacks?

Magic means “hidden complexity”, AKA “abstraction”. The negative connotation is that sometimes you can’t figure out why your software is behaving a certain way and what you need to do about it.

The positive connotation is that you write less code with less cognitive overhead.

Generally I prefer ASP.NET over things like Spring and Ruby on Rails because it has less magic, despite being clearly inspired by both of those.

Here’s a concrete ASP.NET example: You can put an [ApiController] attribute on your controllers and it can change the structure of error responses, among other things. [1]

I don’t agree with some of the other parent points. For example, the comments on “multiple dependency injection container” —- ASP.NET is pretty prescriptive on DI patterns. That sounds like someone made a decision to add complexity, which is on them.

[1] https://stackoverflow.com/a/66546105

So "non magic" means to write everything then? Because the example you showed you have to understand a language feature, attributes. Then see the source code, which is open, and how it's being used.

So, are Rust macros, or C macros, C++ templating magic or it's just means "I don't want to know how this works therefore it's magic"?

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

It seems you had a bad time learning ASP.NET, but in my experience what you're asking for is not difficult at all.

You have to: 1. [Optional] Define a DTO that deserializes { "foo" : { "bar" : "baz" }} to an object 2. Write a class that subclasses Controller 3. Write a method, call it whatever you want, that accepts a JObject or one of your DTO types. 4. Add the attribute [HttpPut("ping/pong/yolo")] to tell the framework this method should be bound to PUTs for that path. 5. Write your business logic.

Is that blood-crying inducing? No.

Without decent documentation, it is.

something like

app.MapPut("ping/pong/yolo", ctx => ...);

and in there you read the Body as string ... it should be a one liner?

app.MapPut("ping/pong/yolo", ([FromBody] Payload request) => {...});

record Payload(Foo Foo);

record Foo(string Bar);

or

app.MapPut("ping/pong/yolo", (JsonElement json) => {...});

Basically, just avoid outdated blog posts and articles :D

this looks like asp.net core

No one in their sane mind would use ASP.NET for new projects (it is legacy and a business risk) nowadays so it's reasonable to assume that everyone means ASP.NET Core given the .NET 7 context.

the context was asp.net mvc specifically

ASP.NET MVC is dead. It has been over 6 years; you need to update yourself.

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.

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.

Bookmark https://devblogs.microsoft.com/dotnet/ and read occasionally. 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.

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

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

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

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

I think this post has the best information on it as I am also learning here https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

It is not just `magic` syntax imo, it is viral to your codebase. The blog post does way more justice than I can explain.

Yes I understand the function coloring "problem" (oh no functions need to specify in their signature whether they return results immediately or eventually). Regardless, I still don't understand how this prevents green threads a la Project Loom, if you have a function that returns a `CompletableFuture` in Java, it also needs to change its signature.

For what it's worth, there is experimentation of green thread in C# happening.

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

I understand the difference in approaches. However, the parent stated that this decision makes green threads harder in C#, which is what I don't understand.

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.

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.

Pretty sure they mean Nullable reference types which are much newer (although they have been around for a while at this point).

Yes, that's what I meant.

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.

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.

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