douglasg14b

Great timing that Microsoft just released a drop-in replacement that's in order of magnitude faster: https://github.com/microsoft/garnet

Written in C# too, so it's incredibly easy to extend and write performant functions for.

It needs to be a bit more deployable though but they only just opened the repo, so I'll wait.

The designers as seen by designers is so right.

Nothing they come up with can be wrong, it's all innovative!!

.Net 8 will work on Linux just fine. But winforms will not, it's specifically a legacy windows-only UI framework.

You're going to have to jump through some incredible hoops to get it to work on Linux. Which are definitely not part of your normal curriculum.

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

The follow on. Lots and LOTS of unrelated changes can be a symptom of an immature codebase/product, simply a new endeavor.

If it's a greenfield project, in order to move fast you don't want to gold plate or over predictive future. This often means you run into misc design blockers constantly. Which often necessitate refactors & improvements along the way. Depending on the team this can be broken out into the refactor, then the feature, and reviewed back-to-back. This does have it's downsides though, as the scope of the design may become obfuscated and may lead to ineffective code review.

Ofc mature codebases don't often suffer from the same issues, and most of the foundational problems are solved. And patterns have been well established.

/ramble

There is no context here though?

If this is a breaking change to a major upgrade path, like a major base UI lib change, then it might not be possible to be broken down into pieces without tripping or quadrupling the work (which likely took a few folks all month to achieve already).

I remember in a previous job migrating from Vue 1 to Vue 2. And upgrading to an entirely new UI library. It required partial code freezes, and we figured it had to be done in 1 big push. It was only 3 of us doing it while the rest of the team kept up on maintenance & feature work.

The PR was something like 38k loc, of actual UI code, excluding package/lock files. It took the team an entire dedicated week and a half to review, piece by piece. We chewet through hundreds of comments during that time. It worked out really well, everyone was happy, the timelines where even met early.

The same thing happened when migrating an asp.net .Net Framework 4.x codebase to .Net Core 3.1. we figured that bundling in major refactors during the process to get the biggest bang for our buck was the best move. It was some light like 18k loc. Which also worked out similarly well in the end .

Things like this happen, not that infrequently depending on the org, and they work out just fine as long as you have a competent and well organized team who can maintain a course for more than a few weeks.

Like most large conceptual practices the pain comes when it misused, mismanaged, and misunderstood.

DDD like Agile, when applied as intended, adds more to success than it detracts. This means that others take it and try to use it as a panacea, and inappropriately apply their limited and misunderstood bastardization of it, having the opposite effect.

Which leads to devs incorrectly associating these concepts & processes to the pain they have, instead of recognizing a bad implementation as a bad implementation.

Personally, I've found great success by applying DDD where necessary and as needed, modifying it to best fit my needs. (Emphasis mine). I write code with fewer bugs, which is more easily understood, that enforces patterns & separations that improve productivity, faster than I ever have before. This is not because I "went DDD", it's because I bought the blue book, read it, and then cherry picked out the parts that work well for my use cases.

And that's the crux of it. Every team, every application, every job is different. And that difference requires a modified approach that takes DevX & ergonomics into consideration. There is no one-size-fits-all solution, it ALWAYS needs to be picked at and adjusted.

To answer your question

Yes, I have had lots of pain from DDD. However, following the principals of pain driven development, when that pain arises we reflect, and then change our approach to reduce or eliminate that pain.

Pain is unavoidable, it's how you deal with it that matters. Do you double down and make it worse, or do you stop, reflect, fix the pain, refactor, and move on with an improved and more enlightened process?

It's literally just "agile", but for developer experience.

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.

And what does it imply?

That an AI might be better at writing documentation than the average dev, who is largely inept at writing good documentation?

Understandably, as technical writing isn't exactly a focus point or career growing thing for most devs. If it was, we would be writing much better code as well.

I've seen my peers work, they could use something like this. I'd welcome it.

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.