IMHO it's unnecessary at this juncture, and further fragments already vastly under engaged communities (.Net & C#)

Posts about .Net & friends fit into the .Net community. It's not so busy that a new community needs to break off to direct traffic & posts to.

This is actually a common failing point/pain point for low traffic or "growing phase" communities & platforms. Fragmentation reduces engagement, and below a certain threshold it just straight dies. Avoiding unnecessary fragmentation until such time as it serves a purpose helps communities grow faster.

To highlight this: the number of mods you are suggesting this community should have to handle TZ coverage is more than the average number of comments on posts in the .Net community today...

I go full chaos and look up where I last used it when I need a snippet...

System.Text.Json routinely fails to be ergonomic, it's quite inconvenient overall actually.

JSON is greedy, but System.Text.Json isn't, and falls over constantly for common use cases. I've been trying it out on new projects every new releases since .net core 2 and every time it burns me.

GitHub threads for requests for sane defaults, more greedy behavior, and better DevX/ergonomics are largely met with disdain by maintainers. Indicating that the state of System.Text.Json is unlikely to change...

I really REALLY want to use the native tooling, that's what makes .Net so productive to work in. But JSON handling & manipulation is an absolute nightmare still.

Would not recommend.

I do feel like C# saw C++ and said "let's do that" in a way.

One of the biggest selling points about the language is the long-term and cross repo/product/company..etc consistency. Largely the language will be very recognizable regardless of where it's written and by who it's written due to well established conventions.

More and more ways to do the same thing but in slightly different ways is nice for the sake of choices but it's also making the language less consistent and portable.

While at the same time important language features like discriminated unions are still missing. Things that other languages have started to build features for by default. C# is incredibly "clunky" in comparison to say Typescript solely from a type system perspective. The .Net ecosystem of course more than makes up for any of this difference, but it's definitely not as enjoyable to work with the language itself.

The great thing about languages like C# is that you really don't need to "catch up". It's incredibly stable and what you know about C#8 (Really could get away with C# 6 or earlier) is more than enough to get you through the grand majority of personal and enterprise programming needs for the next 5-10 years.

New language versions are adding features, improving existing ones, and improving on the ergonomics. Not necessarily breaking or changing anything before it.

That's one of the major selling points really, stability and longevity. Without sacrificing performance, features, or innovation.

Yessss.

C#/.Net backends are the best. The long term stability, DevX, and the "it just works" nature of all the tooling makes it a great choice. It's also fast, which makes scaling for most applications a non-issue.

I've switched to postgres for DB from SQL server, have never looked back, would recommend.

.Net + EF Core + Vue/TS + Postgres. Redis as needed, Kafka as needed.

I can get applications built extremely quickly, and their maintenance costs are incredibly low. The backends are stable, and can hang around for 5, 10+ years without issue or problems with ecosystem churn.

You can build a library of patterns and reusable code that you can bring to new projects to get them off the ground even faster.

Would recommend.

Nevermind PC games, think about how this would impact mobile games. Where you get TONS of transient installs, and very few consistent players.

You could actually go into debt by using unity, and accidentally being successful if you aren't abusively monitizing your game.

If you do this enough you know how to design your solutions to be relatively flexible. At least for your backends.

Your frontend will always churn, that's the nature of the job.

I think you can have a well tended garden without giving up creativity.

You're not sacrificing creativity by practicing structures, considerations, and methodologies that maintain or improve the developer experience with whatever creative endeavor you're on.

The structure of your garden doesn't prevent you from playing around with new plants, it just outlines a set of patterns and expectations known to drive better outcomes.

I'm not saying that your extension of the analogy is bad I'm just disagreeing with some of the premise.

Pretty much.

For instance focusing on PR size. PR size may be a side effect of the maturity of the product, the type of work being performed, the complexity or lack thereof of the real world space their problems touch, and in the methodologies habits and practices of the team.

Just looking at PR size or really any other single dimensional KPI lead you to lose the nuance that was driving the productivity in the first place.

Honestly in my experience high productivity comes from a high level of unity in how the team thinks, approaches problems, and how diligent they are about their decisions. And isn't necessarily something that's strictly learned, it can be about getting the right people together.

If it helps, I've been a visual studio user for the last 9 years.

In order to better support non-C# devs onboarding to C# (who where mostly on Mac, and vs for Mac is terrible) I switched to Rider 6 months ago, so we are using the same IDE and I can help them out.

Holy crap, it's good. There are a few things that aren't quite as nice (no more intellicode, stack traces are kinda shitty), but after fixing some garbage default settings, it's turned into a pretty good IDE.

The visual studio debugger is still better though.