Why is Microsoft Changing C# Syntax So Much?

Why is Microsoft changing things that already work? Top level statements (Program.cs files without a method, class, or namespace), file-scoped namespaces, switch expressions, minimal APIs, and more are all just adjustments to what we already had. So why make these changes? Why is it important? Isn't it just confusing? These are the questions we will answer in today's episode of Dev Questions.
Website: www.iamtimcorey.com/
Patreon: / iamtimcorey
Ask Your Question: suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: signup.iamtimcorey.com/

[@CodingCrumbs]

One issue I had with this change and being new to C# was that all the documentation online shows the old syntax so it was a bit confusing at first trying to figure out why mine looked so different.

[@IAmTimCorey]

That was a tricky transition.

[@ABMedia83]

Great Video I'm not complaining. Global Usings make app development much simpler. Namespace changes also make things simple. Top Level statements makes things easier for getting started. I don't always use top level, but it depends on what I'm doing. With some of my console apps I like the call certain Dialogs (aka from Windows Forms and or WPF)) and you have to write it a certain way to get it to work. Side Note I love the Triple Quote system in C# 11 because it makes it much easier to generate code, documents, etc.

[@IAmTimCorey]

Thanks for sharing.

[@kubev]

I do like the idea behind these changes, though I'm curious as to whether this could have negative repercussions for people new to C# when it comes time for them to deal with older C# code later on.

[@AldoInza]

We just have to empower new developers with smugness that there's a newer, better way. They'll be chomping at the bit to remember the old ways and ackshully away legacy syntax and memorize every bit of it.

[@IAmTimCorey]

That's a valid concern, but I think that it will actually help them. They can get started easily and ramp up to learning about the various things they need. By the time they start looking at legacy code, they will know about namespaces, classes, methods, parameters, using directives, etc. That will really help them understand what is going on in Program.cs and the other older ways of doing things.

[@blo0m1985]

its just crazy confusing even for basics. For example collections: array = Type + [], list = List, tuple = Tuple. Concerning switch, semicolon needed or not at the end, tab + colons for statements... so frustrating. Also naming, I for interfaces but nothing for value and reference types distinguishing. Initialization of variables and access levels in structs differs with class and interface... name it, just a mess. All new is cool thoug but it does not eliminates to get to know old.

[@ChildrenToysCollector1]

Like now with .Net Framework 4.8 ;))) I was started learning curve from .Net Core 3.1 or 5 and never ever see .Net Framework... But almost every company have Framework code.. It's terrible...

[@blackenedsprite8542]

I've found though that I do appreciate the time I spent with all the this stuff being more explicit and having to work with it, as it means I got a better understanding of everything. That said, I really like the changes.

[@IAmTimCorey]

I'm glad.

[@maxron6514]

I still have the feeling one of the big reasons is they are trying to compete with python when it comes to showing a hello world program to the FNGs 😂

[@kubev]

To be fair, one of the most off-putting things about C# beginner tutorials is that there's stuff there that's usually not explained, and you're basically just told to ignore it for now. If that's the case, then it's not as though you really have a full understanding of why that Hello World app works.

[@IAmTimCorey]

What @kubev said. It isn't about competing with Python, it is about taking a good idea and using it.

[@maxron6514]

Sure Tim. My comment wasn’t meant to be taken THAT seriously 😉

[@shs4293]

​@@IAmTimCorey Exactly.

[@chadbaldwin652]

This concept is one of the reasons I tend to develop a lot of my initial/testing code in PowerShell first rather than directly in C#. Because I don't want to deal with all the boilerplate required for me to test something out, or setup a basic idea of what I want it to do. It allows me to be lazy and skip a lot of those steps you'd normally deal with in classic C#. Then once I figure it out, I translate it to C#. I feel like it's the same concept, except now it's making its way directly into the C# language, and I love it.

[@IAmTimCorey]

I'm glad you like it.

[@qa2002]

TC... great job. Like all things, the new C# changes are context specific. Whenever I write code, in terms of style and format, I do not write it for me, but rather I am writing it for the eyes that come in behind me, for those who may need to maintain / enhance the code. And more often than not, that developer is what I call the "unsuspecting" developer, so I use comments, I use consistent styles and I used consistent programming paradigms (best practices) that make things intuitive (hopefully less painful). I try to avoid the "black box" stuff wherever possible, specifically like some of the code changes that remove boilerplate in program.cs, for instance the IConfiguration Configure/Configure services. Thanks for all your hard work!

[@IAmTimCorey]

You are welcome. I do have a video with some tips on code documentation coming out soon that might be of interest to you.

[@MiningForPies]

I love the new changes, been using c# for nearly 20 years. My only complaint is things moving so fast and the documentation is not keeping up. Had to raise an issue today with examples that don’t compile. But that’s not a c# issue, that’s a not enough volunteers jumping in and helping.

[@IAmTimCorey]

Yeah, it can be tough to keep up with it. It is a LOT better than it used to be, though.

[@MiningForPies]

@@IAmTimCorey massively. As with c#. I can still remember handcrafting collection classes so we’d have type safe lists. Then generics came in and people complained and said we don’t need this. Now you’d be insane to not just just a list or collection

[@CodingCrumbs]

This was my issue being new to C# as well. All the online documentation shows the old syntaxes so it was confusing at first.

[@jongeduard]

Same feeling. But I would like to add that the IDE quality suffers from the same kind of problems. VS seems to get more bugs everyday and with top level code IntelliSense is in both VS and VS Code a lot worse than with the old Program class and Main method code style.

[@MiningForPies]

@@jongeduard biggest problem is they cut a lot out of the IDE when they went 64 bit. Support for SSIS is a lot worse now than it was

[@EduardQualls]

NOTE: *Standard English-language (& programmer) vocabulary* (in which not all vegetables are called "broccoli" and not all punctuation is called a "bracket"): *( )* := left or right *_parenthesis_* - plural: *_parentheses_* Used just as one formats a (parenthetical) phrase within a sentence *{ }* := left or right *_brace_* (curly is redundant/understood: like _suspenders_ [in North America] or *_braces_* [in the UK], curling over a big gut) *[ ]* := left or right *_bracket_* (with "sharp" _k_ and _t_ sounds, just like their corners)

[@chriswinslow]

I’m new to C# and OOP, could you please make a follow up video showing the syntax change examples you are saying Microsoft are rolling out? Thanks for your great video courses Tim.

[@IAmTimCorey]

I've covered almost all of the major changes. For example, here is a video on the changes to Startup: kzbin.info/www/bejne/rJXLd6pni7iirck You can also check out the 10-minute training series, since I cover a lot of the smaller changes there: kzbin.info/aero/PLLWMQd6PeGY1MtyfNc0RbJSrC9LRUmT-6

[@iankirkpatrick2022]

I am glad that Microsoft made it optional. But since we're on a public forum and everyone else is voicing opinions and I love voicing my opinion, I figured I would... I'm not a fan of the reduced syntax. I don't actually think it's reducing much in way of barrier to entry. I remember my very first few days of my first programming class learning how to print to the console. My teacher said "Just put this stuff here and we'll teach you about it later." And that was enough for me. It didn't once confuse me. Did I know what it meant? No. Did it make it hard for me to learn how to print to the screen? No. In the same way that I didn't acutally know what a standard library was at the time but there I was, using System.out.println to do what I needed to do. Just because something exists that we don't know about, doesn't mean we have to be afraid of it. I think doing this reduction comes from that mentality (not on the experienced devs side obviously but we assume that beginners will be and I don't think that's an accurate evaluation). As for an affirmative reason to keep the old syntax, I think that it actually will have the opposite effect. It will lead to a greater bearier to entry. Yeah the new dev may be able to print to the console in much less time. But having that stuff there may spark curiosity and encourage them to ask about it and learn about it. I think of the time when I saw my first use of the "new" keyword. I asked my teacher what that was. He introduced me to classes and that sparked me learning about objects much sooner than all the other class mates who just glossed over it. If we take all that out, then we make it harder for those with that drive to learn to know what to learn in the first place. Yes, it is true that not everyone wants to learn like that, but I think it sets a dangerous, or at least an undesired precedent to appease the lack of desire to learn how things work in favor of just getting as many people blindly into the craft as possible. I'd rather hire someone knowing that they can overcome a tiny bit of unknown than to wonder if they got here because we coddled their un-comfortability with a tiny bit of unknown. I realize that this is a small instance of this "coddling" I describe and it's a far cry from coddling in reality, but we know from history and life that consistent small steps leads to miles of progress. I'd hate to see a precedence of this be set.

[@IAmTimCorey]

I don't think this is coddling. Instead, I think it is removing unnecessary code because it is unnecessary (and actually a lie - see my video this Monday about that). The best thing a senior developer can do is reduce complexity. This is a reduction in complexity. For example, full APIs in .NET 5 come with Program.cs, Startup.cs, and a controller to start with. That's well over 100 lines of code and three files before you even start writing your API. With a minimal API in .NET 7, I can create a complete microservice API with full CRUD to SQL exposed as five endpoints, I can have full documentation with Swagger, and I can have full logging in less than 50 lines of code and one file. That's a significant reduction in complexity and a significant increase in clarity. That's not coddling, that's making the code better.

[@batraxos2]

It's probably part of our dummed down society. Microsoft believes we need the Python and Javascript people to like us. C# is way too complicated for them, lets totally change it. We will soon make whole projects in one file again like 40 years ago. It is much easier. We dont even need methods, why not just use global variables and goto. It is more or less what it compiles down to anyway. And of course variables that change type as we go along. Much more flexible. And if there is something in C# you don't understand, don't buy a C# book, search online or try to figure it out, just demand that everything works just like in javascript, where all is allowed and almost everything fails, you just don't know about it.

[@IAmTimCorey]

It sounds like you are arguing that C# is making things too easy, which is it’s while job. It is a high-level language. It’s job is to make things easier. If you want harder, use C++. It does less for you. As for your argument, how it looks shouldn’t really be a valid argument. You didn’t address which things were necessary that I said weren’t.

[@batraxos2]

@@IAmTimCorey Well, it might be easier for small projects, but removing usings, main functions, visible default namespaces, probably the whole mvc structure eventually, setup files like Program and Setup, it might make it more difficult for people to learn how to create well organized larger projects unless people really read a C# book, which most people don't. I am glad that we still have the option to create old-style projects, but I believe that is only temporary. It has neveer been difficult to create a small C# project anyway in my opinion, just create a project, webform or console app, and start working in the main or mainform and create new functions or classes from there. You don't need to understand everything going on to make C# work.

[@catalinbadalan4463]

:))))))))))))))))

[@codeme8016]

I wish you would have talked about its limitations compared to a Full-API as well if any. I assume there's no ability difference based on this video. Thanks for your time and effort.

[@IAmTimCorey]

There aren’t limitations from one to the other.

[@quicktastic]

It's slowly turning C# into Visual Basic which is fine if that is what everyone wants. The concept of the using statements (and other boiler-plate items) is an important thing to understand that will be lost on newcomers. For you, or anyone else that already has experience, it won't change your knowledge of what is actually going on that is hidden, but somebody new will be oblivious. If they try to then give C++ a try, they will be completely lost with 'includes'. It also makes you wonder that if someone is completely baffled and can't grasp the basic boiler plate stuff, how are they really going to do with some of the far more complicated aspects of programming? The option of hiding the boiler plate code seems reasonable to someone that already has a full grasp and understanding of what it is doing and why it is there. Hiding it is then just for a cleaner coding environment. Be careful what you wish for with this stuff.

[@IAmTimCorey]

I disagree. I think your example of hiding usings and then switching to C++ and getting lost with includes just illustrates that. Those two things are totally different concepts. A using does not import a library. It is just a shortcut to eliminate the need to specify the full namespace for an object. An import actually brings in a library. The concept of importing a library in C# was hidden from day 1. Have you ever consciously added the System library? Nope. Why? Because it is already baked into the framework. Concepts such as using directives, namespaces, classes, and methods are all valuable things to know. The questions is, do you need to know them right away? The answer is no. When a new developer opens up a console application to learn C# for the first time, they don't know what variables are, let alone classes, methods, etc. So when they see a Console app with 5 using directives, a namespace, a class, a method (with a parameter) and a bunch of curly braces, we tell them to ignore all of that for now and focus just on the code inside the Main method. We then build up to learning about all of those items and why they are there. So no, I don't think it is a good test for new developers to see if they can grasp the boilerplate code. Also, we aren't hiding boilerplate code, we are eliminating it. There isn't a need for it. Remember that applications are meant to be read by humans. If we can make it easier to read, that's a win.

[@maxthecat4632]

Yes with a smattering of javascript to make it worse.

[@quicktastic]

@@IAmTimCorey You just eloquently described how it all works off the top of your head due to your experience because you had to learn it all. Someone new will be oblivious. Perhaps they won't need to know as they will just be asking ChatGPT to do the heavy lifting anyway :). Sorry if I came across too negative sounding, but I worry about a world where more and more know how to 'do things' but don't know how anything actually works. You do know, which is why you are successful. I appreciate you taking the time to respond. Thank you.

[@starmole5000]

Nothing wrong with visual basic! Cut my teeth on that. And there's a lot of developers (myself included) that love C# but will never touch C++. Just no need, never want/need to get that close to the CPU.

[@bobweiram6321]

@@IAmTimCorey I don't know what happened to my last comment, but I'll reiterate some of it. Beginners should understand namespaces, classes and methods if they're going to use an IDE, which is intended for application development. If beginners need training wheels, then they should be using a REPL console or lightweight environment. Apple already solves this problem with Swift Playground which is a standalone app for learning Swift. It lets beginners learn Swift without getting buried in the development infrastructure. Microsoft IDEs already support a ton of different REPLs.

[@amit-pk5zz]

Till date lot of code is written in C#, asking enterprises to switch to new c# may involve training and adaption cost...which may b negative.

[@IAmTimCorey]

This isn't asking anyone to change existing code. It is for new projects only. You can change your old code, but that is your choice. Everything still works the "old" way.

[@swordblaster2596]

I find the usings and top level stuff of really marginal if any advantage. It's the new syntax they are adding in the misguided belief that "fewer characters = better code" that I really feel is negatively impacting the language, right now. Devs are using it without considering human readability, and for what? Better compilation results? No, it's exactly the same. Development fashions goes around in cycles and currently we're back in the "terse code is better than readable code" phase unfortunately.

[@IAmTimCorey]

I would argue that the old way has had a negative impact on developers for years. Program.cs has always been a lie. They are just now correcting it. Let me explain: Here is the code from a .NET 5 Program.cs file for a Console application: using System; namespace ConsoleApp3 { internal class Program { static void Main(string[] args) { Console.WriteLine("Hello World!"); } } } Here is the same Console application in .NET 7 (I removed the code comment letting you know what has changed and giving you a link to more information about the change): Console.WriteLine("Hello World!"); That's a big difference. So let's talk about each line and why it is logical to remove it: 1. using System; - This using statement is at the top of every class file. Why? Not very DRY. You could say that is obfuscating things, but if you hover over Console.WriteLine, it still tells you it comes from the System namespace. Not really a loss here. 2. namespace ... - Why does this code need to be in a namespace? Nothing calls it. Basically, this is code for show, not for a purpose. 3. internal class Program - Why do we need a class name? Nothing calls this class. Again, code for show. 4. static void Main - Why do we need this name? Nothing can call this method. Again, code for show. 5. string[] args - Here is the one place I agree with you. They should show this. It is actually hidden and it shouldn't be. 6. three pair of curly braces and indents - Not necessary. For twenty years, we have lied to ourselves and new developers that the Program.cs file was a normal normal method inside of a normal class inside of a normal namespace declaration that just had an additional special purpose. That was never true. Main cannot be called and the only way to make the Program class "real" was to put extra methods inside of it and make things messy. What Microsoft did was they acknowledged that there was ceremony without purpose and they eliminated it. In their attempt at making it clean, they did hide one piece (one that new developers rarely use, but still). Everything else was absolutely unnecessary to keep. What exactly from the list above would you like to argue was necessary? By the way, if it comes down to "well, I like it the old way", don't forget that they kept the old way. You just need to check a box and it comes back.

[@jeroenvrijkorte3021]

@@IAmTimCoreyTo me, the main advantage of the old-style Program.cs is that you can easily extract a small piece of reusable logic out to its own top-level method in the same class. Visual Studio lets you do this by selecting a piece a code of and then "Extract method". It is a good starting point to teach code factoring to new developers. In the new-style, this is not possible: you can only create local functions. Personally I dislike local functions in most cases, because any variables from the outer function are also in scope inside the local function. This can create unexpected side effects from the local function onto the enclosing scope and hence subtle bugs. Inexperienced devs are likely going to create a massive Program.cs due to underdeveloped factoring skills, where everything is coupled together through local variables in not-so-obvious ways. To properly structure a program, they would first have to learn the supposedly problematic "ceremony" anyway. So this is my main critique of top-level statements. They actually make it harder to learn the language properly, and add an additional threshold to basic code factoring. I agree with your point though that the old-style Program.cs is a bit of a hack. It arises from trying to integrate an object-oriented programming model into a procedural OS.

[@TundeEszlari]

Sensational video.

[@IAmTimCorey]

Thank you!

[@dereklomax161]

Speaking of syntax changes, I'd like to see some new code on that background screen. It has been the same as long as I remember. I vote for a dapper database call or maybe something related to each video. Keep up the good work.

[@IAmTimCorey]

lol, thanks for the input. I'll pass that along to Dan.

[@DummyFace123]

The biggest thing they could do to reduce boilerplate is have the default accessor (when not specified) be public instead of private or internal. The 90th percentile is I’m going to make it public. The lowest chance of all is I’m going to make it internal. Yet when you create a new cs file in a tutorial, what’s always the first thing you have to change? Exactly. In an interface you don’t specify accessors. Exactly. It’s public. Just make the defaults all public. When I create a new file don’t make it internal. When I implement an interface don’t throw exceptions for auto properties. Low hanging fruit that just grinds my gears. Accessors are ultimately superfluous anyways, some languages don’t have them at all, and neither would most c# code if the goddmn defaults were public

[@IAmTimCorey]

I agree that it would be nice to have the accessor marked as public by default. However, accessors are definitely not superfluous. They allow you to make only the methods, properties, and fields available externally that you want.

[@yufgyug3735]

In my opinion all those changes are problematic. Mainly because they hide too much of what goes on behind the scenes. I think 'it just works' approach is a bad practice - you might be able to write some code, but when something bad happens, debugging it is going to be a nightmare if you don't know what's going on.

[@Jojo-tl4hq]

Every high-level language hides much. It's the purpose of these languages top hide things and reduce complexity.

[@DoubleBullet]

It’s not hiding the boilerplate, it’s eliminating the boilerplate completely because its simply not needed.

[@IAmTimCorey]

Of all the changes that I mentioned, the only hidden things are implicit usings and the "string[] args" in Program.cs. Nothing else is hidden or obfuscated. For example, in Program.cs, we used to have a namespace. However, that namespace was useless because you cannot actually call static void Main, which was the only thing that was in that file. The same is true for the class name. You can't instantiate the Program class. The same is true for the main method. You can't call that method. So we were pretending that it was a normal file just like every other one when in reality, it was totally different. It just disguised itself as a normal file. I don't love the fact that implicit usings are hidden. Same with the args. Those could be confusing. However, neither of these will cause a debugging problem. The only way you would have a problem is if you created your own method with the same name as a standard .NET method and then adding a using directive for it.

[@zzzzz2903]

@@IAmTimCorey _The same is true for the main method. You can't call that method._ - yes, everybody knows that. Entry point. Who is confused by that, should return to programming school - my point. Who is confused by that, should not do programing.

[@astroimagers]

Tuple. 6 years ago! I should just procrastinate and learn everything fresh when we're at C# 13. 😝

[@IAmTimCorey]

That would add quite a few things to learn to your training list.

[@duckyDz]

As long as people still use StackOverFlow and copy 5 year old answers ... I will always be concerned about syntax changes. In general it is not that bad and thankfully Microsoft gives us one of the best docs on the market to learn stuff. Still ... it does not make C# an easier language to learn if all this old content is still around. I am still baffled, when I talk to people, that they learn C# by old tutorials or spent a lot of cash on outdated books when MS is giving us everything for free. This has to change

[@XKS99]

Global using and switch expressions are ACE, rest are take it or leave it.

[@IAmTimCorey]

Thanks for sharing.

[@arrtv3139]

I've watched so much Tim Corey I'm getting an American accent.

[@IAmTimCorey]

I'm not sure if that's a good thing or not, but thanks for watching.

[@gbmarshall]

One change I would like - ability to have an option in the IDE to make your code case sensitive... your choice... so if turned on if you create Abc variable... it would assume that you mean Abc when you reference abc throughout your code.

[@gbmarshall]

@ghost mall say you are typing the name of a text box on your form, txtTextBox and then you type . and intellisense comes up - you have to capitalize the T for Text....

[@IAmTimCorey]

That's baked into the language, though, so it won't be able to happen. We base our naming around it being case sensitive. For example, if we wanted to instantiate a Person class, we could say "Person person = new();' and we would know that "person" is the instance and "Person" is the class.

[@gregwilson6980]

It would help to see examples whether than listen to the narrative.

[@IAmTimCorey]

This is a podcast, so visuals don't really work, but I did a "regular" video on the topic as well: kzbin.info/www/bejne/l4SxoqSQpr6HoZY

[@jasonfreeman8022]

I’ve used MS tools for 30 years. They always end up hiding things from the developer in the Gatsian pursuit of making software development accessible to non-developers. It ends up making things for the non-80% projects nigh impossible because they’ve hidden what you need to know. These changes are not “removing” boilerplate; it’s moving boilerplate. It will eventually bite you. When you need to do something exceptional there won’t be useful examples.

[@IAmTimCorey]

I'm going to do a video for Monday on this, but I'll explain why I disagree with the concept that they hid anything (or practically anything): here is the code from a .NET 5 Program.cs file for a Console application: using System; namespace ConsoleApp3 { internal class Program { static void Main(string[] args) { Console.WriteLine("Hello World!"); } } } Here is the same Console application in .NET 7 (I removed the code comment letting you know what has changed and giving you a link to more information about the change): Console.WriteLine("Hello World!"); That's a big difference. So let's talk about each line and why it is logical to remove it: 1. using System; - This using statement is at the top of every class file. Why? Not very DRY. You could say that is obfuscating things, but if you hover over Console.WriteLine, it still tells you it comes from the System namespace. Not really a loss here. 2. namespace ... - Why does this code need to be in a namespace? Nothing calls it. Basically, this is code for show, not for a purpose. 3. internal class Program - Why do we need a class name? Nothing calls this class. Again, code for show. 4. static void Main - Why do we need this name? Nothing can call this method. Again, code for show. 5. string[] args - Here is the one place I agree with you. They should show this. It is actually hidden and it shouldn't be. 6. three pair of curly braces and indents - Not necessary. For twenty years, we have lied to ourselves and new developers that the Program.cs file was a normal normal method inside of a normal class inside of a normal namespace declaration that just had an additional special purpose. That was never true. Main cannot be called and the only way to make the Program class "real" was to put extra methods inside of it and make things messy. What Microsoft did was they acknowledged that there was ceremony without purpose and they eliminated it. In their attempt at making it clean, they did hide one piece (one that new developers rarely use, but still). Everything else was absolutely unnecessary to keep. What exactly from the list above would you like to argue was necessary? By the way, if it comes down to "well, I like it the old way", don't forget that they kept the old way. You just need to check a box and it comes back.

[@jasonfreeman8022]

@@IAmTimCorey Thanks for the reply. My first reaction is that IDE's have come a long way in my time. Between intelli-sense, file templates, snippets, refactoring tools, project templates, etc. boilerplate code is trivial. So it's not really an issue. Now for your points: 1. Using declarations are important if you're working in a large application that has many namespaces and want to keep code verbosity down. Name collisions in large projects are real and explicit usage declarations can make managing those collisions cleaner and express your intentions better. Code should be written for other readers, not merely your own convenience. Also you will always have to make some declarations in non-trivial applications. Why do it one way for one thing and another for another thing? I spent 10 years working in COM C++ and it kills you because there are multiple ways to do many things. I don't want to see C# become C++ or Perl. 2. Again, namespaces makes code more clear. The explicit use of the namespace keyword makes it clear what entities belong to a given namespace and is easily discovered merely through code inspection. Without them you have to guess or poke around. This can break needed flow when researching a process flow or during debugging. Also, consistency in code is a virtue. You will always have to make some declarations If it's always declared at the top, I can always just look at the top of the file. 3. The class declaration isn't non-necessary. It is essentially a continuation of namespaceing and is useful in some cases. In larger projects, especially if there is heavy code-reuse (I mean your code is used as part of web site and a web server and a windows service and some jobs) the class name can be useful. It isn't constrained to the class "Program" either. This is just a default from the console application template. But the linker does need to find an export named "Main". That brings me to Main. 4. There are 8 variations on the primary entry point Main: // Parameterless Main() methods public static void Main() { } public static int Main() { } public static async Task Main() { } public static async Task Main() { } //Main() methods with parameters public static void Main(string[] args) { } public static int Main(string[] args) { } public static async Task Main(string[] args) { } public static async Task Main(string[] args) { } So the declaration, again gives you a lot of intent and some implementation options. Notice that some are void and others return int. These should all be included in the project template with explanations. This would go far to educate newer devs on how applications on Windows actually work. 5. Ah, you're coming around to my point of view 6. Necessary if you need to explicitly define the scope of the entities your declaring. Perhaps too many, but then between the IDE tools, readability and consistency, I would say they are necessary. Finally I would make a philosophical argument against some of these changes. Devs have an immense learning burden. If the language can do what you need it to (I'm not opposed to all changes, take lambdas versus old school delegates) why reinvent it? We have enough to cope with with tools, extensions, libraries, frameworks other languages and their respective retinues. Consider a typical web dev; There is SQL/No-SQL, platform language like C#, HTML, CSS, Javascript (and extensions like JQuery, etc.), TypeScript, React, cloud tools, containerization, and on and on. If the changes are genuinely useful over the life of an application, then perhaps, otherwise don't add to the existing burden with dubious changes. They may be attractive to new developers, but that new developer will become an old one quickly and needs to remain productive.

[@IAmTimCorey]

I'll let my Monday video do most of the talking, but I wanted to quickly address a couple of things here. First, all using directives aren't implicit, just the most common ones for .NET projects. You still have your using directives at the top. The only time you would have a namespace collision is if you are naming your methods the same thing as common .NET method names. Even then, you won't actually have a collision. .NET is smart enough to use the local method instead of the built-in .NET method. I wouldn't recommend it, but it doesn't cause a problem. Second, you asked about having more than one way of doing things. That's programming in general. We need to chose the best option for our situation. Why have foreach when we have for? Why have int when we have double? Why have StringBuilder when we have string? We have options because not all situations are the same. In this case, not only does the added simplicity make it easier to on-ramp a new developer, they also make it cleaner for smaller applications like microservices. For instance, instead of creating a full API with Program.cs, Startup.cs, and a controller for a total of well over 100 lines of code before I put actual code in my app, we can create a Minimal API, where the entire application including full CRUD endpoints in less than 50 lines of code in one file. That's a significant reduction in complexity that adds value.

[@catalinbadalan4463]

@@IAmTimCorey I always found Console.WriteLine("Hello World!"); with all the dots, brackets and semicolons waaaaaay too convoluted. Why not turning into something much more readable, like: "Hello World!" -> Console ?

[@zzzzz2903]

@@IAmTimCorey _For twenty years, we have lied to ourselves and new developers that the Program.cs file was a normal normal method inside of a normal class inside of a normal namespace declaration that just had an additional special purpose. _ But why? It was clearly documented, everybody knows, it's the entry point of your app. Clear and simple as it is.

[@mikebreeden6071]

Personally I prefer code that I can write a story with over code that saves some typing but tells no story.... but then they are making me write Apex anyway so I guess I'd settle for any C#.

[@rinzler9775]

I just hope they dont try and dumb it down - if people want to program toy languagrs they can choose basic or python.

[@IAmTimCorey]

There is a very valid argument for C# already being the "dumbed down" programming language (hate that terminology). We aren't generally dealing with memory, threading, or any of the other lower-level actions that languages like C expose. The point of .NET is to make a language that is easy to use to quickly build powerful applications. We get a TON of features "out of the box" to handle window creation, terminal messaging, common functionality, and more. And to be clear, Python is not a toy language. It is the leader in working with AI and ML right now.

[@tonyzaddo7910]

2:45 and still getting intro blurb. I am bored, the time cost of watching has exceeded the value of the information presented. Moving on!!

[@atari1040]

Adding new syntax so that GPT cannot replace devs :D

[@IAmTimCorey]

I know this is a joke, but Microsoft is actively training CoPilot on C# and other syntax so that it can be as helpful as possible. The good news is that syntax knowledge is not what makes a developer valuable.

[@bjarnenilsson80]

Yea top level statements ... if r/csharp is aything to go by this changes confuses more beginners than it helps, and here us why they follow an older tutorial ( from before this change was made) so ofc it doesn't mention the checkbox and bingo the beginner niw ends up with code ( even for an hello world console app) that looks different than the tutorial says it should, so ok thinks the user I've done something wrong, creates a new lroject ( ignoring the " do not use top ,evel statements" checbox because the tutorial does not mention it so "it must be an advanced feature" and still ends up witwhat he/she/whatever gender noun still seas as wring code, get's frustrated. Maybe the checkbox shold be " enable top level statements" and be unchecked by default. As we all know things change but tutorials ( esp video tutorials ) almost never change

[@IAmTimCorey]

Changes like this are always going to be confusing at some point. Unfortunately, there isn't a lot of help for that. Even if they switched the checkbox, if I defaulted to the new style, my videos would look different than what they see.

[@bjarnenilsson80]

@@IAmTimCorey true, which us why a default that changes " beginner experience " as much as this a Should be off my default ( at least for a few years imho. And you are good when it comes to making new videos when things change, a ot of peopke are not, and that is where the problemI described starts. Thanks for your reply and keep the excellent videos coming

[@owenreynolds8718]

The really weird thing is that for decades teachers have been playing with boilerplate vs. no-boilerPlate and it's long been settled that -- esp. since IDE's make it for you -- boilerplate is fine, even good. It's easy to say "your code goes in these curly-braces" and students aren't surprised when they have to deal with surrounding cruft elsewhere, or tweak it. MS even worked with Unity3D, so should know that. U3D started using boilerplate-free UnityScript (to be familiar to game-programmer/designers) then realized switching to C#, with it's extra required "using X; class {}"-stuff was just fine and not scaring people off.

[@catalinbadalan4463]

Only one question: why is Microsoft changing C# syntax so much?

[@IAmTimCorey]

Tune in to find out.

[@williammain3247]

It is a way to erase industry experience. Nobody wants any of us once we have a few years experience because only the last couple years of work experience matters.

[@IAmTimCorey]

Nah. If that little of a change erases your experience, you didn't really have any experience. Experience isn't about syntax. It is about your ability to create logic. In a 16-week course on programming in C# I taught at a local college, I would spend the first five weeks teaching the students about 90% of the syntax they would need. I spent the last eleven weeks teaching them how to create logic with that syntax. That was the important part.

[@UristMcFarmer]

If they really wanted to make C# easier, they'd remove the need to have a semi-colon at the end of every line of code. They're only there because compilers in the 1970s needed them. Our IDEs, instead of saying "there should be a semi-colon here" should instead say "end of statement unclear" when something doesn't make sense to it. Additionally, our IDEs should auto-correct casing where appropriate. Sure if you have two variables "myvar" and "myVar" in the same scope, it won't know which is which, but there's no reason for the IDE to say that it has no idea what "myVar.tostring" is. It knows darn well I mean "myVar.ToString()". For me C# is more like backspace-sharp.

[@IAmTimCorey]

No, semicolons are needed. C# allows multi-line statements. The semicolon denotes the end of the virtual line, even if it takes up multiple physical lines.

[@bernhardo1443]

Microsoft has a tendency to always bloat things up just to start all over again.

[@IAmTimCorey]

That's a pretty generic statement. I find that people switch back and forth between two points of views with any product. Sometimes, they bemoan the fact that the feature they want isn't in the language or IDE that they use. Then other times, they bemoan the fact that the features being added to the language or IDE that they use are "worthless" or "bloating things up". When it comes to these specific changes, they are actually removing a lot of unnecessary bloat. So your comment seems...off.

[@user-iu1xg6jv6e]

Did you lose weight? Anyway I think It's a good thing that MS is listening to the community.

[@SonerKOYLU]

The fate of languages is to change. If there is no change in a language, the language will die. The languages is lifeform, like human.

[@IAmTimCorey]

Agreed.

[@zzzzz2903]

But not yearly

[@IamGoen]

I'm all in for simplicity! (KISS).

[@IAmTimCorey]

Agreed.

[@kongvang8825]

These changes seem like it'll make c# less intimidating to newbies. I'm all for it. Webforms was the worst tbh.. please let's not go back lol

[@IAmTimCorey]

Agreed.

[@a-s733]

Actually , We need to ask the question why so many people fighting to hide the complexity which Microsoft creates.? Just look at back and check how many frameworks they have created and deprecated.? How much time people wasted to learn them for nothing.? Think minimal API please. They say all in one page. In one or ten page. Do not hide the real architecture from me. Less I know, more I am depend on the way you propose. The same for global using. So many problems with nullable. You need to deal with so many ? ?.?????? !!!!!!! . Can we say that is a positive change or just another portion of time to loose until you get to be used with them.?

[@IAmTimCorey]

What frameworks have they created and deprecated? You mean Silverlight, WebForms, and WCF? I guess you could add UWP now. But let's actually look at those. WebForms is still fully supported and will be "as long as Windows is supported" (their words). So is WCF (plus they are supporting a community open source effort to make WCF work with .NET Core). Silverlight was killed by Steve Jobs (I did a video on that). It wasn't handled well, but it also wasn't their call. So you've got UWP, which is still supported but not necessarily moving forward. What would you like Microsoft to do? Support these things even though the market rejects them? UWP was their idea for full-screen Windows apps distributed through the Microsoft Store exclusively and exclusively to Windows products (including Xbox). People didn't like that. It didn't help that it was tied to Windows 8. Even if you take these personally, and think that Microsoft is somehow at fault, I think it is ridiculous to say that people wasted their time. What's the difference between UWP development and WPF development? Less than 1%. What's the difference between UWP and .NET MAUI development? About 5% (less if you only deploy to the targets UWP supported). As for nullable, first, you can turn it off if you want. Second, it is designed to show you where you are assuming something won't be null. That's a MASSIVE issue for applications and they have an elegant solution. If you want to hope that your application handles nulls fine, don't use it. But if you want to make sure you handle nulls properly, you need to clearly state to everyone (not just the compiler) whether something can be null or not.

[@andrewfraser2760]

I think Microsoft have gone too far with the changes - pattern matching as an example just obfuscates code !

[@IAmTimCorey]

I disagree. Either way we are going to do pattern matching. It is just that before, we would write more complex logic to match the patterns and potentially end up creating duplicates of our data in an attempt to get the right data. Now we have a clear way to efficiently get what we need.

[@poganezz]

The real answer is at 7:12. Don't thanks me.

[@shariar13877]

These changes are good 👍🏻

[@IAmTimCorey]

I'm glad you like them.

[@santhoshsunkaraneni1387]

instead of verbally explaining the changes, would have been better if you could show us. Thanks for the information.👍

[@IAmTimCorey]

This is a podcast, so I can't really show things since there are people who listen only. I have, however, shown those differences in multiple videos on this channel.

[@user2kffs]

Feels like it’s being dumbed down

[@IAmTimCorey]

That’s what .NET is - programming dumbed down. You aren’t writing Assembly. It is designed to make things easier.

[@user2kffs]

@@IAmTimCorey I agree but the .NET 5 was the perfect balance in my opinion. .NET 6 minimal apis is where it went wrong. No need for exception messages then, just output "Call a senior developer" :)

[@IAmTimCorey]

Balance of what? Easy to use, but also keeps all the stuff I like the way I like it? Minimal APIs do all the same things full APIs do, but they are designed to be for microservices and other small API needs. You still have full APIs that are fully supported. You just don't need to create the full ceremony when you don't need it.

[@botondvasvari5758]

becoming a cryptic mess like react

[@IAmTimCorey]

Nah, just providing the needed/desired options and keeping the language relevant in a changing world.

[@rasmusb639]

Not all changes are good. Look at the default implementations in c# interfaces - horrible, and totally breaks the concept of an interface being a contract. We already had abstract classes, so I really don't understand this change.

[@IAmTimCorey]

I disagree. There was a specific purpose for adding the default implementations. It was to reduce duplication when upgrading interfaces over time. It serves one specific purpose. It can obviously be abused, but the intended purpose is a good one. Here is the spot in a video where I discuss them: kzbin.info/www/bejne/aJ24i2huj96oadk

[@jfftck]

I feel that usings hide so much, this is one area that Python does correctly, you must define the dependencies one at a time and it is discouraged to import everything using import * from __. I believe that explicitly defining the dependencies and the path that they come from allows you to read the file outside of a IDE and still be able to follow the flow. C# is very much tied to the IDE to be able to truly understand the code, which code reviews from the web browser can hide flaws much more easily. This is the largest flaw to the language.

[@iamjonas1025]

Hi, Tim, I am a fan of you, but for this video, you talk a lot without an example, next time pleas try to show us with the example. Thank you.

[@IAmTimCorey]

This series is called Dev Questions. It is a podcast that answers questions people ask. I've covered these topics with examples in other videos. This series is advice, not code-specific.

[@iamjonas1025]

@@IAmTimCorey Sorry about the early comment, I did not know about this series, most of the time I watch coding based on the tutorial, and that's why I expected some example or screen shut. anyways Thank you.

[@LiakatHossain]

I think your intro doesn't match the quality of your work! You could simply add some basic music instead.

[@yasser2768]

The main reason is that they have nothing left to enhance

[@IAmTimCorey]

Nah. Every new release brings new features that I've been wanting. For example, in .NET 8 they are working on making Blazor mix and match as needed between Server and WebAssembly. With .NET 6 we got Minimal APIs. On the C# language side, in C# 9, we got records, init only setters, and more. In C# 10, we got extended property patterns. In C# 11, we got generic attributes, required members, and more. In all of these updates, we've also received major speed improvements. There is tons left to do, but each update also makes our existing systems better.

[@AvinashKumar-dr1nv]

First comment

[@IAmTimCorey]

👋

[@paulomfgoncalves]

The problem is that now we age sooner and die later!!!! For me, THEY can even create some instructions in Chinese!!!! I have a lot of fun with the ideas of the Gods and the magic that the poor see in them!!!! C# feels like the European Union!!!! a spaghetti of free ideas but in the end they don't solve anything !!! 😂

[@IAmTimCorey]

I don't understand this comment at all.

[@paulomfgoncalves]

Follow the fashions without thinking and not contesting, do not criticize !!! The gods of C# have made another decision to evangelize you, obey !!! The world was all wrong and the new paradigm of the gods is now functional, change if you want to continue alive !!! 🤐 🤫

[@IAmTimCorey]

Sorry, that didn't clarify anything.

[@teckyify]

One of my biggest issues with Microsoft and C# is their attitude towards their programming languages. It's the same like towards all products they release, quickly create and forget. For them the language itself is the product. From a language design and developer respect point of view this behavior leaves a sour taste in my mouth. C# is probably the biggest junk heap of a language I've ever seen in 30 years of programming. No general language constructs or design foresight. Just keep adding syntax for every single little shit, without removing anything. By design this leads to the biggest junk heap ever seen. Sounds more like Stockholm Syndrome what you're talking yourself into. I fond it rather amusing and embarrassing.

[@blackenedsprite8542]

So not a MS fan then?

[@jakejake7289]

Just because a feature is there doesn't mean you have to use it. I take a minimalist approach. With each new release of C# there might be a couple of features I like and use. I am incredibly productive with C# and my code is easy to read and maintain.

[@senmafugu]

That is a strong abrasive comment coming from someone with decades in experience in tech. I'm 31 years old and I started when I was 22. I welcome changes and additional features always gets me excited.

[@IAmTimCorey]

Hmmm. Where to start? First, the reason Microsoft doesn't just remove things is because they want to actually support their customers. With your 30 years of experience, I'm sure you've worked on business applications so you know that changing an entire codebase to take advantage of a new feature is difficult, if not impossible. Being forced to do so for no good reason is even worse. However, Microsoft DID remove a LOT of things by moving to .NET Core, yet they still managed to support their existing customers. They added tons of new features, removed a LOT of dead weight, and greatly increased the performance of the code base as well as the developers who are using it. Second, "create quickly and forget"? What does that even mean? C# has been around for 20 years. They haven't forgotten anything. In fact, your argument about them not removing anything argues against this argument. You can't have it both ways. Either they create quickly and forget or they add new features without removing old ones. Third, the "no design foresight" is ridiculous. They have taken a language that came out before the modern web and they've transformed it into an efficient language that can run on practically any platform (Windows, Mac, Linux, Android, iOS, Cloud, IoT, etc.) That didn't happen by accident. You have the right not to like a language. That's personal preference. But then go make that language great. Add value to it. Do something positive. Don't just go looking for a place to complain, especially when you haven't spent the time to actually understand what you are complaining about. You aren't adding value.

[@jakejake7289]

@@IAmTimCorey Spot on!

[@ivanz6368]

To be annoying?

[@IAmTimCorey]

Nope.