Love the pattern matching bits, the not pattern has been long overdue. Unfortunately, that's where it ends for me. Don't like the top level statements...makes it seem like I'm programming in a scripting language and makes me want to run as fast as I can in the opposite direction. Now, records... It will be another feature that is pretty useless and I'll explain why. When I'm writing an immutable type, my constructor validates the invarients based on business requirement. Due to this, records won't ever benefit me and, I'd imagine, people writing immutable classes won't be able to take advantage of it either. Sure the language feature that checks for nulls helps but that doesn't do anything for all the other data types.

I actually don't like the getting rid of the Program / Main boilerplate. I think that should be required. One could ask the question, "Why not remove other boilerplate code?" which could end up in a slippery slope that could lead to confusion for folks maintaining those apps down the road. It's only six lines, just leave it. 😉

I don't love getting rid of the boilerplate code, but during Build, someone in the chat pointed out that it's not really intended for real applications; it's more for simplifying demos & for educational purposes. The rest of us can keep using Main() the way we always have.

Regarding the positional records, since there's the ability to have both constructor and deconstructor overloading, is it going to be possible to do this for positional records as well? From the syntax presented, it seems like it would only allow a single overload. For example, it would be nice to have a record that can be contructed both from (FirstName, LastName) or (FirstName, MiddleName, LastName).

Namspaces is taking up precious screen estate. Why can't I set it to 0 tabs in Visual Studio ?Why cant I have default namespaces as in VB.Net ? Good namning style is to have telling names for methods and variables.C# is not a help in this effort !

So the () constructor will take type inference from the left side, and the var keyword will take type inference from the right. This makes var p = (1,2) make syntactic sense (Although inference will fail). I'm not a fan of this sugar, and feel it, combined with the var keyword, is going to make code very difficult to read. One or the other, fine, but not both.