This is a weird take given that the majority of projects relevant to this article are massive projects with hundreds or thousands of developers working on them, over time periods that can measure in decades.
Pretending those don’t exist and imagining fantasy scenarios where all large projects are made up of small modular pieces (while conveniently making no mention to all of the new problems this raises in practice).
Replace functions replace files and rewrite modules, that’s expected and healthy for any project. This article is referring to the tendency for programmers to believe that an entire project should be scrapped and rewritten from scratch. Which seems to have nothing to do with your comment…?
To be fair Microsoft has been working on Garnet for something like 4+ years and have already adopted it internally to reduce infrastructure costs.
Which has been their MO for the last few years. Improve .Net baseline performance, build high performance tools on top of it, dog food them, and then release them under open source licenses.
C# on non-Windows is not impossible, but it’s going to require effort infeasible for school projects like that one.
You mean winforms (The windows specific UI) on non-Windows? Otherwise this is incredibly misleading, and plain wrong.
C# in non windows is the norm, the default even, these days. I build, compile, and run, my C# applications in linux , and have been for the last 5+ years.
.NET MAUI (Multi-platform App User Interface) uses the latest technologies for building native apps on Windows, macOS, iOS, and Android, abstracting them into one common framework built on .NET. MAUI is the evolution of Xamarin....
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…
That’s seems awfully short no? We’re talking a couple hours of good flow state, that may not even be a full feature at that point 🤔
We have folks who can push out 600-1k loc covering multiple features/PRs in a day if they’re having a great day and are working somewhere they are proficient.
Never mind important refactors that might touch a thousand or a few thousand lines that might be pushed out on a daily basis, and need relatively fast turnarounds.
Essentially half of the job of writing code is also reviewing code, it really should be thought of that way.
(No, loc is not a unit of performance measurement, but it can correlate)
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.
It writes more informative commits than I could ever make so I’m just reading what it says and mostly copy/pasting completely most of the time, I write all of the changes I’ve made into an LLM with a large context window and it write a very detailed commit not just with a title but with bullet points describing each of the...
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.
Anyone preaches the virtues and advantages of domain-driven design, its positive impact on maintainability and adding features, and how it improves developer experience. However, as all things in life, all roses have their thorns....
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.
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.
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.
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.
Following the announcement of Visual Studio for Mac’s retirement, for the next 65 hours we are offering a 65% discount on new subscriptions for Rider, the only cross-platform .NET IDE....
Switched over to it this year from VS, it’s so good in comparison. There’s some things that aren’t as nice (the CPU/memory graphs in VS are actually nice and handy). But overall, an upgrade.
What are your opinions on the future of back-end web development? Is the Java ecosystem going to wither away as more modern and better solutions are emerging and maturing?...
Yeah but the ecosystem drags it about as far down as you can go.
Backend development for large applications relies on stability, the JS ecosystem has anything except stability.This is okay for FE development where you naturally have a lot of churn.
It’s a reasonable expectation that a backend built today should be maintenance free and stable over the next 5-10 years if no more features or bugfixes are required. And is buildable, as is, anywhere in that timeframe with minimal or zero additional work.
Additionally, strong backends in the same ecosystem are similar, they use similar technologies, similar configs, similar patterns, and similar conventions. This is not the case for JS/TS backends, there is incredible churn that hurts their long term stability and the low-maintenance requirements of strong enterprise, and even more importantly small businesses backends.
Mature ecosystems provide this by default this is why C#/Java is so popular for these long-standing, massive, enterprise systems. Because they are stable, they have well established conventions, and are consistent across codebases and enterprises.
This is a perspective most devs in the ecosystem lack, given that half of all developers have < 5 years of experience and the vast majority of that is weighted into the JS ecosystem. It takes working with systems written in python, TS, JS, C#, Java…etc to gain the critical insight necessary to evaluate what is actually important in backend development.
Edit: to be clear this isn’t just shitting on JavaScript because that’s what people do, I work with it everyday, TS is by far my favorite language. 2/3 of my career is with JS/TS. This is recognizing actual problems that are not singularly solvable with the ecosystem that pulls down its liability for backend development. There are languages and ecosystems are much better for your back end it’s not that scary to learn a new language (many of my co-workers would disagree it’s not scary 😒)
Things You Should Never Do, Part I (2000) (www.joelonsoftware.com)
Garnet: A faster cache store drop in replacement for Redis (www.microsoft.com)
GitHub: github.com/microsoft/garnet...
Redis is no longer OSS (fosstodon.org)
Linux and Winforms
Hi Lemmings, I wondered if anyone had successfully created a C# project that uses winforms on linux....
How IT People See Each Other (tesseract.dubvee.org)
Not OC: Just found this on my old hard drive while grabbing some other stuff.
.NET MAUI (programming.dev)
.NET MAUI (Multi-platform App User Interface) uses the latest technologies for building native apps on Windows, macOS, iOS, and Android, abstracting them into one common framework built on .NET. MAUI is the evolution of Xamarin....
How do you manage code snippets?
Do you keep them in your IDE, or elsewhere? Do you have an app for that? Are they easily shared?...
me_irl (lemmy.eco.br)
I'm a hypochondriac, but It's About Programming (www.blobstreaming.org)
I've lately been making my git commit messages with AI (reddthat.com)
It writes more informative commits than I could ever make so I’m just reading what it says and mostly copy/pasting completely most of the time, I write all of the changes I’ve made into an LLM with a large context window and it write a very detailed commit not just with a title but with bullet points describing each of the...
Discussion: worst experience with domain-driven design?
Anyone preaches the virtues and advantages of domain-driven design, its positive impact on maintainability and adding features, and how it improves developer experience. However, as all things in life, all roses have their thorns....
What′s new in C# 12: overview (pvs-studio.com)
The convenience of System.Text.Json - .NET Blog (devblogs.microsoft.com)
Garry Newman: The new Unity pricing would have cost him $410,000 of lifetime revenue (i.vgy.me)
This is of course not including the yearly Unity subscription, where Unity Pro costs $2,040 per seat (although they may have Enterprise pricing)...
JetBrains are offering 65% off Rider until 4th September (lp.jetbrains.com)
Following the announcement of Visual Studio for Mac’s retirement, for the next 65 hours we are offering a 65% discount on new subscriptions for Rider, the only cross-platform .NET IDE....
Visual Studio for Mac Retirement Announcement - Visual Studio Blog (devblogs.microsoft.com)
The future of back-end development
What are your opinions on the future of back-end web development? Is the Java ecosystem going to wither away as more modern and better solutions are emerging and maturing?...
Hours of work (programming.dev)