I would not take pattern matching as the right example. I learned pattern matching at the university and always missed it in C#. It is easy and straightforward. When you love lambdas and linq, so C# 3.0, pattern matching is easy.

However, when it comes to modern C# and memory management I also think that readability suffers a lot. Memory management on that level is well known to the professional C/C++ folks but most of us are just overloaded with it.

I agree. It has the flexibility of Scala without the extra power/abstractions Scalaa gives you. I don't love Scala's flexibility but I put up with it because of its power, the trade off isn't worth it for C# to me.

> You can write C# in too many forms and I don't believe that's really good.

Why not? And what, exactly, defines "too many"?

I know people meme a lot about Go and "not having generics," but I really feel that a lot of the things left out of Go have benefitted it. I've never really been able to jump into a project without a lot of mental overhead. With Go, most code everywhere is written pretty idiomatically, making it easy to approach and read. I've heard similar things about C#, but my experience hasn't been as great.

This is a big problem in the JavaScript world in my opinion. So many different ways to solve common problems that it's difficult to approach. OP might be worried this could be happening to C#.

We could go with a language with just if statements, while statements, function calls and "return" and be extremely easy to jump into. :)

While a bit snarky I do think it is one of the fundamental problems with programming language innovation. No matter how smart we are, learning is effortful. And we frequently judge languages not by how productive it is, but by how quickly we can start feeling productive in it. Which often preferences familiar concepts over more powerful concepts.

There is a very long feedback loop in properly evaluating a language. At least 1-2 years. You need not just figure out how to do what you already know in the language, you need to learn the new way to think in the language. And that takes time and solving lots of problems. This is only sped up if the language's concepts are kept very similar to a language you already know.

We are the bottleneck that slows down language improvement. There is no way anyone can convince me that the hodgepodge of Algol derived languages is one of the best ways out there of writing code. But most new languages will be similar because the hurdles of trying to teach people anything else alongside the actual new interesting concepts of your language are too much of a blocker for any reasonable adoption.

I suppose, but that seems like a natural consequence of C#'s desire to move the language "forward" in terms of implementing new features (such as switch expressions or non-nullable reference types) while also maintaining backwards compatibility (for example, you can still use the non-generic "ICollection" interface if you want to). Just a different set of priorities.

>I know people meme a lot about Go and "not having generics," but I really feel that a lot of the things left out of Go have benefitted it.

Yes, that's why we program in Brainf__k here: It only has the bare essentials and it's so easy to learn.

Perhaps he means something like Python's motto of "There should be one--and preferably only one--obvious way to do it."

https://www.python.org/dev/peps/pep-0020/

I think all the new features are improvements, but I agree the language is getting big with many ways to do the same thing. I don't think MS will ever do a 'Python 3' and cut backwards compatibility.

> Why not? And what, exactly, defines "too many"?

I think Scala was innovating in this respect before Kotlin ate its lunch (it may still be).

You could use Scala as everything between Java++ and Haskell--. Developers proficient in Java++ often had a difficult time understanding code written in Haskell--.

Language designers are not immune to the "code must change constantly otherwise it's abandonware" mentality of today's developers.

I think I agree. I used to write a lot of C# v2 and loved it. There didn't seem to be anything 'missing'. Each version since then has added nice things but are they really necessary? Now the language looks huge and complicated and because of that, I'm not sure I'd ever want to use it again.

C# 2? The freshness of C# 3! The comfort improvements of C# 4, C# 5 and C# 6! And now the new freshness in C# 7.0.

I agree with other posters that this introduces a new style, but when I look at C# 2.0 I see a language I do not want to use anymore. It is old and clumsy. Like Java :)

C# 2 did not have Linq. Linq is the best feature ever.

Actually, adding LINQ to C# did not introduce any new functionality at all. Everything you can do in LINQ you could already accomplish in C# without LINQ. Yes, I suppose someone could say that the older code was uglier, but it already had the same capabilities as LINQ.

That's been the case for the majority of supposed "new features" in C# for at least the past 8 years or so -- LINQ, inline variables, anonymous functions, string literals etc. It's all just syntactic sugar on top of existing features.

That's the general nature of a turing complete language. The purpose of every feature is making things less ugly.

I'd say it's more the general nature of Microsoft in this particular case. "There should be three different ways to do that" has been the case since Windows 3.1.

There is no way you can implement Linq in C# 2.0. C# 2 does not have lambdas and expression trees, so you cannot write an expression which can either be compiled into regular code or into an expression tree depending on context.

IIRC, LINQ can be translated to C# 3.0 without LINQ, so I guess it is syntactic suger but for C# 3.0. To implement it in C# 2.0 one would need to replace expression trees with “home made” query specification classes. It would be a lot of work, it would not be standardized, and it would not be integrated in the language.

So the real new feature in C# 3.0 are the expression trees. LINQ is only one place where expression trees are used.

LINQ is surprisingly powerful when you start overloading SelectMany, as that allows you to implement Monads nicely.

Do you know what "expression trees" are and how they relate to LINQ?