Firstly, I love how both old and new conventions are perfectly valid. Zooming back to when I graduated from BASIC/QBASIC to C++... circa 1994, armed with only a book to reference and no internet... I recall struggling to learn what the heck all the boilerplate stuff meant-- #include stdio.h, using namespace std, etc. Being young and just starting out at the time, it was all pretty intimidating. I always felt there were some basic concepts that I was missing that my book wasn't covering. I remember throwing lots of time at trying to understand concepts that were really too advanced when I was starting out. As a result, it sort of pushed me away from C++ at the time, and into Visual Basic. So, although as a Sr Engineer, sometimes I appreciate the ceremony, certainly for someone just starting out, simple is better.
Oh wow, this video is a great explanation of the changes/features happening with C#. I'm new to both C# & OOP and I've been using PHP while coding in a procedural style for about 95% of the time. At first glance, this seems like a good idea to introduce coding in a gentle way by avoiding a lot of OOP and its syntax namespaces, class, using etc, but in the long run, this method could teach beginners the bad and very hard-to-break habits I picked up while in procedural code land while in the PHP camp and this could do more harm than good for beginners like myself who wants a career in development one day.
I am an "old schooler" who thought the top-level statements feature was senseles. However, you have made a compelling argument and you have converted me.
I completely disagree with why you think this is a good thing. Developing software is defined by a structure and proper syntax. When you are trying to learn something new and all the aspects of a C# application are missing and you don't have to put those things there, you run into issues when you need to expand on those magic things you keep talking about. Now a new user gets confused when they create a class file that has all the files, when you remove the basic structure of an application and make it happen magically, you make it harder for people to learn and follow the code. Like you pointed out about the Args missing and I have to magically know about them, makes me upset. Magic is now how I learn. I need it to have structure and make sense. I need to easily follow the code. This new way is not easy following the code and understanding what is happening. I know you think its less code, but it doesn't flow real well when it comes to the basic structure of a C# code of Namespace, Class and Methods. My first thought is how do I create that as an Async Main method? Do I have to go back to the old way? Now I would have to spend time trying how to figure out how to make the Main method Async when there is no Main method.
So I get what you are saying, but I think you are missing the fact that the old way was also not correct. It pretended to be the same as all of the rest of C#, but it wasn't. So what we taught developers was "this is what a method is and why you create it...but that's not what Main does or is for". We taught them that you can instantiate classes...but not Program (you shouldn't, at least). By teaching them right out of the gate that Program.cs is different (obviously), they naturally get used to the rest of C# operating differently than the entrypoint of the application. Before, that was implied, but confusing. Now you can't help but acknowledge it. As for async main, Main already is async if you want it to be. You just await any call you need to.
@@IAmTimCorey I think it's difficult to say that it's "Not correct", when it is what established the convention for every other file in your assembly. Program.cs is just a file, the same as any other file. It's merely the default startup object. That's it. That's all it is. You can change it very easily. You can have multiple Main methods in an application, and choose between them, which will be the entry-point. There is nothing special, or magical about the Program class. It's just the default. Whoever taught you that Program.cs stands up on some immovable pedestal, is wrong.
I am completly disagree with you because all the boiler plate code can be very overwhelming for a new user. This is also the reason people dont like Java because of all the boiler plate.. The new syntax allows for new users to learn the basics first and then learn aboved classes. Instead of getting everything shoved down them and program .cs class is very contradictory to how an actual class works. This is why pyhton is so popular with new programmers becausew you dont have to worry about classes and methods when starting out
@@primekrunkergamer188 It's not contradictory to how other classes work. It's just a class. There's nothing special about Program. It just happens to be the default name. The way I was taught, we did the basic "Hello, World" stuff in Main, but after that, we made methods outside of Main, and called them, rather than bloating the Main method. The concept of "This is the method that gets called by the operating system, when our program gets launched" was a day one concept. From there, it was common sense to keep that method as uncluttered as possible. The four lines of boilerplate that are added to the file actually go a long way to teaching the day one basics of C#. This is a namespace. This is what a namespace is, and why they are important. Inside the namespace we have the class. This class is called "Program", we can see in the Properties for the project that the OS calls this class when the program starts. If we change the name to Program2, we can see it update in the Properties. Inside a class, we have different types of "member"; this one, called "Main" is a method. Methods are small chunks of code that can be executed by name. The OS looks for a method called "Main" the startup object. We can see it says "Hello, World!"; this is called a string... and so on. Sprinkle in liberal amounts of demonstration of changes affecting the program being run. Now, I've known people to be two weeks into a C# deep dive course, and still not know what a class is. Not even writing within a method for over a week. The culture shock of writing your first class is a lot greater when you've had no boilerplate to use as a reference.
@@ApacheGamingUK I must say it is refreshing to see principled C# devs making reasoned arguments against these incessant changes to things that weren't broken and didn't need fixing in the first place. I agree, the pre-6 Console boilerplate Program.cs is a much more fitting introduction / entry-point to C# w/ namespace, using(s), class, curly bracket scoping, etc. Without that fundamental cursory knowledge, you really don't belong in C# to begin with. We should never shy away from it, especially not just to remove a few lines of relevant syntax. Terse code is nice, reducing nesting/indentation makes things cleaner (I've accepted and embraced file-scoped namespaces for example), but there is also overdoing it. A reasonable argument can be made this top-level stuff is overdoing it, and is causing more confusion than it is solving any perceived problems. I hate having to memorize exceptions to the rule, especially just to make script-kiddies happy they could spit out "Hello World" with a few less lines (keystrokes, really) of code.
The program Entrypoint is set in the project properties, and is easy to change. Recursion is an extremely valuable technique. Calling Main() can be useful in certain situations, especially when you're CLI-focused, and not GUI focused. You absolutely can reference and call this method, and there's no rules that say you can't. I'd say this is a terrible primer for a new developer, as it makes a lot of categorically false statements.
Yes, you CAN call Main. You shouldn't. Main isn't the place to do recursion. If you want to do that, create a method to do that. Go to statements are also possible, but it is an antipattern to use them.
@@IAmTimCorey Then say that in your video ;) I understood the direction you were coming from for this video, but you made a lot of false statements to get there. Instead of making statements that are factually wrong, just state that they are anti-patterns, that you *shouldn't* use them, like you just did with me! If I'm being honest, I had to double check that I wasn't getting you confused with someone else when I clicked through to this video 🤣 It came across to me as "person unfamiliar with the tools/language arguing for the style they're familiar with" which didn't mesh with your reputation obviously.
I think they are learning from how to make applications efficient from a development standpoint and yes, some of those lessons come from Python. There's a reason why 60%+ of developers use Python. It is easy to quickly use to get the job done. C# isn't going the scripting route, but being more efficient as a developer isn't a bad thing.
One unfortunate thing about top-level-statements is that they are a bad way to learn about accessibility as top-level variables are visible in (local) methods which they would'nt be in the classic way.
@@DanCojocaru2000 If you use the classic model a variable in static void main would not be visible in other class methods. But with top-level-statements all methods are local methods inside the main method and therefore there is no encapsulation in this direction. This is not generally bad but not good for educational purposes where the learner should experience real encapsulation and not just get told not to use the top-level variables inside the methods.
@Peter B. Well, if you use the classic model, then those variable would be static variables inside the class that contains static void Main, so they would be visible.
@@DanCojocaru2000 They would only be static variables if you explicitly declare them that way. If your top-level-statments would just be the contents of the main method the top-level variables would be local variables inside the main method and therefore not visible inside other methods. Try to look at it from a learners perspective.
I've been on the fence and one of your other videos you talked about this didn't really sell me. This was much more compelling, and I can't think of a reason not to agree. Good job.
I love the new structure since .NET 6. I have worked on versions from .NET 1.1 and I can say that this is so much better. It did take me some time to get used to it though. The new structure is less clutter and more readable(no unnessary braces and indentations throughout the file). I also like how it hides not so essential details to writing your application but does not completely remove them to the point that those who want to learn the inner workings cannot access the information. It's DRY, it's abstraction, it's simplicity. It's just great.
they could have left the static void/int Main(string[] args) at top level because having a return 0/1/2/-1 ... at top level is really weird. on the global using thing. the reason I don't like them is because they remove the "file can compile on its own" philosophy.
I agree on the top line. As for the file compiling on its own, that’s never been a thing. Every time you call out to a method, you have a dependency on a different file.
@@IAmTimCorey No you don't. That's only if you call a method that exists within a different file. I'm most used to using "System.CodeDom.Compiler.CSharpCodeProvider" to compile source from single files, although that's a bit outdated now. Still works fine for simple payloads though. When writing game mods, "Source Mods" are actually really useful, as they get recompiled each time they are used. So, any ABI, and any non-breaking API changes within the game engine are automatically resolved, without needing to release, and publish a new version of the mod. The game just takes that one single file, compiles it, and treats it as an in-memory Assembly.
11:20 so they realise all this NOW? after all these years of c# existing, now they realise the boiler plate sh1t is not needed? can u explain why they just realised that NOW?
I don't think it is that they just realized it now. It is that they have the ability to make this change now when they didn't before. A lot had to be in place before a change like this could be made.
I would go further and also remove the usings and the namespace from the class files. I actually always use namespaces that stick to the folder structure. so why repeat everything in every file?
I imagine it could be useful where i add an extension to multiple classes that do the same thing, but do it differently. For example, let's say i want to add a new comparison operator to multiple classes. My new operator might do the "same thing" in all the classes, but would be implemented differently for each one. In that case, i might add one file for the operator, in which case i'd need a namespace to add the right code to the right one. In most cases, however, it does seem redundant.
Even further you could go so far as to make it a file scoped class and have it infer a whether it’s a in an interface, abstract class or enum based on the name. Definitely a bit to radical but at least interesting.
Yeah, At the start, I was getting frustrated with the new way of .NET 6. However, the more new project I started, the more it make sense. It is just the same, but cleaner.
Generics, Linq, async-await... Those were great improvements. But the latest changes to the C# language are mainly about saving a few characters. It's ridiculuous and just getting on my nerves to spend precious developer time just to find out what useless changes have been added this time again to the C# language. At least I get paid for it by my employer. And then there are those colleagues who rewrite the whole code because they think these useless changes would improve their code quality.
I wonder more whether you put back possibility of using (eg. serilog) logging during app startup (reporting misconfigured parts when starting container) that was possible way back with webhost
Im a relatively new developer and still have a good memory of how i learned to code. For me the static void main and his friends was a huge help and motivation to learn. Every time when i had to create a learning project these keywords(static, void , public ect..) were right there and yes it was annoying and scary first but then i was able to track my learning progress with these. These keywords were like a path for me to take and understand them one by one. Im a bit sad that the new generation will not have the feeling when they sit down one day and look on the main method and be proud for understanding all of it. This feeling gave me a big boost at the time and a good milestone for the learning process.
From a learning perspective IE someone who learned C# within the past year for work, the old program was more useful for learning. Especially since I was relatively new to OOP. I do like the convenience of the new program file, but I think for beginners that boilerplate is actually important to understand.
It is, I struggled with startup not being present whilst doing Tim's mastercourse that uses startup etc. All beginners should avoid these changes until they have learned the old ways
As someone who has recently been learning C# on my own, I will say that whatever advantages these changes might have had for new learners are pretty heavily offset by the fact that now all the tutorials from before a certain cutoff point don't work the way the websites and books say they will. Learning how C# has changed and how to modify tutorials to accommodate those changes is pretty exhausting when you're brand-new and don't understand the documentation yet.
The thing I miss the most is a sense of encapsulation around the main method lines of code. When you added the Test() method it made it obvious to me. What if a new coder was putting main lines then a function then more main lines then a few more functions then more main etc.. Would that run? Would that be easy to read?
I think the key here is to treat Program.cs differently, which this now makes clear. We used to put methods next to Main, but that's not really a good solution. It pretends that the Program.cs class is a normal class. As for putting methods in Program.cs now, yes, that will work. The reason it will is because you are creating local methods. A local method is a method inside of a method. There are limited uses for it, but it can be useful (LINQ is a common use). They've been around for a while before these changes were put in place.
The methods have to be past the last lines of code or it won’t compile. I do think this is somewhere that more clarity is necessary however I’ve also kinda come to the conclusion that if Im doing something where a method is needed in program cs or just organizing it with a method i should probably be putting that method in another file. It either ends up being some sort of extension method or startup configuration object but if it’s more than one or two things then it adds too much clutter to program.cs and in cases where it’s 2 or less it should be fine to inline them instead of using methods. That’s more of a personal preference but the tooling also lack clarity around this and inlining methods inside of your entry point code does feel weird.
@@IAmTimCorey Hi Tim, thanks for replying. I agree with you about just having to treat Program.cs differently. It's unique and should be treated as such but I guess I'm too used to other methods sitting next to main within the class and namespace. I just want there to be a little more clarity around the fact that if you put a custom method in Program.cs - tell/show the user that it is a local method even if they don't realize it is a local method. They may not intend it to be that way and a hint to put it in another file would be good.
I know it’s unwarranted, but it freaks me out to not see using statements. It’s like “Hey, I can’t run this without using statements.” I know that’s not true, but still weirds me out.
Making functions that are only used internally no longer visible is conclusive and makes sense. (If I got that right) BUT, Names Spaces should stay the same as before, because I like to decide for myself which scripts should have access to it or not.
@@IAmTimCorey That makes sense. Thank you for the good information. I myself still use VS 2019 because it is almost impossible to migrate larger projects from pre 22 to VS 22 without having to invest thousands of hours in troubleshooting and bug fixing again.
Great video. I'd say, top level statements and global usings made C# the perfect first programming language to learn. No need to awkwardly say "we'll discuss it later" when a student who never wrote a line of code inevitably asks "hey, what is a namespace" or "what does the `static void Main(string[] args)` mean" after they see a new console app.
You can write a method inside of any method, not just Main. They are called local methods. There isn't a huge need for them, but they do serve a purpose.
Thanks for all you do Tim Corey! I like the idea of streamlining the Program.cs file but to me it's just more magic and to me magic is likely the root of many bugs (especially unknown bugs). I am leery of frameworks and try to avoid as much as possible (which is why I despise the idea of) modern/current-frontend development. Until things are better understood, people rely on magic to get things done and often I find people are resistant to change because ultimately, change may force them into uncovering and understanding the magic that's been hidden. Before someone flames me, I understand most languages of today are "magic" over assembly, which itself is magic over binary, which itself is magic over circuits and electrical impulses. 😉The magic I'm referring to is that which exists at the framework-level.
Interesting. I hadn't thought about it in that context. I still prefer explicit, but I can see your point. I think the difference for me is that with a property, we see that as the stand-in for the private backing field. With args, there is no object in front to indicate that it is there.
I think you're also saying tbat program.cs should really just be figuring out args and then passing execution to a related class, which I agree, with, even though I am guilty of making small programs in program.cs, only. My only fear is that the open "script-like" nature is going to lead to more of this, not less. :(
True my only gripe is the allowance of local methods in that file. Ideal Program.cs would look something like: await new MyConsoleApp(args).Run(); There is rarely a need to have anything else in the entrypoint file. The number one confusion of C# novices stem from the fact that main() is in a class and they don't yet know what that is. Even worse, the class by its nature should be static internal and it's never been by default, so you can do new Program() and confuse yourself even more.
@@IAmTimCorey I am just saying that the format of a new program is now script-like, and may lead to new people just putting everything in Program.cs, because it's kind-of more like how you would setup a scripting language.
"people will...". C# is for employees of companies. nobody, other than someone who uses c# for work, will write c# for fun. It doesn't run on microcontrollers, you don't learn it for big data experiments, students of maths don't use it. Employees have bosses, and code reviews, and style guides, and legacy projects to drop junior devs into. Those train the employees the best practices. If they're missing, it's an organizational problem and you'll find bad code regardless of theae changes. And the other group is unity developers and that tooling has tons of boilerplate and doesn't move to newer c# styles. So we're fine.
For me personally this still seems weird and wrong. I can understand the concept that when the application is loaded the system is going to execute the main method and we shouldn’t and don’t need to call it ourselves. I think that’s a lot better than having the format and elements of a C# file be totally different only for this one file. And making the default setting be for this style optimized for beginners is silly also. At least give us a system level override to the template system to say we are not a beginner and want the traditional version. It’s not like you are saving the developer typing the code, it’s provided. Perhaps beginners should be encouraged to use REPLs or Jupyter style notebooks to isolate learning rather than making the vast majority of template users select non-defaults or have to go back and change settings and retype those lines you tried to save them.
Hi TIm, This is completely irreverent to this video. But what is your take on the 'wso2 API Manager' for Api Management. Will Api Integration Become easier if we use this. Looking forward to hear your opinion. Thank you.
I think old way, shows oops way to start application with proper code i.e. namespace, class etc. --- Also with new approach , how to pass args required when app first run ?
I'm afraid I disagree. Top level and implied usings are not an improvement. They hide certain constructs that newcomers really should understand. Not everyone that learns C# has a computer science degree. It also makes the transfer to/from C, C++ and Java more traumatic. I could just be getting old but I believe change should make things clearer and I don't think this does. Still keep up the great work. 🙂
How can 12 lines (of which 11 do nothing but repeat project defaults) be clearer than one line that does the actual stuff you want? Newcomers need to fiddle with the code to learn, not be lost in boilerplate that effectively does nothing. Once they start a new .cs file, THEN it's the time to learn how files interoperate and what namespace and class is.
@@bobweiram6321 How is a new console app not the perfect playground? Has elitist gatekeeping not been a downfall of enough technologies already? Before .NET6 it was always easier to do simple prototyping in node.js rather than spinning a new c# project, now the code is still worse but not overwhelmingly so.
I think Microsoft is trying to do more things for developer, this change remind me when I writing Python, you don't need class or method, just a print('hello world') and done. Like jQuery's motto is “write less, do more”
Hi Tim, could you please add some chapters to your videos? They are pretty long so this would be very useful if you know something but would like to refresh your knowledge or learn only things you don't know.
Main is a very old convention from the earliest C. I believe Main was callable from another program, that is, you could call an executable from another executable by the name of the program. Your call would then be internally directed to go through Main first. Main can take parameters because you could call an executable with those parameters from a completely other executable. So it's for external calling, not internal calling. Can anybody prove me wrong? The early C authors wanted all there programs to be as interoperable as possible, each potentially a component in some much more complex combination of programs. Simply, each executable program was in fact a function.
This seems to be nice in theory, but I highly doubt it will be industry standard. Somehow people hate simplicity, need strict structure and files with endless lines of code. In the end, all of this stuff is just syntax sugar ... like most stuff that get's added to C# lately.
if implicits usings are fine, what was the reason behind having explicit usings before? there must have been one even if its no longer deemed valid reason
I think there is a bit of confusion here. Not every using is implicit. Just the standard ones we almost always use from Microsoft. Before we only had one system (explicit). Now we can have the standard Microsoft usings as implicit while making the rest explicit.
Tkanks for the video great topic as usually I was thinking why I get that weird thing that some methods can be null and get those warnings (never crashed once) but as I think about it that makes sense if something can be null first make sure it’s not then do something. Gonna come back to my apps and do those checks. About the topic I like the idea of less code if we do the same. I know you didn’t mention it but having in blazor this one file with using statements lovely. Don’t need to have those 12 or more lines at the beginning.
Not a "lie". Just a place indicating where to start. If you prefer the new way then that is fine. That's what this comes down to. Preference. Just don't call it a "lie". Comes across as clickbait.
Top level statements we only a meager small scoped change. The REAL paradigm shift is the pattern matching and functional programming they have been introducing. But also a bigger topic of discussion, as the older users still think of C# to be nothing more than a mix of C++ and Java.
Yeah, it is supposed to only be for one purpose (running your app), not for the logic as well. Ideal is to follow the Single Responsibility Principle (SRP) from SOLID.
Год назад
I did not like the new style because there wasn't a good way to do integration tests. The service setup and configuration were all jumbled into one 'invisible' method. At that time even ms documentation was suggesting to go back to old way for running such tests. I do not know how it is right now. I did not create new projects with newer .net versions.
Yep, they solved that problem. Here's an answer with the correct way, as well as the original workaround (partial class Program): stackoverflow.com/a/70645399/733798
I understand that's not as intuitive, but we are also talking about more of an edge case. The number of people that are doing integration/end-to-end testing up through Program.cs is fairly low compared to the overall usage.
I think there are some guys at Microsoft that are aimed to bring every other languages features (e.g python, ....) right into the C#. Microsoft is trying to gain more reputation by doing these things. Entry-Point is Entry-Point after all. Programmer doesn't needs to write it by his own. By any means it gives him the insight behind the execution flow. every single executable file in any operating system has one Entry-Point. We are trying to hide it for what ? In a python projects I always have this confusion "Which file is the main executable .py ?" I definitely need a manual to run the code. It's C# dude, a language based on C++, not Python. I'm using this templates for testing small functions used in other project it looks fine because there are no more brackets; but I hope that it goes for just experimental purposes, not for changing whole language design.
"The number one thing I want from C# is for one of my code files to work differently to all the others" said literally nobody, ever, before Microsoft introduced top-level statements and everyone decided that if Microsoft are doing it, it must be good. It's cobblers. They're created an incredible language, but now they've got (almost) nothing useful left to do and they can't just do nothing, can they?
I don't like top-level statements. I like the goal, but I think the implementation is very poor. It's C#, so code goes in functions, and functions go in classes. Telling new developers that the Main() function is a 'magic' entrypoint for the program shouldn't be a big deal, it's not hard to understand. Making Program.cs special by hiding the enclosing function and class just introduces different magic that new developers will encounter very slightly later in their learning process, and, worse, I can't use the change to clean up any other file. I've got a heck of a lot more other files than I have program.cs files, when they wanted to make Program.cs easier to understand, they should have done it in a way that provides benefits both for Program.cs and for other files too. I'd much rather have namespaces implied by the directory path of the file unless a namespace statement is present near the top of the file, and have the class name (defaulting to internal rather than private) implied by the file name unless a class statement followed by a semicolon (no brackets around class members) is present at the top of the file. That way Program.cs is reduced to a single static void Main() {} function that has an obvious namespace (the name of the project root directory, e.g. ConsoleApp1) and an obvious class name (the name of the file, Program), so it's easy for new developers to understand, plus the rules they learn there apply to every other code file as well. More importantly it also eliminates the first two levels of indention in all my files, or if I prefer the indented style I can still do that and include multiple classes in a file.
Great Video! ...but I think it is the other way around... The new way is a Lie, but that is a good thing. Obviously, C# got a lot of flack for needing a dozen or so lines before you can write a single line of code, so this an attempt to compete with languages like Java Script and Python where you can just start coding. We did actually "Need" those lines, because we didn't have global usings, or default namespaces, etc... Now they are optional, and you can, for the moment, do it the old way if you really want too. I don't like changes, but this is a good one!
I like knowing the name of my base namespace, especially when my solution contains multiple project entry points and it's not always going to be named after the solution. Doing ctrl + shift + f "static void main" to find the entry point is faster than checking the project properties. Seeing string[] args makes sense if you're used to executing commands from console. I see no advantage to hiding the args, you just have to kind of know that they exist; I think that's kind of dumb. I don't care if it's "cleaner". I don't care that some lines were eliminated, I see no advantage; feels like a downgrade to me. I don't like the change. I would argue having "Using System;" is a benefit for new developers because they can wrap their head around the idea that methods exist in a package; they don't just come from the nether. I'm not on the bandwagon to eliminate everything that is implicit. I don't think implicit automatically == bad
I agree that just hiding things isn't a great strategy. I'm still a fan of the new way of doing things, I just think it could use some tweaks. This doesn't set you up well for multiple entry points to the app, but that's not a typical use-case. In that case, along with a few others, I'd recommend using the original layout, which is still included and supported.
As for the changes to Main, years ago I wrote a scripting language that used a C-like syntax and worked much the same way with not having a Main function though you could write and call functions. For much the same reasons, you can't (shouldn't) call it, the compiler didn't need it to make its life easier, etc. So why bother with it. So I have no problem seeing that MSFT finally caught up to what I was doing in around 1997 ;) But at the same time I will say this isn't a terribly useful change one way or the other. Seems they just traded one bit of magic knowledge for another bit of magic knowledge. In a new code base I'd probably use it. Adding a new application to an existing code base I wouldn't as I value code style consistency.
Thanks for the video. Seems like a mundane topic on the surface but clearly not, judging by the comments. Things should be more accessible and less bureaucratic. MSFT could certainly improve in this regard which is what they're doing People gate keeping the old way is so odd. Go program in assembly and yell at kids to get off your lawn if you have such an aversion to incremental improvements and QOL changes
Just disable top level statements and you have a "proper" Program.cs I don't much care that they simplified the Startup file away, but trying to find info on services and middleware is hard when MS still only has examples and tutorials for pre-6.0 unless you dive to the end of the specific version reference pages. The changes were steep and there was little to no announcement or "here's what changed" documentation (at least from MS themselves).
I'm not sure what more Microsoft could do to announce the "here's what changed". They wrote an article on it ( learn.microsoft.com/en-us/dotnet/core/tutorials/top-level-templates ) and then they linked that article in the Console app template. They also wrote blog posts about it, did videos on it, tweeted about it, and more.
If we listen to people who preach this "no change for helping 'noob's" what will happen is simple, the language would slowly but surely die, so then this people would become king's over a grave, or would need to learn those 'cheap' scripting languages to find a job. The market evolves, C# needs to evolve too, when is easy to code we can produce more, we can train more people and bring more ideas to the community, stale water brings nothing to us. We should absolutely discuss the changes being made or planned, but just say "change nothing, noobs should suffer as I have" is not smart. As always, thanks Tim for the content.
Using your own logic, you might as well remove typing safety and the entire compilation step. Beginners hate declaring types and compilation step because they don't understand the advantages of type safety and compilers. All you've managed to do is turn C# into another Python and JavaScript with no real advantages. At that point, no one will bother with C# and it will die even faster.
"die even faster"? .NET is 20 years old and is growing in popularity and usage. And while they aren't turning C# into a scripting language, it isn't a bad thing to emulate some of the things that make Python so popular. There's a reason why it has such a large market share.
So far watching 12 minutes of the video is about nothing. Sorry I expect to learn something valuable on your channel in a serious and straightforward way but this video this is just talking about nothing with clickbait video name. 13:30 talking about string[] args being the only hidden thing is not true because there is also int return value from the main function which is the UNIX return value of the program 18:00 doing function definitions inside functions is a nice way for spaghetti code development. This was all wrong in python and with these top-level statements, it's trying to look like Python. Having the ability to have everything run as a script does not force you to think of splitting it because you don't know why and you don't know how to call the code in the automagical Program.cs when you are new in programming. It creates a new exception for you in the process of learning because when you learn it the top-level statements way, it's all different everywhere else in the other parts of the application. Having StartUp cs or similar stuff is not about DRY because it's used once but it's about single responsibility principle and readability - not having one main with 1000 lines but split it into logical parts. You are suggesting that when something in the application is used only once, it can be inlined. That creates nice spaghetti code. Sorry leaving at 24 minutes, this video is not good.
That would fundamentally change how C# operates and it would break LOTS of existing code. None of these changes are breaking changes. Microsoft tries hard not to do that. The semicolon indicates the end of a logical line of code. The word "logical" is important there. When you wrap code onto more than one line, that's still valid C# syntax. The semicolon is what tells the compiler when the line is actually done. Removing that would mean that we would either need to go back to one physical line is one logical line only or the compiler would need to be entirely rebuilt to figure out when lines are actually completed. That would be REALLY tough, if not impossible, since there could be multiple interpretations of when a line is done.
I don't like the new style simply because i got my start back in the good ol' days of .net framework. It's ok for simple scripts, but i don't think i would use it in a real world application with command line arguments and a lot of main logic. If microsoft ports winforms to linux i'll pretend to like it though...
I get it. Personal preference and what you are used to are strong influencers. I've definitely already seen value in it in real-world applications that I've built. As for Linux, I don't think WinForms is coming (since it is tied to Windows libraries), but Uno and Avalonia are on the Linux desktop.
I can't agree with everything. as if this particular video is not prepared properly. there is no historical information, why it was designed so initially, the evolution of the .NET platform and c # itself, what it was compiled into and what it is now, etc., etc. Are you saying the Progarm.cs file is an entry point in Serbian? i.e. everything is compiled to CIL and there is only one c# file with c# code as an entry point?) in general dislike
Most of that does not apply to this video. As for the entry point being the only starting point of your app, yes, that is correct. You can technically change it, but that is where every app starts unless changed.
Did channel owner understand how configured in old style solution and multiple enty points? This video show low understanding for most of style or patterns of configuration ...
I'm guessing you made this video because you know the decision to remove this boilerplate code was controversial. I believe it will hinder many new programmers because not only is the code meant to explain the why and how of what you do, it also signposts your code. If they actually did this to make code easier to read then they failed.
New console is much more straight forward. When I want to do something in Console its obviously very temporary anways, so I dont need top level statments, main, brackets. Just show me the money, let me just write the code I need. Thats it.
I don't like top level statements, because you can't easily add classess and structures in the main Program file to play around with things. Even for real projects, I often like to start with the basic console project and start building project architecture from scratch starting in the main Program file. Top level statements prevents you from doing this. And also the one file looking inconsistent in the project is not my cup of tea. I like the other new features though such as global usings, new WebApplicationBuilder and so on... Oh, and I hate nullability checks and always get rid of them when I can, but I realise I am in the minority here...
I love the new structure in fact I think Microsoft should have went further. For example the majority of the templates still contain namespace Xyz { } instead of namespace Xyz; which would save an indent
no, just no. now program is basically a python/javascript file without any structure, while the rest of the language works differently. newbie wants to learn c# ? take one more day and learn properly. it will benefit when learning other languages too
That's not what is happening. There is absolutely structure. Yes, Program.cs works differently than other parts of C#, but that was ALWAYS the case. That's the thing I was trying to communicate. When is the last time you called Main()? If the answer isn't never, it should be. So we have a method that wasn't created for the purpose that all other methods are created for (reusability among other reasons) inside of a class you should know not to instantiate (unless "normal" classes) with a namespace that is useless, since no one should be accessing Main or Program. As for new developers learning C#, .NET absolutely should be working to make it easier to start C#. Do you want a relevant language or one you like that is no longer developed? You can always use Delphi if you want to take that step back.
Uh. so Maybe you actually want to embed this app in a larger program and call its Main() from the larger project... Now suddenly them hiding all this is not doing the developer a service.
Why would you embed an entire application in a larger one and not just call it like a library? That seems rather edge case at best. More like a “you could but you shouldn’t”-type of scenario.
Startup.cs is bullshit. The Program.cs was almost empty and some random things went into a separate class. However top level statement for a web project doesn't work well because you actually need methods in that program class. Setting up a web project for maximum simplicity is not the right thing, we should not optimize for demos. It surely makes sense for a Console app but for a web app I expect people to know what a class is.
@@IAmTimCorey well because otherwise we're back to Startup.cs. I want to have a method for configure services for example. I see no need to put it in a separate class but I do want it in a separate method. In any case if you argue that it is correct to put this method in a separate class you should argue that this class should be created by default (yes even with a single call to AddRazorPages in it) because one thing's for certain - you'll register more dependencies
when i first started learning c#, .Net 6 was not out yet. i had such a hard time understanding the point of Main. the fact that i am also self taught definitely did not help in understanding either, but still, .Net 6 is just vastly superior imo.
@@IAmTimCorey So, last comment for the evening, but this is a perfect example of what I mean. This person couldn't make sense of what is a core concept of OOP, not just C#. Classes, usings, namespaces, entry points. To them, this Program.cs abstraction is "superior". Why? Because now they don't have to understand some of the most core fundamentals? They can treat C# as an abstracted magical scripting box? They can skip the "hard" part? Main as the entry point (can still be forced in 6) is a core concept to understand for any language, be it C, Java, Python. Now this person is going to be stunted in their understanding of the language for as long as they can get away with ignoring the need to dive deeper into the language. Treating, or encouraging people to use C# like a scripting language is only hurting them more than it is helping them.
This is all a bit of nonsense really. Namespaces only really became a thing because people were mistakenly using the wrong variable from time to time. Okay, they serve a bit of a purpose in grouping stuff together sometimes, but if you write decent code, you don't really need a namespace. You can use a well written class for that. Secondly, Main shouldn't be void, it's never been void and the OS doesn't see main as void. The OS uses eax for a return code after execution and if your entry point is Main, you need a return code. Okay, so main isn't the REAL entry point, but it's the only one you have in C#. Losing the main function/method means you also lose where in the source file execution starts. For many people, main might be at the bottom of a source file, with there being many methods positioned above main that's even before you get to the arguments that main takes, which in reality, the operating system passes you 3. An argument array, an argument count and an environment array (which many don't realise that you get).
@@IAmTimCorey Things are encapsulated into classes, compiled into libraries. In C++, the only names you see are the ones in your include files. Code should be broken down into compilation units and classes to form libraries. The applications I write are written so that things only see what they need to see, nothing more. You don't need namespaces for that. You can use them if you want to, and I do from time to time, but it's not a big deal. I guess where you don't have headers to define things, like in C++, it's a bit more difficult, but project references roughly gets you there.
I disagree. Understanding an application's entry point method is essential and shouldn't be avoided. In addition, the "Main" method can return numeric values, not just "void". Change to "int Main" to have an exit code for your app. That exit code is especially useful when calling your console app via Process.Start and consuming the Process.ExitCode value. Using top-level statements just confuses that. Top-level statements may have a place to teach some things by bypassing others, but overall, they should be avoided, by new developers especially imo. I have been writing code professionally for 30 years and can really code with or without top-level statements. However, I choose to not use it because it hides the actual entry point method, and makes less sense when returning an exit code.
As a systems architect, I'm mortified of the back-doors that top level statements open to less skilled engineers in my teams. The ability to have running code outside of modules (and therefore exempt from UML mappings and unit test fail-safes) can introduce hard to detect circular logic, akin to the ones introduced by static method and singleton pattern abuse. I have no issues with top level statements before DI bootstrapping, such as the use case depicted in the video but anywhere else it's just spaghetti waiting to happen. If only that toggle about top level statements could be enforced only on the application entry point and nowhere else, then I'd be 100% on board.
First, I would hope that as a system architect that you would understand that this isn't code running outside of modules. Main still exists. It just isn't shown because it isn't necessary. You can still model it and you can still test it (although testing Main is more integration or end-to-end testing). As for top level statements anywhere else in the app, they aren't. They are only the entrypoint for your application. There isn't a way to make any other file act like Program.cs. This is just for entrypoints. So it sounds like you should be 100% on board then, right?
@@IAmTimCorey Having never used this feature before in production, I was unaware that it was restricted to the entry point of the application. At a first glance it looked like C# moving towards a hybrid paradigm model like python and php, which is very problematic to me and one of the reason I stay away from these languages for big projects. If this feature is restricted as such then yes, I have no issues with it.
I think this is unfortunate that MSFT is softens structure of c#. Nothing wrong with "old" way. I guess this is to appeal to newcomers, who are not very savvy and don't have strength to understand logic behind "old" way. This is so common to new generation of developers...
But you are arguing against the very purpose of .NET. It is designed to make programming easier. That's the role of a high-level language. That's why we have built-in libraries for all of the "hard" stuff like connecting to an API, authentication, creating windows, handling moving people to HTTPS, etc. Should we pull those things out too, since they were put in to appeal to newcomers? For example, this line was added in .NET Core: app.UseHttpsRedirection(); We used to have to write that code manually. Should we remove those features because the old way allowed you to have more control over how that's done?
@@IAmTimCorey I'm not saying that libraries for hard stuff is bad - quite opposite - this is part of what makes .NET, C# ecosystem very strong. I was referring to conceptual things. I have lots of interactions with jr. developers. What I notice - there is an erosion of fundamentals: for example (not limited) - newcomers are avoiding things like OOD - polymorphism, inheritance, encapsulation. Very simple and elegant projects that could be done in right way become full of accidental complexities and unintuitive approaches. I suspect this is influences of scripting languages like JS. I always bring this analogy - .NET & C# - it is like piano. And you can play anything on piano => you can develop practically any algorithms, systems in C#, .NET. It comes with certain complexities that needs to be followed, otherwise results will not be good. Piano is very hard to learn. C# is harder to learn compared with some other languages - but this what makes software better as a result.
Alex this is very much the "I suffered so everyone else should too" fallacy. Should Assembly writers scoff at you for using C# in the first place? That's also the "old" way but kids these days are using modern C# instead! This doesn't have to be for newcomers. Programming should be easier and engineers shouldn't get bogged down with the bureaucracy of the framework for no reason. When was the last time you made your own string builder or http client or dictionary implementation? Are you a worse programmer because you aren't reinventing the wheel? Or are you a good one because you know which tools exist and how to use them regardless?
No, dude. Hiding is not truth. The argument being that when learning, it's better for you to not know the "automagic". There is no magic. This is such a condescending attitude - we know better what is best for you kind of thing. As a beginner it was always a puzzle to understand what main does. To truly and understand how things work. The interaction with the operating system. To look for more. And in a way..the old style was better, because it made me ask why is JAVA/C# so different than C++ or Javascript at the beginning, for example. What is so special about OOP? Why did they choose to do it this way. I think your argument is that it's less lines of code and indentation for playing with variables and stuff, which could be valid, but don't make that into "it's less of a lie". You are lying to yourself.
Nah. Tons of things have been built. Those who argue online are a small minority. For instance, even including my replies on this video and the fact that people posted more than once, the ratio of comments to views is 1%. That means that even if we said that each comment was a unique person, out of 100 people who watched the video only 1 said anything. Yet we look at that 1% (which probably more like 0.3% since I reply to almost every comment and then people comment more than once) and we say "those people represent everyone" when in fact, they represent the VAST minority. I'm saying that in terms of who is talking and who is "getting work done", not on what people believe about the topic. Also, don't forget that while I have over 350,000 subscribers, only 15,000 have even watched this video so far. That means the other 96% aren't even watching this video. They are doing something else (hopefully great work).
I could never understand what is the point of Startup.cs. It always seemed like such a random piece of overengineered complexity which only served to obfuscate how the DI setup actually worked.
This is what I hate about C# development, and I daresay modern development, in general. "Top Level Statements" really add nothing other than breaking existing structure. Then, the gotcha computer geeks, who seem to gravitate towards technical interviewing, love to throw it in your face that you aren't aware of something like this. By the way, I have stood up in the middle of an interview and walked out because someone insulted me because my definition of "boxing" differed from theirs. I finally started my own consulting business because I was tired of getting lambasted for not using the latest coding paradigms or using the latest buzzwords. Life is too short to worry about that crap; try focusing on making bug free applications.
lol. I'm not in love with everything they did (hiding args, implicit usings), but I've already experiences the benefits of the cleaner Program.cs file and global usings are amazing.
I disagree comon top level feels so cheap just like they way js and python hides abstraction the way other scirpted language feels cheap now dotnet will feel so cheap just to satisfy those noob programmers need who started their programming from scripted language
@@Box-of-hats what will noob programmers learn if programming language did everything for them will there be difference between programming and scripting this way.
That’s not an argument against them. That’s just a preference. And programming isn’t supposed to be hard. That’s the whole point of .NET - to make it easier. Otherwise, you would write in Assembly.
@@IAmTimCorey there is a difference between compiled language and scripted language. Compiled languages should be explicitly written. We should not make compiled language like a scripted language just for the sake of making it easy. The point of dotnet is not making it easy but to provide clr for the common language. Dotnet was supposed to make it easy for the code to run under the CLI not to make it easy for the noobs. Programming is a software engineering not a toy to play with by the kids (to make it easy).
All we are doing is satisfying the needs of noob programmer who comes from scripting language. We who have started from compiled language doing this for 10 years we know how it should be and top level programs are not the way it should be.
So it's just for looks? I think this is great. These "noobs" that just want to start coding will not get confused with all this strucutre that i'ts really unnecessary. If you are a senior developer you should not be wasting time worrying about this stuff.
So your ideal situation is to make the language less accessible? I'm not overly bothered either way, pros and cons on both sides, but if your main gripe is 'now newbies can use it as well' I don't see a great argument there
@@mikeconey2 if senior programmer actively endorses such stupidity where will the programming community head. After using all the programming languge I feel in love with dotnet only and they will pollute dotnet too which language am I suppose to use then afterwards.
Firstly, I love how both old and new conventions are perfectly valid. Zooming back to when I graduated from BASIC/QBASIC to C++... circa 1994, armed with only a book to reference and no internet... I recall struggling to learn what the heck all the boilerplate stuff meant-- #include stdio.h, using namespace std, etc. Being young and just starting out at the time, it was all pretty intimidating. I always felt there were some basic concepts that I was missing that my book wasn't covering. I remember throwing lots of time at trying to understand concepts that were really too advanced when I was starting out. As a result, it sort of pushed me away from C++ at the time, and into Visual Basic. So, although as a Sr Engineer, sometimes I appreciate the ceremony, certainly for someone just starting out, simple is better.
Thanks for sharing.
Oh wow, this video is a great explanation of the changes/features happening with C#. I'm new to both C# & OOP and I've been using PHP while coding in a procedural style for about 95% of the time. At first glance, this seems like a good idea to introduce coding in a gentle way by avoiding a lot of OOP and its syntax namespaces, class, using etc, but in the long run, this method could teach beginners the bad and very hard-to-break habits I picked up while in procedural code land while in the PHP camp and this could do more harm than good for beginners like myself who wants a career in development one day.
I am an "old schooler" who thought the top-level statements feature was senseles.
However, you have made a compelling argument and you have converted me.
Thanks for sharing.
I completely disagree with why you think this is a good thing. Developing software is defined by a structure and proper syntax. When you are trying to learn something new and all the aspects of a C# application are missing and you don't have to put those things there, you run into issues when you need to expand on those magic things you keep talking about. Now a new user gets confused when they create a class file that has all the files, when you remove the basic structure of an application and make it happen magically, you make it harder for people to learn and follow the code.
Like you pointed out about the Args missing and I have to magically know about them, makes me upset. Magic is now how I learn. I need it to have structure and make sense. I need to easily follow the code. This new way is not easy following the code and understanding what is happening. I know you think its less code, but it doesn't flow real well when it comes to the basic structure of a C# code of Namespace, Class and Methods.
My first thought is how do I create that as an Async Main method? Do I have to go back to the old way? Now I would have to spend time trying how to figure out how to make the Main method Async when there is no Main method.
So I get what you are saying, but I think you are missing the fact that the old way was also not correct. It pretended to be the same as all of the rest of C#, but it wasn't. So what we taught developers was "this is what a method is and why you create it...but that's not what Main does or is for". We taught them that you can instantiate classes...but not Program (you shouldn't, at least). By teaching them right out of the gate that Program.cs is different (obviously), they naturally get used to the rest of C# operating differently than the entrypoint of the application. Before, that was implied, but confusing. Now you can't help but acknowledge it.
As for async main, Main already is async if you want it to be. You just await any call you need to.
@@IAmTimCorey I think it's difficult to say that it's "Not correct", when it is what established the convention for every other file in your assembly. Program.cs is just a file, the same as any other file. It's merely the default startup object. That's it. That's all it is. You can change it very easily. You can have multiple Main methods in an application, and choose between them, which will be the entry-point. There is nothing special, or magical about the Program class. It's just the default. Whoever taught you that Program.cs stands up on some immovable pedestal, is wrong.
I am completly disagree with you because all the boiler plate code can be very overwhelming for a new user. This is also the reason people dont like Java because of all the boiler plate.. The new syntax allows for new users to learn the basics first and then learn aboved classes. Instead of getting everything shoved down them and program .cs class is very contradictory to how an actual class works. This is why pyhton is so popular with new programmers becausew you dont have to worry about classes and methods when starting out
@@primekrunkergamer188 It's not contradictory to how other classes work. It's just a class. There's nothing special about Program. It just happens to be the default name.
The way I was taught, we did the basic "Hello, World" stuff in Main, but after that, we made methods outside of Main, and called them, rather than bloating the Main method.
The concept of "This is the method that gets called by the operating system, when our program gets launched" was a day one concept. From there, it was common sense to keep that method as uncluttered as possible. The four lines of boilerplate that are added to the file actually go a long way to teaching the day one basics of C#. This is a namespace. This is what a namespace is, and why they are important. Inside the namespace we have the class. This class is called "Program", we can see in the Properties for the project that the OS calls this class when the program starts. If we change the name to Program2, we can see it update in the Properties. Inside a class, we have different types of "member"; this one, called "Main" is a method. Methods are small chunks of code that can be executed by name. The OS looks for a method called "Main" the startup object. We can see it says "Hello, World!"; this is called a string... and so on. Sprinkle in liberal amounts of demonstration of changes affecting the program being run.
Now, I've known people to be two weeks into a C# deep dive course, and still not know what a class is. Not even writing within a method for over a week. The culture shock of writing your first class is a lot greater when you've had no boilerplate to use as a reference.
@@ApacheGamingUK I must say it is refreshing to see principled C# devs making reasoned arguments against these incessant changes to things that weren't broken and didn't need fixing in the first place. I agree, the pre-6 Console boilerplate Program.cs is a much more fitting introduction / entry-point to C# w/ namespace, using(s), class, curly bracket scoping, etc. Without that fundamental cursory knowledge, you really don't belong in C# to begin with. We should never shy away from it, especially not just to remove a few lines of relevant syntax.
Terse code is nice, reducing nesting/indentation makes things cleaner (I've accepted and embraced file-scoped namespaces for example), but there is also overdoing it. A reasonable argument can be made this top-level stuff is overdoing it, and is causing more confusion than it is solving any perceived problems. I hate having to memorize exceptions to the rule, especially just to make script-kiddies happy they could spit out "Hello World" with a few less lines (keystrokes, really) of code.
make static void main great again
lol
Make it private, so no one takes offense. :-)
The program Entrypoint is set in the project properties, and is easy to change.
Recursion is an extremely valuable technique.
Calling Main() can be useful in certain situations, especially when you're CLI-focused, and not GUI focused.
You absolutely can reference and call this method, and there's no rules that say you can't.
I'd say this is a terrible primer for a new developer, as it makes a lot of categorically false statements.
Yes, you CAN call Main. You shouldn't. Main isn't the place to do recursion. If you want to do that, create a method to do that. Go to statements are also possible, but it is an antipattern to use them.
@@IAmTimCorey Then say that in your video ;)
I understood the direction you were coming from for this video, but you made a lot of false statements to get there. Instead of making statements that are factually wrong, just state that they are anti-patterns, that you *shouldn't* use them, like you just did with me!
If I'm being honest, I had to double check that I wasn't getting you confused with someone else when I clicked through to this video 🤣
It came across to me as "person unfamiliar with the tools/language arguing for the style they're familiar with" which didn't mesh with your reputation obviously.
he literally says that lol @@peter.dolkens
MS decided to have own Java and made C#, and now like to move to language as Python:)
I think they are learning from how to make applications efficient from a development standpoint and yes, some of those lessons come from Python. There's a reason why 60%+ of developers use Python. It is easy to quickly use to get the job done. C# isn't going the scripting route, but being more efficient as a developer isn't a bad thing.
Well, that explains a lot, I saw this weird logic, I was confused but it worked so I did not care.
Thanks again Tim!
You are welcome.
One unfortunate thing about top-level-statements is that they are a bad way to learn about accessibility as top-level variables are visible in (local) methods which they would'nt be in the classic way.
That's true. It isn't a huge downside, but it is an unfortunate side-effect.
Why wouldn't they be? When you declare and int x = 0; inside the Main method, is it not visible?
@@DanCojocaru2000 If you use the classic model a variable in static void main would not be visible in other class methods. But with top-level-statements all methods are local methods inside the main method and therefore there is no encapsulation in this direction. This is not generally bad but not good for educational purposes where the learner should experience real encapsulation and not just get told not to use the top-level variables inside the methods.
@Peter B. Well, if you use the classic model, then those variable would be static variables inside the class that contains static void Main, so they would be visible.
@@DanCojocaru2000 They would only be static variables if you explicitly declare them that way. If your top-level-statments would just be the contents of the main method the top-level variables would be local variables inside the main method and therefore not visible inside other methods. Try to look at it from a learners perspective.
I've been on the fence and one of your other videos you talked about this didn't really sell me. This was much more compelling, and I can't think of a reason not to agree. Good job.
Thanks!
I love the new structure since .NET 6. I have worked on versions from .NET 1.1 and I can say that this is so much better. It did take me some time to get used to it though.
The new structure is less clutter and more readable(no unnessary braces and indentations throughout the file). I also like how it hides not so essential details to writing your application but does not completely remove them to the point that those who want to learn the inner workings cannot access the information.
It's DRY, it's abstraction, it's simplicity. It's just great.
Thanks for sharing. I agree.
they could have left the static void/int Main(string[] args) at top level because having a return 0/1/2/-1 ... at top level is really weird.
on the global using thing. the reason I don't like them is because they remove the "file can compile on its own" philosophy.
I agree on the top line. As for the file compiling on its own, that’s never been a thing. Every time you call out to a method, you have a dependency on a different file.
@@IAmTimCorey No you don't. That's only if you call a method that exists within a different file. I'm most used to using "System.CodeDom.Compiler.CSharpCodeProvider" to compile source from single files, although that's a bit outdated now. Still works fine for simple payloads though. When writing game mods, "Source Mods" are actually really useful, as they get recompiled each time they are used. So, any ABI, and any non-breaking API changes within the game engine are automatically resolved, without needing to release, and publish a new version of the mod. The game just takes that one single file, compiles it, and treats it as an in-memory Assembly.
11:20 so they realise all this NOW? after all these years of c# existing, now they realise the boiler plate sh1t is not needed? can u explain why they just realised that NOW?
I don't think it is that they just realized it now. It is that they have the ability to make this change now when they didn't before. A lot had to be in place before a change like this could be made.
I would go further and also remove the usings and the namespace from the class files. I actually always use namespaces that stick to the folder structure. so why repeat everything in every file?
I think MS will think that a little bit too much like telling people how to code. I don't think it's a great idea tbh even with that in said.
@@blackenedsprite8542 It already exists, if you use a GlobalUsings file.
I imagine it could be useful where i add an extension to multiple classes that do the same thing, but do it differently.
For example, let's say i want to add a new comparison operator to multiple classes. My new operator might do the "same thing" in all the classes, but would be implemented differently for each one. In that case, i might add one file for the operator, in which case i'd need a namespace to add the right code to the right one.
In most cases, however, it does seem redundant.
I’ve considered that, but if you move a file, that would change namespaces in a way that would affect other files.
Even further you could go so far as to make it a file scoped class and have it infer a whether it’s a in an interface, abstract class or enum based on the name. Definitely a bit to radical but at least interesting.
Yeah, At the start, I was getting frustrated with the new way of .NET 6.
However, the more new project I started, the more it make sense.
It is just the same, but cleaner.
Glad it is growing on you.
Generics, Linq, async-await... Those were great improvements. But the latest changes to the C# language are mainly about saving a few characters. It's ridiculuous and just getting on my nerves to spend precious developer time just to find out what useless changes have been added this time again to the C# language. At least I get paid for it by my employer. And then there are those colleagues who rewrite the whole code because they think these useless changes would improve their code quality.
I wonder more whether you put back possibility of using (eg. serilog) logging during app startup (reporting misconfigured parts when starting container) that was possible way back with webhost
That still works the same way as it used to.
Im a relatively new developer and still have a good memory of how i learned to code. For me the static void main and his friends was a huge help and motivation to learn. Every time when i had to create a learning project these keywords(static, void , public ect..) were right there and yes it was annoying and scary first but then i was able to track my learning progress with these. These keywords were like a path for me to take and understand them one by one. Im a bit sad that the new generation will not have the feeling when they sit down one day and look on the main method and be proud for understanding all of it. This feeling gave me a big boost at the time and a good milestone for the learning process.
Now that you mention it, that was true for me too, I just never thought about it.
Interesting perspective. Thanks for sharing.
Deprecated .
From a learning perspective IE someone who learned C# within the past year for work, the old program was more useful for learning. Especially since I was relatively new to OOP. I do like the convenience of the new program file, but I think for beginners that boilerplate is actually important to understand.
Thanks for sharing.
It is, I struggled with startup not being present whilst doing Tim's mastercourse that uses startup etc. All beginners should avoid these changes until they have learned the old ways
As someone who has recently been learning C# on my own, I will say that whatever advantages these changes might have had for new learners are pretty heavily offset by the fact that now all the tutorials from before a certain cutoff point don't work the way the websites and books say they will. Learning how C# has changed and how to modify tutorials to accommodate those changes is pretty exhausting when you're brand-new and don't understand the documentation yet.
That is a big downside. The problem is that change can’t happen without this problem.
The thing I miss the most is a sense of encapsulation around the main method lines of code. When you added the Test() method it made it obvious to me. What if a new coder was putting main lines then a function then more main lines then a few more functions then more main etc.. Would that run? Would that be easy to read?
Totally agree
I think the key here is to treat Program.cs differently, which this now makes clear. We used to put methods next to Main, but that's not really a good solution. It pretends that the Program.cs class is a normal class. As for putting methods in Program.cs now, yes, that will work. The reason it will is because you are creating local methods. A local method is a method inside of a method. There are limited uses for it, but it can be useful (LINQ is a common use). They've been around for a while before these changes were put in place.
The methods have to be past the last lines of code or it won’t compile. I do think this is somewhere that more clarity is necessary however I’ve also kinda come to the conclusion that if Im doing something where a method is needed in program cs or just organizing it with a method i should probably be putting that method in another file. It either ends up being some sort of extension method or startup configuration object but if it’s more than one or two things then it adds too much clutter to program.cs and in cases where it’s 2 or less it should be fine to inline them instead of using methods. That’s more of a personal preference but the tooling also lack clarity around this and inlining methods inside of your entry point code does feel weird.
@@IAmTimCorey Hi Tim, thanks for replying. I agree with you about just having to treat Program.cs differently. It's unique and should be treated as such but I guess I'm too used to other methods sitting next to main within the class and namespace. I just want there to be a little more clarity around the fact that if you put a custom method in Program.cs - tell/show the user that it is a local method even if they don't realize it is a local method. They may not intend it to be that way and a hint to put it in another file would be good.
I know it’s unwarranted, but it freaks me out to not see using statements. It’s like “Hey, I can’t run this without using statements.” I know that’s not true, but still weirds me out.
Making functions that are only used internally no longer visible is conclusive and makes sense. (If I got that right) BUT, Names Spaces should stay the same as before, because I like to decide for myself which scripts should have access to it or not.
You can turn off implicit namespaces, but they are only for the built-in namespaces we all use commonly.
@@IAmTimCorey That makes sense. Thank you for the good information. I myself still use VS 2019 because it is almost impossible to migrate larger projects from pre 22 to VS 22 without having to invest thousands of hours in troubleshooting and bug fixing again.
I'm curious what issues you had moving to VS2022. I've not seen any issues in any of my projects (even my larger ones).
Great video. I'd say, top level statements and global usings made C# the perfect first programming language to learn. No need to awkwardly say "we'll discuss it later" when a student who never wrote a line of code inevitably asks "hey, what is a namespace" or "what does the `static void Main(string[] args)` mean" after they see a new console app.
Thanks!
I don’t like how you can write functions effectively inside of your main.
You can write a method inside of any method, not just Main. They are called local methods. There isn't a huge need for them, but they do serve a purpose.
Thanks for all you do Tim Corey! I like the idea of streamlining the Program.cs file but to me it's just more magic and to me magic is likely the root of many bugs (especially unknown bugs). I am leery of frameworks and try to avoid as much as possible (which is why I despise the idea of) modern/current-frontend development. Until things are better understood, people rely on magic to get things done and often I find people are resistant to change because ultimately, change may force them into uncovering and understanding the magic that's been hidden.
Before someone flames me, I understand most languages of today are "magic" over assembly, which itself is magic over binary, which itself is magic over circuits and electrical impulses. 😉The magic I'm referring to is that which exists at the framework-level.
I agree with all except the argument about rags.
It might be hidden, but so is value in a property (and maybe soon, field).
Interesting. I hadn't thought about it in that context. I still prefer explicit, but I can see your point. I think the difference for me is that with a property, we see that as the stand-in for the private backing field. With args, there is no object in front to indicate that it is there.
I think you're also saying tbat program.cs should really just be figuring out args and then passing execution to a related class, which I agree, with, even though I am guilty of making small programs in program.cs, only.
My only fear is that the open "script-like" nature is going to lead to more of this, not less. :(
True my only gripe is the allowance of local methods in that file. Ideal Program.cs would look something like:
await new MyConsoleApp(args).Run();
There is rarely a need to have anything else in the entrypoint file.
The number one confusion of C# novices stem from the fact that main() is in a class and they don't yet know what that is. Even worse, the class by its nature should be static internal and it's never been by default, so you can do new Program() and confuse yourself even more.
I don’t see this as a move towards scripting in C#. Removing unnecessary code is just cleanup.
@@IAmTimCorey I am just saying that the format of a new program is now script-like, and may lead to new people just putting everything in Program.cs, because it's kind-of more like how you would setup a scripting language.
"people will...". C# is for employees of companies. nobody, other than someone who uses c# for work, will write c# for fun. It doesn't run on microcontrollers, you don't learn it for big data experiments, students of maths don't use it.
Employees have bosses, and code reviews, and style guides, and legacy projects to drop junior devs into. Those train the employees the best practices. If they're missing, it's an organizational problem and you'll find bad code regardless of theae changes.
And the other group is unity developers and that tooling has tons of boilerplate and doesn't move to newer c# styles. So we're fine.
@@AldoInza I literally started with C# for fun.
For me personally this still seems weird and wrong. I can understand the concept that when the application is loaded the system is going to execute the main method and we shouldn’t and don’t need to call it ourselves. I think that’s a lot better than having the format and elements of a C# file be totally different only for this one file. And making the default setting be for this style optimized for beginners is silly also. At least give us a system level override to the template system to say we are not a beginner and want the traditional version. It’s not like you are saving the developer typing the code, it’s provided. Perhaps beginners should be encouraged to use REPLs or Jupyter style notebooks to isolate learning rather than making the vast majority of template users select non-defaults or have to go back and change settings and retype those lines you tried to save them.
Hi TIm,
This is completely irreverent to this video. But what is your take on the 'wso2 API Manager' for Api Management. Will Api Integration Become easier if we use this. Looking forward to hear your opinion. Thank you.
I think old way, shows oops way to start application with proper code i.e. namespace, class etc.
---
Also with new approach , how to pass args required when app first run ?
I'm afraid I disagree. Top level and implied usings are not an improvement. They hide certain constructs that newcomers really should understand. Not everyone that learns C# has a computer science degree. It also makes the transfer to/from C, C++ and Java more traumatic. I could just be getting old but I believe change should make things clearer and I don't think this does. Still keep up the great work. 🙂
How can 12 lines (of which 11 do nothing but repeat project defaults) be clearer than one line that does the actual stuff you want? Newcomers need to fiddle with the code to learn, not be lost in boilerplate that effectively does nothing. Once they start a new .cs file, THEN it's the time to learn how files interoperate and what namespace and class is.
@@the-niker Newcomers should use a playground if that's a big enough issue.
@@bobweiram6321 How is a new console app not the perfect playground? Has elitist gatekeeping not been a downfall of enough technologies already? Before .NET6 it was always easier to do simple prototyping in node.js rather than spinning a new c# project, now the code is still worse but not overwhelmingly so.
@@bobweiram6321 top level usings are optional, if you don't like them just turn them off
What constructs do they hide, beyond the small things I discussed?
I think Microsoft is trying to do more things for developer, this change remind me when I writing Python, you don't need class or method, just a print('hello world') and done. Like jQuery's motto is “write less, do more”
I think so, yeah. They are trying to make things better.
Hi Tim, could you please add some chapters to your videos? They are pretty long so this would be very useful if you know something but would like to refresh your knowledge or learn only things you don't know.
Right now I simply don't have the time. Sometimes viewers will provide them and I add them to the description to add the chapters, though.
Main is a very old convention from the earliest C. I believe Main was callable from another program, that is, you could call an executable from another executable by the name of the program. Your call would then be internally directed to go through Main first. Main can take parameters because you could call an executable with those parameters from a completely other executable. So it's for external calling, not internal calling. Can anybody prove me wrong? The early C authors wanted all there programs to be as interoperable as possible, each potentially a component in some much more complex combination of programs. Simply, each executable program was in fact a function.
Thanks for sharing!
This seems to be nice in theory, but I highly doubt it will be industry standard. Somehow people hate simplicity, need strict structure and files with endless lines of code.
In the end, all of this stuff is just syntax sugar ... like most stuff that get's added to C# lately.
if implicits usings are fine, what was the reason behind having explicit usings before? there must have been one even if its no longer deemed valid reason
I think there is a bit of confusion here. Not every using is implicit. Just the standard ones we almost always use from Microsoft. Before we only had one system (explicit). Now we can have the standard Microsoft usings as implicit while making the rest explicit.
Tkanks for the video great topic as usually I was thinking why I get that weird thing that some methods can be null and get those warnings (never crashed once) but as I think about it that makes sense if something can be null first make sure it’s not then do something. Gonna come back to my apps and do those checks. About the topic I like the idea of less code if we do the same. I know you didn’t mention it but having in blazor this one file with using statements lovely. Don’t need to have those 12 or more lines at the beginning.
Yep.
Not a "lie". Just a place indicating where to start. If you prefer the new way then that is fine. That's what this comes down to. Preference. Just don't call it a "lie". Comes across as clickbait.
Thanks Tim, less code and more readable. I really like Dot Net 7, would you make a video about .NET 8 that talk about blazor united?
Eventually. I want to see it get near release first, though. Right now, a LOT can change about how it works before it gets released.
Top level statements we only a meager small scoped change. The REAL paradigm shift is the pattern matching and functional programming they have been introducing. But also a bigger topic of discussion, as the older users still think of C# to be nothing more than a mix of C++ and Java.
Pattern matching is really awesome.
I'm not supposed to add fields and methods to the Program class?! Whoops. Lol.
Yeah, it is supposed to only be for one purpose (running your app), not for the logic as well. Ideal is to follow the Single Responsibility Principle (SRP) from SOLID.
I did not like the new style because there wasn't a good way to do integration tests. The service setup and configuration were all jumbled into one 'invisible' method.
At that time even ms documentation was suggesting to go back to old way for running such tests. I do not know how it is right now. I did not create new projects with newer .net versions.
Yep, they solved that problem. Here's an answer with the correct way, as well as the original workaround (partial class Program): stackoverflow.com/a/70645399/733798
@@IAmTimCorey a bit ironic that the goal is to make things simple but now you have to make arbitrary csproj edits to get things to work.
I understand that's not as intuitive, but we are also talking about more of an edge case. The number of people that are doing integration/end-to-end testing up through Program.cs is fairly low compared to the overall usage.
It's an improvement ! No need for such verbosity in the language when it's implicit
Yep.
The old one I think is better here in the new one I just feel lost as someone trying to learn by myself, the old one you see whatever is going on
I think there are some guys at Microsoft that are aimed to bring every other languages features (e.g python, ....) right into the C#. Microsoft is trying to gain more reputation by doing these things.
Entry-Point is Entry-Point after all.
Programmer doesn't needs to write it by his own. By any means it gives him the insight behind the execution flow. every single executable file in any operating system has one Entry-Point.
We are trying to hide it for what ? In a python projects I always have this confusion "Which file is the main executable .py ?" I definitely need a manual to run the code.
It's C# dude, a language based on C++, not Python.
I'm using this templates for testing small functions used in other project it looks fine because there are no more brackets; but I hope that it goes for just experimental purposes, not for changing whole language design.
"The number one thing I want from C# is for one of my code files to work differently to all the others" said literally nobody, ever, before Microsoft introduced top-level statements and everyone decided that if Microsoft are doing it, it must be good.
It's cobblers. They're created an incredible language, but now they've got (almost) nothing useful left to do and they can't just do nothing, can they?
But it worked differently before too?
We have an option to use whichever we want, so it's a good thing in the long run.
Yep.
I don't like top-level statements. I like the goal, but I think the implementation is very poor.
It's C#, so code goes in functions, and functions go in classes. Telling new developers that the Main() function is a 'magic' entrypoint for the program shouldn't be a big deal, it's not hard to understand. Making Program.cs special by hiding the enclosing function and class just introduces different magic that new developers will encounter very slightly later in their learning process, and, worse, I can't use the change to clean up any other file. I've got a heck of a lot more other files than I have program.cs files, when they wanted to make Program.cs easier to understand, they should have done it in a way that provides benefits both for Program.cs and for other files too.
I'd much rather have namespaces implied by the directory path of the file unless a namespace statement is present near the top of the file, and have the class name (defaulting to internal rather than private) implied by the file name unless a class statement followed by a semicolon (no brackets around class members) is present at the top of the file. That way Program.cs is reduced to a single static void Main() {} function that has an obvious namespace (the name of the project root directory, e.g. ConsoleApp1) and an obvious class name (the name of the file, Program), so it's easy for new developers to understand, plus the rules they learn there apply to every other code file as well. More importantly it also eliminates the first two levels of indention in all my files, or if I prefer the indented style I can still do that and include multiple classes in a file.
Great Video! ...but I think it is the other way around... The new way is a Lie, but that is a good thing. Obviously, C# got a lot of flack for needing a dozen or so lines before you can write a single line of code, so this an attempt to compete with languages like Java Script and Python where you can just start coding. We did actually "Need" those lines, because we didn't have global usings, or default namespaces, etc... Now they are optional, and you can, for the moment, do it the old way if you really want too. I don't like changes, but this is a good one!
It was what it was, it is what it is, and it will be what it will be but it was never a lie.
Automagically (around 6:30), love the word even if it was unintentional :D
It was intentional.
I like knowing the name of my base namespace, especially when my solution contains multiple project entry points and it's not always going to be named after the solution.
Doing ctrl + shift + f "static void main" to find the entry point is faster than checking the project properties.
Seeing string[] args makes sense if you're used to executing commands from console. I see no advantage to hiding the args, you just have to kind of know that they exist; I think that's kind of dumb.
I don't care if it's "cleaner". I don't care that some lines were eliminated, I see no advantage; feels like a downgrade to me. I don't like the change.
I would argue having "Using System;" is a benefit for new developers because they can wrap their head around the idea that methods exist in a package; they don't just come from the nether.
I'm not on the bandwagon to eliminate everything that is implicit. I don't think implicit automatically == bad
I agree that just hiding things isn't a great strategy. I'm still a fan of the new way of doing things, I just think it could use some tweaks. This doesn't set you up well for multiple entry points to the app, but that's not a typical use-case. In that case, along with a few others, I'd recommend using the original layout, which is still included and supported.
As for the changes to Main, years ago I wrote a scripting language that used a C-like syntax and worked much the same way with not having a Main function though you could write and call functions. For much the same reasons, you can't (shouldn't) call it, the compiler didn't need it to make its life easier, etc. So why bother with it. So I have no problem seeing that MSFT finally caught up to what I was doing in around 1997 ;) But at the same time I will say this isn't a terribly useful change one way or the other. Seems they just traded one bit of magic knowledge for another bit of magic knowledge. In a new code base I'd probably use it. Adding a new application to an existing code base I wouldn't as I value code style consistency.
in cpp linker include libs:), include are only signatures, but can contain inline methods
Thanks Tim. Us dinosaurs appreciate the work you do.
You are welcome.
As a conspiricy theorist, I said this from the very beginning.
lol
Thanks for the video. Seems like a mundane topic on the surface but clearly not, judging by the comments.
Things should be more accessible and less bureaucratic. MSFT could certainly improve in this regard which is what they're doing
People gate keeping the old way is so odd. Go program in assembly and yell at kids to get off your lawn if you have such an aversion to incremental improvements and QOL changes
Thanks for sharing.
As a senior dev...THANK YOU for making this video.
You are welcome.
Great video, thank you Tim.
You are welcome.
Just disable top level statements and you have a "proper" Program.cs
I don't much care that they simplified the Startup file away, but trying to find info on services and middleware is hard when MS still only has examples and tutorials for pre-6.0 unless you dive to the end of the specific version reference pages.
The changes were steep and there was little to no announcement or "here's what changed" documentation (at least from MS themselves).
I'm not sure what more Microsoft could do to announce the "here's what changed". They wrote an article on it ( learn.microsoft.com/en-us/dotnet/core/tutorials/top-level-templates ) and then they linked that article in the Console app template. They also wrote blog posts about it, did videos on it, tweeted about it, and more.
If we listen to people who preach this "no change for helping 'noob's" what will happen is simple, the language would slowly but surely die, so then this people would become king's over a grave, or would need to learn those 'cheap' scripting languages to find a job.
The market evolves, C# needs to evolve too, when is easy to code we can produce more, we can train more people and bring more ideas to the community, stale water brings nothing to us. We should absolutely discuss the changes being made or planned, but just say "change nothing, noobs should suffer as I have" is not smart.
As always, thanks Tim for the content.
Absolutely.
Using your own logic, you might as well remove typing safety and the entire compilation step. Beginners hate declaring types and compilation step because they don't understand the advantages of type safety and compilers. All you've managed to do is turn C# into another Python and JavaScript with no real advantages. At that point, no one will bother with C# and it will die even faster.
"die even faster"? .NET is 20 years old and is growing in popularity and usage. And while they aren't turning C# into a scripting language, it isn't a bad thing to emulate some of the things that make Python so popular. There's a reason why it has such a large market share.
@@IAmTimCoreyStupidity always has the biggest marketshare.
"Don't ever do that.. Don't" lol... ever... never... not even in another dimension.
So far watching 12 minutes of the video is about nothing. Sorry
I expect to learn something valuable on your channel in a serious and straightforward way but this video this is just talking about nothing with clickbait video name.
13:30 talking about string[] args being the only hidden thing is not true because there is also int return value from the main function which is the UNIX return value of the program
18:00 doing function definitions inside functions is a nice way for spaghetti code development. This was all wrong in python and with these top-level statements, it's trying to look like Python.
Having the ability to have everything run as a script does not force you to think of splitting it because you don't know why and you don't know how to call the code in the automagical Program.cs when you are new in programming. It creates a new exception for you in the process of learning because when you learn it the top-level statements way, it's all different everywhere else in the other parts of the application.
Having StartUp cs or similar stuff is not about DRY because it's used once but it's about single responsibility principle and readability - not having one main with 1000 lines but split it into logical parts. You are suggesting that when something in the application is used only once, it can be inlined. That creates nice spaghetti code.
Sorry leaving at 24 minutes, this video is not good.
It isn’t script-like just because it looks like one. When you are new to programming, calling a local method is a fine way to learn.
Hmm, one big simplification they forgot about is to not need to write ";" after every line.
That would fundamentally change how C# operates and it would break LOTS of existing code. None of these changes are breaking changes. Microsoft tries hard not to do that. The semicolon indicates the end of a logical line of code. The word "logical" is important there. When you wrap code onto more than one line, that's still valid C# syntax. The semicolon is what tells the compiler when the line is actually done. Removing that would mean that we would either need to go back to one physical line is one logical line only or the compiler would need to be entirely rebuilt to figure out when lines are actually completed. That would be REALLY tough, if not impossible, since there could be multiple interpretations of when a line is done.
Thanks for this great tutorial Tim
You are welcome.
I don't like the new style simply because i got my start back in the good ol' days of .net framework. It's ok for simple scripts, but i don't think i would use it in a real world application with command line arguments and a lot of main logic. If microsoft ports winforms to linux i'll pretend to like it though...
I get it. Personal preference and what you are used to are strong influencers. I've definitely already seen value in it in real-world applications that I've built. As for Linux, I don't think WinForms is coming (since it is tied to Windows libraries), but Uno and Avalonia are on the Linux desktop.
I can't agree with everything. as if this particular video is not prepared properly. there is no historical information, why it was designed so initially, the evolution of the .NET platform and c # itself, what it was compiled into and what it is now, etc., etc.
Are you saying the Progarm.cs file is an entry point in Serbian? i.e. everything is compiled to CIL and there is only one c# file with c# code as an entry point?)
in general dislike
Most of that does not apply to this video. As for the entry point being the only starting point of your app, yes, that is correct. You can technically change it, but that is where every app starts unless changed.
Did channel owner understand how configured in old style solution and multiple enty points? This video show low understanding for most of style or patterns of configuration ...
I'm guessing you made this video because you know the decision to remove this boilerplate code was controversial. I believe it will hinder many new programmers because not only is the code meant to explain the why and how of what you do, it also signposts your code. If they actually did this to make code easier to read then they failed.
New console is much more straight forward. When I want to do something in Console its obviously very temporary anways, so I dont need top level statments, main, brackets.
Just show me the money, let me just write the code I need. Thats it.
Thanks for sharing.
I don't like top level statements, because you can't easily add classess and structures in the main Program file to play around with things. Even for real projects, I often like to start with the basic console project and start building project architecture from scratch starting in the main Program file. Top level statements prevents you from doing this.
And also the one file looking inconsistent in the project is not my cup of tea.
I like the other new features though such as global usings, new WebApplicationBuilder and so on...
Oh, and I hate nullability checks and always get rid of them when I can, but I realise I am in the minority here...
That is a good point, that it is a bit harder to temporarily add classes before moving them out.
Still think they should force a method main with braces to contain the code.
Why?
Guess its just from my die hard c++ habbits.
using System; is the equivalent of Java1 having to import java.lang.* to even get hold of Object. Unnecessary noise.
Agreed.
I love the new structure in fact I think Microsoft should have went further. For example the majority of the templates still contain namespace Xyz { } instead of namespace Xyz; which would save an indent
That's just a matter of updating the templates in Visual Studio. They'll get to that.
9:30 - "......but should you??" 👊
no, just no. now program is basically a python/javascript file without any structure, while the rest of the language works differently. newbie wants to learn c# ? take one more day and learn properly. it will benefit when learning other languages too
That's not what is happening. There is absolutely structure. Yes, Program.cs works differently than other parts of C#, but that was ALWAYS the case. That's the thing I was trying to communicate. When is the last time you called Main()? If the answer isn't never, it should be. So we have a method that wasn't created for the purpose that all other methods are created for (reusability among other reasons) inside of a class you should know not to instantiate (unless "normal" classes) with a namespace that is useless, since no one should be accessing Main or Program.
As for new developers learning C#, .NET absolutely should be working to make it easier to start C#. Do you want a relevant language or one you like that is no longer developed? You can always use Delphi if you want to take that step back.
Automagical code is among my least favorite because documentation is horrid, and debugging it even harder.
To be fair, I fail to see how you'd have a hard time debugging this.
Uh. so Maybe you actually want to embed this app in a larger program and call its Main() from the larger project...
Now suddenly them hiding all this is not doing the developer a service.
Why would you embed an entire application in a larger one and not just call it like a library? That seems rather edge case at best. More like a “you could but you shouldn’t”-type of scenario.
Startup.cs is bullshit. The Program.cs was almost empty and some random things went into a separate class. However top level statement for a web project doesn't work well because you actually need methods in that program class. Setting up a web project for maximum simplicity is not the right thing, we should not optimize for demos. It surely makes sense for a Console app but for a web app I expect people to know what a class is.
Why do we need methods in the entrypoint for our application? It needs to call methods, sure, but why should it also contain methods?
@@IAmTimCorey well because otherwise we're back to Startup.cs. I want to have a method for configure services for example. I see no need to put it in a separate class but I do want it in a separate method.
In any case if you argue that it is correct to put this method in a separate class you should argue that this class should be created by default (yes even with a single call to AddRazorPages in it) because one thing's for certain - you'll register more dependencies
when i first started learning c#, .Net 6 was not out yet.
i had such a hard time understanding the point of Main.
the fact that i am also self taught definitely did not help in understanding either, but still, .Net 6 is just vastly superior imo.
Thanks for sharing.
@@IAmTimCorey So, last comment for the evening, but this is a perfect example of what I mean.
This person couldn't make sense of what is a core concept of OOP, not just C#. Classes, usings, namespaces, entry points. To them, this Program.cs abstraction is "superior". Why?
Because now they don't have to understand some of the most core fundamentals? They can treat C# as an abstracted magical scripting box? They can skip the "hard" part?
Main as the entry point (can still be forced in 6) is a core concept to understand for any language, be it C, Java, Python. Now this person is going to be stunted in their understanding of the language for as long as they can get away with ignoring the need to dive deeper into the language.
Treating, or encouraging people to use C# like a scripting language is only hurting them more than it is helping them.
This is all a bit of nonsense really. Namespaces only really became a thing because people were mistakenly using the wrong variable from time to time. Okay, they serve a bit of a purpose in grouping stuff together sometimes, but if you write decent code, you don't really need a namespace. You can use a well written class for that. Secondly, Main shouldn't be void, it's never been void and the OS doesn't see main as void. The OS uses eax for a return code after execution and if your entry point is Main, you need a return code. Okay, so main isn't the REAL entry point, but it's the only one you have in C#. Losing the main function/method means you also lose where in the source file execution starts. For many people, main might be at the bottom of a source file, with there being many methods positioned above main that's even before you get to the arguments that main takes, which in reality, the operating system passes you 3. An argument array, an argument count and an environment array (which many don't realise that you get).
Namespaces are used so that we don't have to have globally unique names. They've been baked into the product since the beginning.
@@IAmTimCorey Things are encapsulated into classes, compiled into libraries. In C++, the only names you see are the ones in your include files. Code should be broken down into compilation units and classes to form libraries. The applications I write are written so that things only see what they need to see, nothing more. You don't need namespaces for that. You can use them if you want to, and I do from time to time, but it's not a big deal. I guess where you don't have headers to define things, like in C++, it's a bit more difficult, but project references roughly gets you there.
Great video!
Thanks!
Thanks!
You are welcome.
I disagree. Understanding an application's entry point method is essential and shouldn't be avoided. In addition, the "Main" method can return numeric values, not just "void". Change to "int Main" to have an exit code for your app. That exit code is especially useful when calling your console app via Process.Start and consuming the Process.ExitCode value. Using top-level statements just confuses that.
Top-level statements may have a place to teach some things by bypassing others, but overall, they should be avoided, by new developers especially imo.
I have been writing code professionally for 30 years and can really code with or without top-level statements. However, I choose to not use it because it hides the actual entry point method, and makes less sense when returning an exit code.
Excellent vidoe
Thanks!
As a systems architect, I'm mortified of the back-doors that top level statements open to less skilled engineers in my teams. The ability to have running code outside of modules (and therefore exempt from UML mappings and unit test fail-safes) can introduce hard to detect circular logic, akin to the ones introduced by static method and singleton pattern abuse.
I have no issues with top level statements before DI bootstrapping, such as the use case depicted in the video but anywhere else it's just spaghetti waiting to happen. If only that toggle about top level statements could be enforced only on the application entry point and nowhere else, then I'd be 100% on board.
First, I would hope that as a system architect that you would understand that this isn't code running outside of modules. Main still exists. It just isn't shown because it isn't necessary. You can still model it and you can still test it (although testing Main is more integration or end-to-end testing).
As for top level statements anywhere else in the app, they aren't. They are only the entrypoint for your application. There isn't a way to make any other file act like Program.cs. This is just for entrypoints. So it sounds like you should be 100% on board then, right?
@@IAmTimCorey Having never used this feature before in production, I was unaware that it was restricted to the entry point of the application. At a first glance it looked like C# moving towards a hybrid paradigm model like python and php, which is very problematic to me and one of the reason I stay away from these languages for big projects.
If this feature is restricted as such then yes, I have no issues with it.
But when you need to advocate a change too much there's something wrong with it. :)
Nah. Change is hard. Any time you need to re-learn how to do something, it is tough even if it is the right call.
Existential crisis be like
I think this is unfortunate that MSFT is softens structure of c#. Nothing wrong with "old" way. I guess this is to appeal to newcomers, who are not very savvy and don't have strength to understand logic behind "old" way. This is so common to new generation of developers...
But you are arguing against the very purpose of .NET. It is designed to make programming easier. That's the role of a high-level language. That's why we have built-in libraries for all of the "hard" stuff like connecting to an API, authentication, creating windows, handling moving people to HTTPS, etc. Should we pull those things out too, since they were put in to appeal to newcomers? For example, this line was added in .NET Core: app.UseHttpsRedirection(); We used to have to write that code manually. Should we remove those features because the old way allowed you to have more control over how that's done?
@@IAmTimCorey I'm not saying that libraries for hard stuff is bad - quite opposite - this is part of what makes .NET, C# ecosystem very strong.
I was referring to conceptual things. I have lots of interactions with jr. developers. What I notice - there is an erosion of fundamentals: for example (not limited) - newcomers are avoiding things like OOD - polymorphism, inheritance, encapsulation. Very simple and elegant projects that could be done in right way become full of accidental complexities and unintuitive approaches. I suspect this is influences of scripting languages like JS.
I always bring this analogy - .NET & C# - it is like piano. And you can play anything on piano => you can develop practically any algorithms, systems in C#, .NET. It comes with certain complexities that needs to be followed, otherwise results will not be good. Piano is very hard to learn. C# is harder to learn compared with some other languages - but this what makes software better as a result.
Alex this is very much the "I suffered so everyone else should too" fallacy. Should Assembly writers scoff at you for using C# in the first place?
That's also the "old" way but kids these days are using modern C# instead!
This doesn't have to be for newcomers. Programming should be easier and engineers shouldn't get bogged down with the bureaucracy of the framework for no reason.
When was the last time you made your own string builder or http client or dictionary implementation? Are you a worse programmer because you aren't reinventing the wheel? Or are you a good one because you know which tools exist and how to use them regardless?
@ghost mall - not necessarily. But rather consistent. I like most of recent improvements in C#. But this one seems weird.
No, dude. Hiding is not truth. The argument being that when learning, it's better for you to not know the "automagic". There is no magic. This is such a condescending attitude - we know better what is best for you kind of thing. As a beginner it was always a puzzle to understand what main does. To truly and understand how things work. The interaction with the operating system. To look for more. And in a way..the old style was better, because it made me ask why is JAVA/C# so different than C++ or Javascript at the beginning, for example. What is so special about OOP? Why did they choose to do it this way. I think your argument is that it's less lines of code and indentation for playing with variables and stuff, which could be valid, but don't make that into "it's less of a lie". You are lying to yourself.
Sort of reminds me of Qbasic
There's a throwback.
These changes have been a disaster. Everyone's too busy arguing online about them to get any work done!
Nah. Tons of things have been built. Those who argue online are a small minority. For instance, even including my replies on this video and the fact that people posted more than once, the ratio of comments to views is 1%. That means that even if we said that each comment was a unique person, out of 100 people who watched the video only 1 said anything. Yet we look at that 1% (which probably more like 0.3% since I reply to almost every comment and then people comment more than once) and we say "those people represent everyone" when in fact, they represent the VAST minority. I'm saying that in terms of who is talking and who is "getting work done", not on what people believe about the topic. Also, don't forget that while I have over 350,000 subscribers, only 15,000 have even watched this video so far. That means the other 96% aren't even watching this video. They are doing something else (hopefully great work).
I could never understand what is the point of Startup.cs. It always seemed like such a random piece of overengineered complexity which only served to obfuscate how the DI setup actually worked.
I think it served a purpose for specific-sized apps. It just isn't for every app or even most apps.
This is what I hate about C# development, and I daresay modern development, in general. "Top Level Statements" really add nothing other than breaking existing structure. Then, the gotcha computer geeks, who seem to gravitate towards technical interviewing, love to throw it in your face that you aren't aware of something like this. By the way, I have stood up in the middle of an interview and walked out because someone insulted me because my definition of "boxing" differed from theirs. I finally started my own consulting business because I was tired of getting lambasted for not using the latest coding paradigms or using the latest buzzwords. Life is too short to worry about that crap; try focusing on making bug free applications.
What's your definition of boxing ?
i hate the new Program.cs file every time i see it i feel like i'm reading something illegal it hurt my brain but i don't miss the Startup.cs
It’s ok to not like something new.
Don't get me wrong; I love you Tim Corey, but you really drank the Microsoft Koolaid on this one...
lol. I'm not in love with everything they did (hiding args, implicit usings), but I've already experiences the benefits of the cleaner Program.cs file and global usings are amazing.
I disagree comon top level feels so cheap just like they way js and python hides abstraction the way other scirpted language feels cheap now dotnet will feel so cheap just to satisfy those noob programmers need who started their programming from scripted language
What do you mean by cheap? Helping the noob programmers is important. I don't see how a language being harder to learn benefits anyone
@@Box-of-hats what will noob programmers learn if programming language did everything for them will there be difference between programming and scripting this way.
programming was supposed to be hard. Aint?
That’s not an argument against them. That’s just a preference. And programming isn’t supposed to be hard. That’s the whole point of .NET - to make it easier. Otherwise, you would write in Assembly.
@@IAmTimCorey there is a difference between compiled language and scripted language. Compiled languages should be explicitly written. We should not make compiled language like a scripted language just for the sake of making it easy. The point of dotnet is not making it easy but to provide clr for the common language. Dotnet was supposed to make it easy for the code to run under the CLI not to make it easy for the noobs. Programming is a software engineering not a toy to play with by the kids (to make it easy).
Doesn’t like it
Why not?
All we are doing is satisfying the needs of noob programmer who comes from scripting language. We who have started from compiled language doing this for 10 years we know how it should be and top level programs are not the way it should be.
so stop being a dick and school these people who doesnt know better ;)
So it's just for looks? I think this is great. These "noobs" that just want to start coding will not get confused with all this strucutre that i'ts really unnecessary. If you are a senior developer you should not be wasting time worrying about this stuff.
So your ideal situation is to make the language less accessible? I'm not overly bothered either way, pros and cons on both sides, but if your main gripe is 'now newbies can use it as well' I don't see a great argument there
@@mikeconey2 if senior programmer actively endorses such stupidity where will the programming community head. After using all the programming languge I feel in love with dotnet only and they will pollute dotnet too which language am I suppose to use then afterwards.
The only reason why we had a Main method is because they had c# be a "true" OO language. But at the starting lines of code, it's just unnecessary.