Good luck with your code base in 5 years when someone decide to add all the new stuff.
Also (see in comments too), upgrading .Net is very easy. There are man not-to-small codebases can be "easily" upgraded from .Net Core 3 to 8 without any hassle. Backwards comptability was always baked into Microsofts thinking.
.Net 7 and 8 did also (IMHO) not contain that many groundbreaking features, just some "smaller" stuff.
I'm not saying Go is 100% right in that, but it's much more conservative about stuff added into the language.
I also think that Go looks like a practical joke that escaped some INTERCAL-like satire committee in the 1970s.
Good sum types destructuring would probably also be useful in more languages like Go, but many languages today provide "async/await" pattern syntax benefits without anything at all like "proper" sum types. Sum types are "merely" a possible implementation detail of the Monad and it's the Monad laws that empower some things beyond just sum types.
Exception-based languages don't look monadic at first blush, they definitely aren't Sum types, but try/catch is one of the earliest and oldest of the monadic binding/combining approaches, even if it isn't often thought as such (and is barely considered more than goto/switch). It's far more obvious when you start to realize the intersection of async/await and try/catch is a working monad (and how that is reflected in Task/Promise monad instances).
Golang is the obvious odd one out where every other line of "best practice" code is `if err != nil` and the only other advice is "well you could just ignore errors". try/catch doesn't ignore errors, it just looks like it. Rust error chaining doesn't ignore errors, it just looks like it. Golang gives you the choice between micro-managing errors or BASIC-style "ON ERROR RESUME NEXT" and I cannot get anyone to convince me why this isn't either a practical joke or an intentional throwback to writing code like it is the 1970s all over again (even VB6 had better options than "ON ERROR RESUME NEXT", even if they maybe weren't used as often as they should be in some legacy 1990s/2000s codebases).
You have a valid point there, but it hurts my ears a little for you to use the word "monadic" or "monad" to make the distinction between how the way Golang handles errors differs from how other modern language do it. To me, for a language to "have monads" requires the type system to give the programmer the ability to distinguish between a value type, e.g., an integer, and a computation that produce a value type. Haskell's type system for example uses `Integer` to refer to the former and, e.g., `IO Integer` to refer to that latter. And clearly by that definition, Rust and most other modern languages just don't have monads, i.e., don't have monadic types (and consequently don't support a monadic programming style) -- unless perhaps Rust's macro system can be used in some complex way to define the monadic-computational types, but I've never seen it used that way. BTW, I'd actually go further and say that to get the benefits of monadic style, the IO monad or whatever the language calls it must be the only way to perform side-effecting computations (though there is a little wiggle room on the definition of side effect here).
To be more precise, the terminology I prefer is that a monad (in the context of programming languages) is a type that obeys the 3 monad laws: https://wiki.haskell.org/Monad_laws. There are other ways besides a monad for the type system to distinguish between a value and a computation producing a value; Explicit continuation passing is one such way: whereas in Haskell you'd read a character from standard input with `main = getChar >>= \char -> do something with char`, in a language that uses explicit continuation passing, you'd write `main = getChar (\char -> do something with char)` where in this language getChar takes one argument, which happens to be a continuation argument. But all the languages I know about that let the programmer use the type system to distinguish between a value and a computation producing a value use the monadic style to express that distinction (rather than something like explicit continuation passing) so I tend to use "monad" and "monadic" to refer both to the specific thing that obeys the 3 laws and for the deeper programming-language property.
That's one level of confusion in this conversation so far. However, the other problem is that monads don't just mean "computation". (Arguably the Lambda Calculus is way closer to the metal and more accurate to describe as the abstraction of "computation".)
Monads are useful for describing "computations as values" but that's not what the abstraction is entirely for and thinking of monads only as "computations" is how you fall into the easy mistake to make that IO in Haskell is the only "real" monad. There are lots of monads in the wild (Maybe, Either, Promise, List, ...), some of which don't really describe computation at all. We love to mock it, but the technical definition of a monad is "a monoid in the category of endofunctors"; nothing about that is "computation" specifically. Computation is a handy shorthand, of course, but its confusing one of the trees for the rest of the forest sort of thing, mostly because Haskell's IO was the first time monad escaped as a term of art for the deep abstraction that it is.
There is an importance to the monad laws and the two monad "operators", more importance than "computation" as a shorthand for thinking about monads. These operators are called "multiplication" and "identity" in raw Category Theory, but in programming "identity" is usually called "return" and "multiplication" is often called "bind", "bind" is interesting because it also has a dual generally called "join" and "join" is sometimes called "flatMap" or "SelectMany". (Yes, that does point out that most list structures in every modern programming language provide monad operators and obey the monad laws. Lists are a monad.)
A dumber, better shorthand for monads may be "glueable". Monads bind things together in a way that two binds of the same type of monad results in just one monad. (flatMap two lists together and get one list back.) The power of monads is that you can keep gluing things together. Whether by "executing side effects" in a "computation runtime" like the stalwart IO monad or in all the "boring" ways of Lists and Promises and Maybe and Either (that mostly have nothing to do with "computations", except Promises, sort of). The big useful bit is that the Monad laws imply that you can do all this "gluing" in a stable way. That stable way also makes room for the means to transform from one type of Monad to another (Monadic transformers).
Monadic transformers are where some of the real power of the IO monad as an abstraction lives (and other monads in terms of compile-time representations): the idea that the "notation" doesn't matter so much as the end "glued" result. Imperative looking do-notation is the same sort of "glue" as a lot of individual calls to the Monad operators bind and return, transforming from one form to the other is "relatively" "trivial" because the Monad laws say everything should be fine.
There is a usefulness to the IO Monad in Haskell and it is an interesting way to "describe side effects to perform", but the whole of monads and monadic binding is a lot more than just the IO Monad and if you are defining monads to only mean "the IO Monad" you are missing some of their other usefulness.
Show me one place in my writings where I imply that the IO monad (or state monads generally) is the only monad.
That comparison is not a fair comparison to Go, which has a much stricter guarantee around source and library compatibility within the 1.x series.
Can a single developer remember all of .NET? No, but that applies to most languages/ecosystems. But if you encounter something you've never seen, you can always check the docs.
And the thing hasn't been named ".NET Core" for 4 consecutive releases now.
WebForms would like a word.
We're always thinking about the bloat concern when it comes to language development. However, our philosophy on it is that bloat primarily comes when you add replacement systems that are expected to supersede the previous mechanisms, not compliment them. So we try to do the former sparingly. In the history of C# there are very few times we've actually done this, and we do view those times as unfortunate cases where we likely rushed a feature too early and then regret having to live with those features forever.
To help combat this, we tend to go through long periods of design and experimentation, where we propose features, create prototypes of them, and then interact with a large set of diverse community groups to try things out. The feedback from this is tightly bound into our design process and allows us to refine (or even jettison) designs rapidly.
We also normally will both break up work into lots of smaller pieces (composing large language changes into small orthogonal, complimentary, composable blocks), and do designs over many years if appropriate. We think this approach has helped us create a language that is 25 years old, while being both very rich, and still very cohesive. There are a few mistakes we've made along the way ("anonymous-delegates", i'm looking at you), but we're very happy that our ratios here are very good given our continued investment in this space.
Still not really sure how I feel about class primary constructors on the other hand, will give them some time to marinate.