Don't worry, AI can read the docs and become a master programmer in a few weeks. This is fine. Just tell the LLM what you want and it will build or re-build it in the latest release of C#/.net.
Right or the fact that Graphics are kind of attractive to kids so what do you have for c# if you want to access graphics hardware like every other language has had for like i dunno eternity. lol What year was XNA discontinued.
I think there is one part of the story missing here. What you are proposing is what .NET historically came from. A slow moving framework with extremely long LTS. This strategy made .NET lose to things like Node.js. So what you are seeing in terms of rapid development of the language+framework is the response of MS losing market share and trying to innovate to gain adoption and I think that approach has worked well. Go back 10 years and mostly enterprise shops with old devs did .NET, that's no longer the case. Maybe it's time to slow down. But without the historical context I mentioned above, it might be hard to understand why things are like the are. Thanks
A fair point and well made. The point I'm trying to haphazardly make is that at the very least the LTS situation should be *better* than node.js. Organisations pay directly or indirectly to use C#/.NET. If its not better then why use it at all? I think 5-6 years is a decent compromise.
@@edandersenwell you pick something like C# or Go for the performance over Node. So it should at least move as fast. Besides backwards compatibility it honestly wonderful in .NET land, so upgrades are almost trivial if you do them every year. In Node land not so much.
I'd love to go back to .NET, I have fond memories of years of building solutions, websites and mobile stuff with it, however ever since I started doing Gen AI, Software consulting, startup work and working with (younger) teams of developers everyone and their brother was using the newest JS/TS frameworks and mess of build and compile tools, GraphQL, etc, cloud envs, containers and variations on css and ui frameworks that they entail - the full stack ecosystem is crazily over-complex, ultimately popularity driven and not rationally driven because we are human beings not AI (yet) and we tend to go with the crowd or else be contrarian as a species..you have to appeal to one of those mindsets.. AND we have to go where the devs are and the money is.. who knows maybe GenAI and WASM will change everything...
As someone who started with C# over 15 years ago: I love how quickly and useful the language still evolves. I used to dislike new language features, but after I got to use them more often and kept adopting all of them until I liked them, I realized the issue was just me being too comfortable using old stuff and that the language design team did a great job and made great decisions all the way along. The only thing I wished for is more manual memory management and banning null completely.
@@wobuntu Could not agree more, we will get result and option types build in in C# 13, you can almost forget about nulls... This just proves how much these upgrades are important
I am of the opposite position as the language is by now just a freak show of disjointed features, some never worked in a useful capacity to begin with. It has developed the same problem as C++ has, too many unnecessary things that add complexity to both leaning and using the language. And given how dependent developers are on external libraries these days, they inherit this if they like it or not and have to deal with the new stuff. The result is that the language gets harder to work with, not easier and a huge overhead is created. It's objectively a bad thing to put too much into a language, especially if it results in competing ways to accomplish the same thing. The usage model of a language needs to be simple, expressive and easy to follow. C# never was that great in this regard, but by now its on the evil side of the spectrum. By all means, keep expanding the library with useful functions and classes. But the language must be quite stable and not trying to incorporate everything someone, somewhere has dreamed off.
@@TheEVEInspiration Interesting point of view. I agree with the requirement of a language being easy and comprehensible, but in my opinion c# is exactly that (apart from a few quirks like linq in its integrated query style). IMHO the language got easier over time (no need to explicitly newing up delegates to pass functions, inbuilt types for common delegates like a predicate, pattern matching like if(myObject is SomeType castedInstance)..., target typed new, type inference for generics, range support, etc. Can you point out some examples why you think the language is overloaded with features/complex to learn?
The problem with C# is that it's gaining so much ALTERNATE syntax, so instead of one way to write something, there are now 4 different ways to do the same thing. The whole argument of, "You don't have to use it" is, to be blunt, bullshit, because sooner or later, you'll need to use or read code that does use these alternate syntaxes.
yes you don't have to use it, but going on an interview there will always be some guy who now thinks you're a newb for not using something that he himself used a "couple of times" and that's my issue on finding common ground with other fellow developers... some programmers have become so idealistic to the smallest detail when it matters to them personally =/
Can you give me an example that bothers you? I think Microsoft's own documentation should be up-to-date, to recommended practices, as that is their goal. I don't know of any major pattern that has significantly changed or being introduced for no reason. They do add a lot of features for the runtime when to optimize the framework itself.
This was always the case in JavaScript, which the community/ecosystem has slowly tried to bleed OUT of it. TypeScript seems to be bringing that mentality back into it though, which is frustrating. It might seem flexible and appealing, at first...but then you realize how much unnecessary friction this brings to teams just trying to get things done.
As a developer I enjoy receiving these regular updates and language improvements and due to these short LTS timespans I get to actually use these features in production code. If it wasnt for that, companies would much slower adapt and drive eager developers mad because they are stuck with a 10 year old framework that they hate to support after some time because newer and better things are out.
I totally agree. I'm also looking forward to the nex release. C# has become mutch better the last years. The code can be written with a lot less extra text. For example primary constructors 1 line of code replaces at least 3 lines. It's beautiful 😊 Initializing empty list, array etc with [] is in my opinion mutch more intuitive and more clean than before.. Switch expressions are greate.
@@KjetilValoy This is your opinion, but there are different ones. How lowercase is more readable than the word "default". Less text does not mean more readable. More verbosity is not good too. There was a syntactic sugar balance in C# that will soon be gone... The main focus in the video is usability. Tried building a Auth server without licenses - huge pain
I personally like most things I’ve seen. I want to write and read less code and focus on value. Also, they are still in process of adding significant performance enhancements which is also great. I think if every other LTS was doubled, that would be more than enough. So, basically version % 4 == 0 versions are doubled to 6 year LTS, or ELTS. Seems like a reasonable compromise. If you can’t update target framework with minimal changes every 4 years, why should they support you?
I think .NET desperately needs a Microsoft supported batteries included template like Laravel with auth, queues, scheduler, middleware, signalr, orm and so on preconfigured. You would save days in configuration time and issues for people who haven’t set up that kind of stuff before. Also it would bring a paved path for people still wanting to do it themselves, which we are really missing in key areas
Yes yes yes and YES I want them to spend their time doing this instead of adding esoteric syntax niceties to C#. .NET Aspire is close in concept but just needs that final push.
I would like to give you more likes if I could, the most painful aspect is having to setup everything yourself not only that but being very proficient at it (good luck making a mixed authentication flow for your web and mobile clientes)
Just because noobs cant architect good systems you want to present a one size fits all as THE WAY. No, this will create a bias towards one way of doing things and if it's not that then 'you are doing it wrong'. People should think for themselves, combine parts themselves into a solution. Cant do that? Not my problem.
Is something is stopping .NET developers to still use .NET Framework 4.8? ;-) * It supports Windows 7+ * It's preinstalled with Windows 10 * It has 95% of all needed features * It's still supported * It generates small *.exe and *.dll files So if you "just need .NET" - why not use 4.8? It doesn't support Mac or Linux tho.
@@igorthelight Some people like me for example still use .NET Framework 4.8. We moved the code to Azure some time ago but at 4.7 version. And we will migrated it to NET.Core. One of the reasons it for example azure functions v1.x will not be supported after 14th September in 2026. Kinda hard to predict how long it will take to actually do it. Of course users wont be happy as it will mean no new features for let say a month since the team will be ocuppied with this "unproductive change" ;).
As desktop app developer, I get quite frustrated that these days, .Net is synonymous with web development. Pretty much every .net youtube channel focuses around web. All the new features focus around web.
@@edandersen We are stuck in .NET Framework 4.8, WinForms... some content on guidance from moving away, would be helpful but also, I'm aware that each situation is unique.
The main issue is that even desktop development is web development these days. WPF had a lot of layout improvements over winforms, but has since been completely eclipsed by html/css. That the libraries from MS shipped only half-baked didn't help adoption at all. WinUI? Even less baked than WPF. MAUI? Delivered at the same time as the ability to internally serve Blazor pages into a web control, like Electron devs have been doing with nodejs for years. Meanwhile our customers are asking for more cloud integration, more hosted, client-less solutions. The PC has been losing ground to phones and tablets for years now in the hands of the public, and zero-trust setups in Enterprise environments are making local installation increasingly problematic. As far as desktop stuff goes, dives into what it takes to actually get WinUI or MAUI into a usable state for a real application. How many (obvious) value converters do I need to write, and what third party framework libraries making working with them workable? Or did they actually ship something usable out of the box? How does performance compare to the afore-mentioned Blazor-in-a-WinForms-web-control implementation?
Same with SQL Server and SSIS. At this point SSIS basically seems dead in the water, or at least it’s going to be re-branded soon to something with Azure in the name. They must think data centers are going extinct or that only luddites don’t fully embrace a cloud-first approach.
Some time ago I started using Go after more than 2 decades with C# and, because it gave me the comparative experience, I completely agree with you (I still use both). Too many features can indeed become a hindrance and I find myself actually more productive while using Go, and especially while maintaining Go code. Concerning breaking changes, Go was released to the public 12 years ago and the current version is still 1.x, which means minimal breaking changes, since initial release for 12 years, absolutely nothing compared to what we have with .Net.
C# is not a "web development framework", it's a programming language. Most the things you're asking should be directed at Aspnet team, you know, the ones working on a framework, not the language design team. IMO, it's completely insane to ask for slowdown on language features. If you're ever impacted by a breaking change in the language, you can specify a language version in your project.
So you're wrong on many levels. Securing an API is baked in. You do NOT have to use Entra, IS4 or Azure B2C. Any OpenID / OAuth provider will work. Also, you point to Django, Laravel and Ruby as better options, but find me a case where those are used in an enterprise? You typically see those in smaller projects, while the larger ones use .NET or Java. As for frequent releases - C# DOES NOT change its syntax each year, but adds new features. You can use them if you want, but you can also ignore them and do what you did 5 years ago. The point being is that with .NET / C#, you can constantly evolve your code with new features and new patterns, while Python is barely on v3 after 20+ years on the market (oh and v3 is not the same as v2 so go rewrite your code). Java just recently (within the last 5 years started to innovate and add new features). And lastly, .NET and C# are open source, so I'm not sure why you fixated on Ruby's MIT license in the video.
@@edandersenI didn't see what auth provider Django includes. Laravel includes middleware targeting their own ORM, so if that's the standard, fully 2/3 of all the online examples I've seen for pre-Open ID .NET auth has used EF, so you're already there! But, if I want OpenID /OAuth Laravel doesn't provide a provider either. And on most projects, the auth isn't standalone, it's integrated, and most integrated authentication these days is providable via OpenID / OAuth.
Thats what I worry about. It appears the team is focussing on language minutiae at the expense of making this a great experience for beginners, i.e. the next generation. Thanks for the comment.
My recommendation if you are a beginner focus on other questions, that's not something you need ( at the beginning) to become a proficient C# developer.
There is a little difference between C# 10 and C# 12 tbh. As compared to C# 7 and C# 8 for example. I think they should be called C# 9.1 and C# 9.3 and the problem wouldn't exist
The whole industry is addicted to the new shiny toy. Is it for developers and users that a new product is introduced every year? I don't think so. It seems like a good question for a new person, which version will they start learning from? What about the learning content producers? I think software development is now a fair that moves forward with decisions without deep thought. Every application is loose, full of bugs and seems to have been developed in a hurry. The applications I used on 386 sx 25 hz computers were more responsive and faster than the ones I use now. The whole industry has turned into a clown show.
You cannot make any money without releasing new products. I've been happily using free software like vim and Window Maker for the past 20 years or so. They haven't changed much or at all, they didn't need to change, they are still as great as they were 20 years ago. The difference with Microsoft bs is that the developers who have worked on these fine products have not become millionaires (nor have they ever intended) by sucking out money of their hapless customers/users.
As someone that’s been supporting applications which have been built in .Net Core 2.1/2.2/3.1/5/6 and most recently 8. The hardest part is justifying an upgrade to an existing API which is working, to a new version without any “business benefits”. So whilst I like clicking file-new and using the latest framework. Companies need to understand that these applications when building on .Net Core or front-end technologies are never done, they require yearly/ 2 year upgrades just as companies do with hardware (eg laptops).
@@edandersen I know of a .net core 3 app C# 6 API (MVC) with a REACT class UI code base (all pod deployed) to replace a VB6 desktop app from 2003. That 3.5 year long project went belly up and the new plan is to continue using the VB6 app that, so far, has been doing fine with win32 api legacy code. VB6 for life. lol Perhaps they'll try again, but this time to re-write it in Excel/VBA for some real LTS. 😀
My company has to maintain the bulk of code in .Net Framework 4.x because we still need to support legacy Windows (~Windows 7) in manufacturing equipment (and installing new stuff on them is tempting fate and the owners blame you when their manufacturing stuff breaks), with the occasional port to CE Framework for small devices. The client side can't just retire their old machines without a whole chain of decision making. When I get involved in the task, the machine's existence is baked into the project. So my experience with the wider .Net ecosystem has largely been personal pet projects.
I just started learning c# as well, 4 month ago, from python background, to build desktop app. And to be honest I am excited that the language is moving fast. I agree that the strongest push c# eco-system need is a well funded open source community to lift a wide array of well supported packages. Such as Pandas, Jupyter, Django, etc... for python
I agree with you. A much longer term support period makes perfect sense to me. People have other, real, serious work to do, so they don't want to be constantly chasing new features that are of little benefit. My Customer for example does not care about these changes, they care about the business solutions that I write and if they keep running, ideally for many years, without needing to be constantly updated.
5:50 Identity Server uses a standard (openid connect, which sits on top of oauth 2.0), so any other identity provider/authorization server that uses this standard can be easily implemented too (I don't know about the 2 others). The documentation is just lacking some details and make it seem like there are only these 3 solutions, but in fact there are many others (to name a few: keycloak, auth0, adfs). And even that is non exhaustive, there are other ways to secure applications that .net supports but are poorly documented.
Also, if you need a simple authorization / authentication, why not simply start with asp net identity? If you really need an identity provider, azure entra id or auth0 or keycloak (among others) will be the de facto choice
Yes, duende identity server is commercial now, but it is quite a permissive license and the community edition is free for commercial companies with < 1 million USD projected gross revenue.Yes there's a lot of new versions, but the amount of breaking changes is quite limited. I'd be pretty comfortable working with most .NET projects from 10 years ago, but if I'd have to update a JavaScript / node.js project I most likely have to rewrite it to a completely different framework/paradigm.
You’re hitting the nail on the head with the issue and a related issue of “big languages”. They’re just unnecessarily big and it feels like the engineers that keep inventing all these things for C# just don’t know when to stop. They’ve turned C# into Windows, by which I mean, they’ve crapped it all up. There’s a reason why MS needs hundreds of PhDs to work on Windows. It’s overly complex crap. There’s a reason why Linux is the most used application hosting OS. They’re streamlined.
I find myself not wanting to invest the time to write code in any language when I know the language and libraries are a moving target. At some point we are going to have to develop some languages, libraries, and UI toolkits that are good enough to commit to supporting for 20 years instead of rushing after what is new and shiny every 3. All I want to do now is make console applications because at least that interface isn’t going to leave me high and dry anytime in the next decade.
@@JethroBodine1422 I do appreciate that. I built a windows forms app for someone in .net 1.1 and it’s great it has an upgrade path all the way forward to today. My only lament is that when I need to build apps for Linux that there isn’t anything with that level of api stability.
Well, there are standardized languages, and we also have languages that do have standard libraries very stable so this is not a problem, just choose better tools. In UI there are HTML, CSS and web components very stable. It is those Javascript libraries that live all the time.
I've been trying to learn C# on and off since the beginning of this year, and I've made almost zero progress precisely because of all that you're describing, especially the versioning convention change. .NET this, ASP that. It's indecipherable.
I started my c# journey by messing about with unity, this was 10 years ago though, then managed to get an mvc job as my first proper software job at the young age of 30
After years of using C#/Wpf/WinUI I needed a secure web project and so I went with Angular, node etc... There's not a day goes by that I don't miss C#.
can you compare an Angular migration with a .Net migration? Angular has an history of really deep changes to syntax and framework, i don't think .Net has ever had something that require that effort... biggest change was probably async/await
About time somebody said this. I mean you are supporting .NET 4.8 well into 2020s something that came in 2019 and would be supported through this decade. Enterprises don't like updating applications every 2 years else they switch to something else.
I also agree, after the introduction of linq, mostly all features in C# were nice-to-haves. Then there are some features that even break the original idea of the language, like tuples, which I believe are a benchmark of bad separation of concerns.
C# itself is adding new features, but these aren't at all mandatory. C# will be as valid now as it will be in 10 years (the only possible exception being code where the name field is used for backing fields, and its the first time that they will make a change that breaks code from an older version). So no C# isn't at all becoming harder to do. It's becoming a bit like Python in a sense, where there are just different ways of doing things depending on what your style is. Right now, most changes are aimes at performance and functional features. As far as the dot net api goes, that rarely gets deprecated to a point where switching versions of dotnet changes your interactions with the dot net api. You don't need to have the latest most fancy code. You don't have to understand all of C# it's language features. You don't have to use features you don't understand. The dot net common api does not rely on any specific C# features. The changes don't affect your codebase, nor do they force you to change your code. Nugget packages are a different story. Don't just update them to the newest version.
@@edandersen You can enforce style with .editorconfig and raising analyzer rules to errors to guide the developers to pick appropriate constructs and avoid the ones you feel that are improper for a particular use case. C# is not Java and never was one. It is closest to the metal language with automatic memory management out of all the viable alternatives, that covers both high-level business domain modeling and low-level systems programming. So it is beneficial to look at it while having experience both in, say Python and TS *and* C++/Rust/C. This allows you to decide what kind of C# you want to use. People writing long ass types, abusing interfaces and getting carried away with func composition is not idiomatic code, never was and existed even in the first versions.
@@youse600 Because beginners often like to read code written by experts to find out how to do things. That was my experience when I started out in software engineering in the late 1970s. It was probably easier then because (at least in the field I worked in) a lot of stuff was written in assembly languages.
I don't think the pace of C# updates are too fast, I think they feel too "half backedy". DU's for example, I'm not even sure how they will be able to optimize them without some runtime changes on the generics reification. But other than that I don't think C# is "getting harder for newcommers", you can learn the basics of C# very fast if you just don't take the job of needing to learn .
I like the evolving language but spot on with the central point of the support cycle length. I stick with .Net Framework 4.8 for my main clients as they need to know there is at least 5 years support going forward without being forced into expensive release cycles.
Yes, you are really forced onto an average of a 2-year upgrade cycles even though technically LTS lasts 3-years. Staying on LTS for the full 3-years does not help the average, for example: .NET 6 (Nov 2021) .NET 9 (Nov 2024, but goes out of support before .NET 11 or 12 are released) Thus: Must upgrade to .NET 10 (Nov 2025), so you are averaging an upgrade every 2-years. You either upgrade annually (which I do), or on a 2-yearly schedule on the LTS. It would be nice if there was an extra 15 months on LTS, so people could decide to skip an LTS version (and have 3-months to do the migration).
This is really interesting. I like how Java and Python both have very long support periods so that it is possible to ship an app and barely touch it for years (assuming using mostly standard library). With Rust I find compatibility to be so good that upgrades barely take any effort at all, loving that too
Well said. I’m rather tired of the two year hamster wheel as well. C# has put food on my table since 2002, and I’m immensely grateful to Microsoft for what they’ve given/sold us. They seem to have lost touch with the fact that regular old working class companies don’t have thousands of developers devoted to keeping up with the thousands of developers pumping out code at Microsoft. This pace made sense in the early days of Core to stabilize it, but not any more. I TOTALLY agree with your idea that security patch only support should go into effect after year 2 until year 4 or 5. ALSO, I think we can safely say C# is feature complete at this point.
I for one love the pace at which C# is evolving. Contrast that to Java and you know how lucky we are. And not once have I come across a change that made my old, time-tested habits invalid.
Since there are quite a few new nuget libs that support .net Standard 2.0, I also use the .Net Framework 4.8 again, since the support there is tied to the Windows OS. With web api, however, I'm sticking with .Net but would also like to see an LTS+ version with 5-6 years of support.
I think C++'s 3 year major language release cadence is the best frequency (and the additional time means they can ensure better backwards compatible non-breaking changes). The .NET team could do major releases every 2 years if they're feeling impatient, but every year is overkill. It's funny and perhaps a little sad to see a site like Pluralsight update their C# course path to what WAS the latest version only for Microsoft to already be coming out with the next release by the time this happens. Instructors have to be feeling a little like Sisyphus trying to keep up with this ridiculous pace.
I see both sides to this coin. I understand the hassle with updating pipelines etc but 3 years for LTS should be enough time for preparing for these updates. For STS its 18 months, which is much shorter but that's the tradeoff you get new features in shorter period of time. It is very expensive to have to maintain and support older frameworks (believe me I know) so I get Microsoft's desire to shorten things, and keep pushing the envelop with new features. The example in the video of very long support for 4.8 Framework is comparing apples and oranges. That is a totally different technology, so they knew they needed to support that much longer before folks made the plunge to .Net Core.
As a professional full stack developer which codes C# for a living I totally agree with your point. Instead of adding all of the syntactic sugar to C# and adding breaking changes every year, let's add things that are actually helpful like admin panels (like filament for Laravel), reorganize the documentation to make it easier for newcomers.
Breaking changes?? I have been using C# since 1.0 and I have very very rarely had to deal with any breaking changes except, most have been on the plattform change from .net framework to netcore and net framework does still supported.
.Net team wants to make a more modern language and I want that too. Recently they started to introduce breaking changes therefore longer LTS support makes sense.
@@edandersen modern in the term of wider developer adaptation, like it should be par with the feature available in new and evolving languages like: go, rust, etc.
Modern language ideas are ****** IMO. Keeping it simple and limiting the scope of effects is VERY important for creating stable code. The new trends do everything they can to break everything in ways even long time users do not understand. Many barely understand multi-threading, let alone they ways in which it can break code, so anything that makes it less obvious where things (can) go wrong is bad. And anything that hides functionality that needs to be on the top of a programmers mind is bad too. Most new features/syntax tends to muddy the water and result in executing code in plates and times that are less predictable. And also, the separation between database and language is wrong. Database access is fundamental to most applications, so a language needs to deal with that well and not stuff that into libraries. Because C# did this wrong, a mess evolved around ORMs and other frameworks. A similar thing can be seen with regard to dealing with the web. It's just very unbalanced IMO, resulting in an explosion of libraries/frameworks, each adopting different patterns and language styles. Few will want to support the mess that this created, old an new alike. New features will not address the core problem!
I totally agree with your main point about needing longer LTS versions. I'm also on the same page about Microsoft sometimes changing stuff just to try and attract fans of popular languages, even if it doesn’t always hit the mark. Lately, it feels like they’re adding a bunch of features to appeal to Rust developers, like option and result types, and all the things thy did with nullables. On one hand, it’s annoying that C# seems to jump on every new bandwagon, piling on extra features and duplicating stuff for the same tasks.But on the other hand, I get that not updating the language at all wouldn’t be the way to go either. There are some new features I don’t really see the point of, like being able to write actual method bodies in interfaces since .NET 6. Still, there are other new features I can’t live without now. I’m really looking forward to implicit fields in C# 13-I always hated not being able to have implicit member variables like with auto properties while still managing setters and getters and working with WPF. Plus, the collection expressions in C# 12 are awesome because you can pass collections to methods without having to refactor when the collection type changes. And the performance improvements in the latest versions are insane. Just upgrading can double your LINQ performance without any code changes. Honestly, there’s rarely a new feature I don’t end up liking once I get how it works. I also get that some new features overlap with old ones without fully replacing them, especially since Microsoft has a long history of supporting legacy stuff (remember when they skipped Windows 9? Afaik because they didn’t want to retire code still checking for Windows 95/98 for compatibility). My main concern is that the magnitude of features coupled with the short release cycle leads to oversights from the .NET team. All these features and the quick release cycle might lead to some things slipping through the cracks. For example, I heard the new null check (variable is not null) is faster than the previous (variable != null), and some LINQ methods are way quicker now because they use Span internally, while others still don’t. It’s frustrating because I have to keep learning different ways to do the same thing - not because it is better, but simply because the other option has not been properly updated - with every new .NET version, and it can get pretty tiring. I think if they could double the release cycle and extend LTS support, it would give the .NET team more time to polish new features and give all of us C# developers more time to maintain our apps before jumping to the next LTS version. That would solve a lot of the issues.
After programming for 15 years in c#, I want to switch to Java. There's a lot of cat n mouse with c#. I bet not even c# creators know all the features and can keep up with the ever changing syntax and nuances. There are more nuances than keywords now
When moving a critical .NET Framework app to Core, we realized the .NET Core implementation had a bug. I made an upstream contribution with a fix that was approved but now my patch will only flow to .NET 9 as it looks like only absolutely important commits are being backported to .NET 8 even though EoL is almost 1.5 years away. So now we have to hold off the migration from Framework 4.8 until .NET 9 is GA :)
@@EraYaN If the cycles were 3-5 years longer, it would be expected that the fix could be queued for .NET 8 (like an 8.1) because more attention would be around to maintain it.
From a security point: If you have an active app in production (or in a mobile app store) you should build (and probably upgrade) once or twice each month. There are vulnerabilities discovered all the time. Having a long LTS only makes this worse. If you are in the microservice hell/heaven, you already have pipelines, and they should be doing most of this for you.
It's already difficult to justify migrating away from 4.8 as most apps in the wild just work. The short life cycles of core makes it even harder to justify. The basic argument seems to be the cool kids are over there and it will just run faster, however I never found 4.8 to be slow 🤷♂️ Don't get me wrong I've spent a year migrating everything but I've had to kick new features down the road while I did it.
.NET is going through the same issue Java had 10-12 years ago. If you come in cold or need to take on a new paradigm (like switching to a 'thick' client), it's quite difficult to determine what APIs to adopt and what docs or blogs are current.
Personally, I never even saw much of a point with the whole LTS thing. Especially with .NET. In my experience, almost every recent .NET version (at least since .NET 5 or so) upgrade has basically just been doing a search and replace of the target name, and update dependencies. Ex. replace "net7.0" with "net8.0" in the entire solution, and double check the diff to make sure it didn't replace something it wasn't supposed to. Basically every new C# version also has come with at least one new QoL feature or syntax improvement, that while it doesn't in any way revolutionize anything, at least makes the syntax look nicer and cleaner. These are also never compatibility breaking, and are optional to use, so it's not like you have to go through the entire codebase immediately and update it to use them.
Its not always as simple as a find and replace. There *are* breaking changes and third party packages are not always updated on time. Thanks for the comment!
As a seasoned ASP developer I totaly agree with you. They tried to avoid the .Net framework "infinite" support time frame but, in my opinion, they went too far regarding lts releases. It's daunting especially for smaller shops.
C# is a better language in so many ways than python but python is more widely adopted. There is still great mistrust of microsoft and .net lacks the ecosystem that python has (e.g., pyspark and NLP) including the nice integration with lower level components, such as direct integration with C and use in microcontrollers.
Having worked in the Go ecosystem, much of what you mentioned really resonates with me. Go releases are usually focused on security and runtime improvements, not introducing new syntax, and when it happens, the community has fair warning that a major change to the language is happening. Given how complex C# already is, i think it would benefit MS to glean some tips from Go.
The choice of philosophie between C# and Go are just different.. Go pursuits minimalist and "afraid" of breaking changes. C# introduces as much keywords as it can think of to make the codes as expressive as possible. It is the reason why Go stays with 1.x for more than 10 years.. while C# got new version for every 2 years... I prefer something in the middle balances
Yes but much like Go, .NET runtime never ever tries to break on you. When people talk about breaks they mean surrounding ecosystem which is less stringent with backwards compatibility. The thing is - Go does *not* provide it. Instead, you are at mercy of release cadence of separate dependencies, which, surprise can and do take breaking changes. In reality, if you assume that .NET 6 and newer is the only target worth even talking about, you never had or will have any breaks whatsoever. Updating is just bumping a target version, redeploying and enjoying another +5-35% of performance. I can't believe how clueless .NET community is in its lack of awareness of how bad everyone has it elsewhere, and how good we have it if just by a degree of improvement that .NET went through in the last 5 years.
That's quite accurate what you said, and I havent thought much about it, but it's true, when I have to create a .Net microservices with some standars security protocols as JWT or WSSE, have no support at all but community, well, except WSSE for oasis that I had to create it from scratch.
You're wrong, a lot of them do... .NET and nodejs have wildely different usecases. I would *never* start a very complex app with a javascript framework...
@RaMz00z i didn't mean no startups using .NET but most prefer Node over .NET and i think because of following reasons. 1. one language for frontend and backend (no context switching) 2. npm packages for literally anything 3. easy to hire developers and easy to find replacements( big thing for startups) 4. for most cases nodejs is fast enough But i don't like to be a fan boy for any language or framework. I'm just saying nodejs is good enough for most startups.
My problem with dotnet isn't c# so much. It's that I have to re-invent the wheel every time I create something. Example - every MVC web site I create I need to spend 2-3 days creating a user management system. Even just listing users in the system is something you need to manually create. If there were some sort of repo for components like this, I would be so so so happy.
100%. Thank you for being brave and posting on the wild west which is Twitter. I decided to learn c#, and it's been confusing to say the least, especially when there are a number of different ways to do things. If Microsoft are serious about the next generation of developers choosing C# then they need to make it novice friendly, releasing the the versions of the framework/language for a longer period of time, before releasing new versions will definitely help.
Long story short: .NET Should have releases every 2 years. Standard support for a version should be 4 years. Long support should be 8 years. End of story.
Why, what is wrong with current schedule? Updating to new version is usually matter of an hour top. There is so little breaking changes between .NET 7 and .NET 8 that update was a breeze.
@@petrmalecik5661beacuse you upgraded from 7 to 8... i encourage you to migrate an enterprise Blazor app from 6 to 8 with all of the runtime changes, they just reinvented runtime for fun
I've been working with .Net since ~3.5 and I definitely agree. I think the rapid pace was beneficial when .Net Core was introduced as it gave some time to quickly iterate and improve on what was a new and radical change at the time. At this point though .Net feels pretty solid. It'd be nice if the LTS release window started to lengthen.
I feel the same way. At the same time, if the app has developers around, couple of minor releases a year is a good idea anyway, just to keep the supportability in sync
Hot takes? Oooh I love those like hot cakes. You know, I am fully onboard with a longer LTS. In exchange, because I'm a madman that never considers consequences of his actions, I would like to finally see some actual breaking changes: old API being deprecated and eventually fully removed (e.g. non-generic IEnumerable, IComparable, IEquatable, etc.), System.Void being promoted to a first class citizen (Func, Task, ValueTask instead of Action, Task, ValueTask), ability to define functions at namespace -level, etc.
It is difficult to keep up, and I also have experienced trying to upgrade a project over multiple major versions which is also challenging. IMHO, Node has the same problem with major versions and breaking changes. It is even worse with all of the packages that you end up having g to wait for them to fix or even if they are still being maintained. I am happy they cut support earlier so we don’t have as much legacy code running on “supported versions”. It also frees up the teams from maintaining more older versions.
Agreed. 100%. Been with C# and .NET since the beginning and it's become somewhat of a Frankenlanguage trying to be everything to everyone. It's great to innovate but not at the expense of losing sight of what's truly important.
The auth example is very good. If I had to make a new stack today using .NET, I would probably do the OAuth server in something else than .NET seeing how complicated/messy that is.
I loved how laravel used to have everything set up out of the box when i worked with it, from routes all the way to orm, you go straight into building things, also artisan is better than dotnet cli imo. But to be fair c# is goated.
People will always disagree on particular choices, but I love how almost any annoyance and redundancy in the code has got removed within the last years. If anything in your code is duplicated and verbose, it's purely your fault. And the fact that at the same time the performance only improves, is absolutely amazing
Outstanding! Well stated and I agree with just about everything you said. I was an early adopter in the v1 days (circa 2003). The move from "full framework" to Core was jarring and marked the beginning of this insanely aggressive release cycle and short support periods. Not enough people raised their hands back then, but I appreciate people like you that are raising awareness. New subscriber here! :)
C# is the Microsoft Word of programming. You use it mainly at work, in big companies, and what you do with it will still be used 15 years later. You can't say the same about a lot of other web frameworks. Every few years, we compare C# to the current frameworks, and we forget that we did the same a few years ago and the previous other frameworks are no longer relevant. Still, I welcome effort towards minimal API. And I would like to see more effort put towards Polyglot Notebooks, which allows to write C# in a friendly and visual environment.
I predict that in the not too distant future, there is going to be a massive tech-debt problem caused by React and Node! At least with .NET apps, they all have the same foundational structure. The same cannot be said of React where every app is different because apparently, not being 'opinionated' is the holy grail! .NET may apply some opinionation, but at least with a base set of rules, you end up with a better structured, more maintainable application.
I agree with you. The most annoying aspect to me is that now when I write by-the-book C# code from two versions ago, Visual Studio is graying the code out and suggesting I "fix" or "simplify" the code, using (in my opinion) these uglier and less readable syntaxes I would rather not use.
I agree with Microsoft giving LTS releases more than 3 years of support, eg your 6 year proposal sounds good. I disagree with the idea that there should be long intervals of many years in which no new features are released. Those lists of features in new C# versions are actually VERY useful and make the language much MORE attractive to use, they did so for me. Those who want to use them shouldn't have to wait 5 years or whatever to get them. Those who don't want them can ignore them. Every other programming language has major feature releases around annually or so. See also Java.
You’re right. I have been saying the same thing. The time you need to learn the new plus adaptation is not enough. When ever you think you’re almost there with the new features , there comes a new release.
Stay with .NET Framework if you don't want new features in framework or language because it's too much 'learning'. I honestly, don't want .NET Framework 'grandpas' who thought that < 4.7 was good enough deciding whether and what we should have in .NET Core/5+. Regarding LTS, I agree and would welcome longer LTS, 4 or 6 years. But feature-wise? C# is amazing but still we are missing a lot of features supported in other languages that would be great to have. Quicker release cycle also helped to shape the language to be so amazing today. So in my opinion they should drop some of the dogmas they were following and start introducing more breaking changes if they will allow the language to improve.
.NET has the largest keyword count of all the major high level languages. Beats C++ by a mile. All the new stuff is literally catering to people who are lazy to type. Gone are the days of LINQ and WPF like features.
I do with they would remove some of the bloat and clean up the runtime a bit Break backwards compatability if necessary We cant let the past hold back the language
Wow. I was actually thinking about this today. Change is good but At the current rate it is bad in my opinion. I started with .Net about 4 years ago and its hard as a new learner.
I've spent most of my career working in .NET and I enjoy it for the most part. The vocal online community is way behind the times and stuck in their ways. I finally found a job that is value to customer oriented and not fixated on design patterns and antiquated arbitrary rules that slow development to a crawl. All code bases become hard to maintain over time. Doesn't matter if you spend 80% of your time planning out your next move. Requirements change and tech debt is inevitable. I also agree that not having good starter templates is a huge negative, especially the auth part. Massively hinders people that want to try it out when they're coming from frameworks that are vastly more developer friendly.
If there's an adoption problem for C#/.NET, it's likely not the fault of C#/.NET. It's possibly due to improvements in the JS/TS ecosystem reaching significant levels. Lack of adoption need not be caused by a "fault" in System A, but by improvements in System B.
I agree there should be longer-term supported versions. That Framework 4.8 is the currently longest-supported version is insane. On the other hand, there's the opposite problem - look at Java, where a lot of devs are stuck on an old version of the language because it's the one with long-term support. I mean you CAN use more modern JDKs if you want, but getting started as a beginner right now is kind of frustrating - since there's no clear answer to which JDK to start with…
I agree that the LTS version should have a longer support cycle. If you are developing anything of reasonable complexity just managing update cycles can become a serious drain of resources on a three year cycle. Six years for LTS and two years per interim cycle seems very workable while allowing plenty of time for new features.
Some comments here are sort of insane to me. How can you be concerned about about updating .NET version often even if you needed to do it every year. Do you guys seriously not keep your dependencies updated? This is not different than any other dependency. The amount of code changes you need to do in .NET is basically nothing. People put way too much weight on .NET 6 vs .NET 7 etc. Think of it as .NET 1.6 to .NET 1.7 and keep your minds from rotting :)
php/ts/go guy here. I just recently got into c# and I don't have that problem Just watch the whats new in c# 11-12-13 videos first, before doing the outdated tutorials and use the new versions of doing things. but, on the other hand, I've been doing programming for 10 years. bugs anc console warnings never scared me. I wish c# was a bit faster though. It has some nice syntactic sugar stuff, but, I quite like go right now, wich also destroys it in terms of performance.
I agree with you. C# is getting more and more complex. Too many ways to do one thing. I wish C# team could think more about simplicity. Sometimes less is more.
Your example about support life cycles. If you're releasing an app 1 month before .NET 8 stable is scheduled to come out, you should already have had months to years of advance knowledge of any breaking changes, and you should have made your app compatible with .NET 8 already long before it was released, so upgrading should have been trivial. It's not like no one knows what it contains before it comes out. For that matter, for a brand new app, you could have had it target .NET 8 from the start, even if its not quite final, because your app is brand new anyway.
Nah I don't think most normal orgs will be running a separate ".NET 8 Preview" build of their app during development. If you release on the latest at the time LTS, sorry but I think you deserve way more than a year of support.
@@edandersen You don't have to run a Preview build, just read the occasional release notes leading up to it, and don't use the .NET 6 features that they removed in the first place. Then you can update to .NET 8 after it comes out stable with minimal fuss.
I hobby code and did many a project in C# and .NET, receiving praise from even professionals and having some projects on Github, but I think the kids don't like C# or MSFT, ironically since they often have the best tools. I loved Silverlight since it was so easy to build a professional looking UI. I worked in Silicon Valley in management for a couple of decades and retired in my 40s when my ship finally came in. Not an IPO, but a huge inheritance. Good luck to you reader.
I think everything is fine with C#, except when it comes to Blazor. It should be something similar to Vuejs engine-wise with the razor syntax (which is beautiful). I mean, there's people literally using vuejs in the middle of blazor SSR projects. I don't like how bulky the page download is. Makes no sense.
I think everyone thought of this but rarely going public about it. Really exhausting to catch up all these dynamics on .NET and C#. Now they want to add to C# even more of the functional programming paradigm on it, it might be great but also could render C# unlearnable. It become like riding a roller-coaster, which is exiting and exhausting at the same time
@@edandersen probably it is because it is like roller-coaster, it is exiting until it becomes exhausting. It seems that now the folks began to show the symptoms of exhaustion :)
Started off my coding journey with C# and .NET, Razor, Blazor, MVC, API, WPF the whole shebang. Now I work in SvelteKit, being a beautiful language that it is the platform being a corporate cash cow really brings it down. If I pick up anything beside TS now I think it's gonna be Go.
Only issue I have with the pace of language development, is that several features come out half baked, and are either missing useful bits or have ramifications that must be supported forever more. As an example of the former, introduced in C#8 is the amazing nullability annotations for references, but it has some glaring holes, like how Task functions will not respond to `NotNullIfNotNull` and similar attributes.
C# release schedule and short LTS 2 year time (don't even get the point of short term support in big corporate) is exhausting. Bigger problem is the cost of constantly updating existing Azure code bases. Big corporates are starting to put the breaks on coding. Maintenance is becoming a big headache for regular companies.
Being saying for years that - need more focus on WINDOWS frameworks, WINUI, WPF, ASP - expand them make them better, add controls, add generation, and make them look and interact better. Too much emphasis on the language and too much emphasis on development on non-windows platforms ( MAUI)
C# has become C++. Two developers can create code that looks like a completely different languages depending on the features they choose to use. It's maddening.
totally have this problem where I work apps get stuck with so much tech debt because they were written in earlier versions of .net core and quickly became unsupported, impossible to keep up all apps
Please consider subscribing if you haven't already 🙏 Hot takes and coding tutorials guaranteed.
Don't worry, AI can read the docs and become a master programmer in a few weeks. This is fine. Just tell the LLM what you want and it will build or re-build it in the latest release of C#/.net.
Right or the fact that Graphics are kind of attractive to kids so what do you have for c# if you want to access graphics hardware like every other language has had for like i dunno eternity.
lol What year was XNA discontinued.
I think there is one part of the story missing here. What you are proposing is what .NET historically came from. A slow moving framework with extremely long LTS. This strategy made .NET lose to things like Node.js. So what you are seeing in terms of rapid development of the language+framework is the response of MS losing market share and trying to innovate to gain adoption and I think that approach has worked well.
Go back 10 years and mostly enterprise shops with old devs did .NET, that's no longer the case.
Maybe it's time to slow down. But without the historical context I mentioned above, it might be hard to understand why things are like the are.
Thanks
A fair point and well made.
The point I'm trying to haphazardly make is that at the very least the LTS situation should be *better* than node.js. Organisations pay directly or indirectly to use C#/.NET. If its not better then why use it at all? I think 5-6 years is a decent compromise.
@@edandersenwell you pick something like C# or Go for the performance over Node. So it should at least move as fast. Besides backwards compatibility it honestly wonderful in .NET land, so upgrades are almost trivial if you do them every year. In Node land not so much.
At least with Node they don't change the language itself. JS is evolving not nearly as fast as C#.
Java's update/support cycle looks reasonable, nowadays ...
I'd love to go back to .NET, I have fond memories of years of building solutions, websites and mobile stuff with it, however ever since I started doing Gen AI, Software consulting, startup work and working with (younger) teams of developers everyone and their brother was using the newest JS/TS frameworks and mess of build and compile tools, GraphQL, etc, cloud envs, containers and variations on css and ui frameworks that they entail - the full stack ecosystem is crazily over-complex, ultimately popularity driven and not rationally driven because we are human beings not AI (yet) and we tend to go with the crowd or else be contrarian as a species..you have to appeal to one of those mindsets.. AND we have to go where the devs are and the money is.. who knows maybe GenAI and WASM will change everything...
As someone who started with C# over 15 years ago: I love how quickly and useful the language still evolves. I used to dislike new language features, but after I got to use them more often and kept adopting all of them until I liked them, I realized the issue was just me being too comfortable using old stuff and that the language design team did a great job and made great decisions all the way along.
The only thing I wished for is more manual memory management and banning null completely.
@@wobuntu
Could not agree more, we will get result and option types build in in C# 13, you can almost forget about nulls... This just proves how much these upgrades are important
As long as they keep the upgrade process easy and well documented I have been happy with the LTR length.
I love null
I am of the opposite position as the language is by now just a freak show of disjointed features, some never worked in a useful capacity to begin with.
It has developed the same problem as C++ has, too many unnecessary things that add complexity to both leaning and using the language.
And given how dependent developers are on external libraries these days, they inherit this if they like it or not and have to deal with the new stuff.
The result is that the language gets harder to work with, not easier and a huge overhead is created.
It's objectively a bad thing to put too much into a language, especially if it results in competing ways to accomplish the same thing.
The usage model of a language needs to be simple, expressive and easy to follow.
C# never was that great in this regard, but by now its on the evil side of the spectrum.
By all means, keep expanding the library with useful functions and classes.
But the language must be quite stable and not trying to incorporate everything someone, somewhere has dreamed off.
@@TheEVEInspiration Interesting point of view. I agree with the requirement of a language being easy and comprehensible, but in my opinion c# is exactly that (apart from a few quirks like linq in its integrated query style). IMHO the language got easier over time (no need to explicitly newing up delegates to pass functions, inbuilt types for common delegates like a predicate, pattern matching like if(myObject is SomeType castedInstance)..., target typed new, type inference for generics, range support, etc.
Can you point out some examples why you think the language is overloaded with features/complex to learn?
The problem with C# is that it's gaining so much ALTERNATE syntax, so instead of one way to write something, there are now 4 different ways to do the same thing.
The whole argument of, "You don't have to use it" is, to be blunt, bullshit, because sooner or later, you'll need to use or read code that does use these alternate syntaxes.
I agree. Today every C# project can look totally different. Thanks for the comment!
I agree too.
yes you don't have to use it, but going on an interview there will always be some guy who now thinks you're a newb for not using something that he himself used a "couple of times" and that's my issue on finding common ground with other fellow developers... some programmers have become so idealistic to the smallest detail when it matters to them personally =/
Can you give me an example that bothers you? I think Microsoft's own documentation should be up-to-date, to recommended practices, as that is their goal. I don't know of any major pattern that has significantly changed or being introduced for no reason. They do add a lot of features for the runtime when to optimize the framework itself.
This was always the case in JavaScript, which the community/ecosystem has slowly tried to bleed OUT of it. TypeScript seems to be bringing that mentality back into it though, which is frustrating. It might seem flexible and appealing, at first...but then you realize how much unnecessary friction this brings to teams just trying to get things done.
As a developer I enjoy receiving these regular updates and language improvements and due to these short LTS timespans I get to actually use these features in production code. If it wasnt for that, companies would much slower adapt and drive eager developers mad because they are stuck with a 10 year old framework that they hate to support after some time because newer and better things are out.
10 years is a bit much. But 5-6 years is fair I think for enterprise. Thanks for the comment!
I totally agree. I'm also looking forward to the nex release. C# has become mutch better the last years. The code can be written with a lot less extra text. For example primary constructors 1 line of code replaces at least 3 lines. It's beautiful 😊 Initializing empty list, array etc with [] is in my opinion mutch more intuitive and more clean than before.. Switch expressions are greate.
Yeah all that's already in now. Is there really that much left after union types worth all this disruption for?
@@KjetilValoy This is your opinion, but there are different ones.
How lowercase is more readable than the word "default". Less text does not mean more readable. More verbosity is not good too.
There was a syntactic sugar balance in C# that will soon be gone...
The main focus in the video is usability. Tried building a Auth server without licenses - huge pain
I personally like most things I’ve seen. I want to write and read less code and focus on value. Also, they are still in process of adding significant performance enhancements which is also great. I think if every other LTS was doubled, that would be more than enough. So, basically version % 4 == 0 versions are doubled to 6 year LTS, or ELTS. Seems like a reasonable compromise. If you can’t update target framework with minimal changes every 4 years, why should they support you?
I think .NET desperately needs a Microsoft supported batteries included template like Laravel with auth, queues, scheduler, middleware, signalr, orm and so on preconfigured. You would save days in configuration time and issues for people who haven’t set up that kind of stuff before. Also it would bring a paved path for people still wanting to do it themselves, which we are really missing in key areas
Yes yes yes and YES
I want them to spend their time doing this instead of adding esoteric syntax niceties to C#. .NET Aspire is close in concept but just needs that final push.
Well said!
I would like to give you more likes if I could, the most painful aspect is having to setup everything yourself not only that but being very proficient at it (good luck making a mixed authentication flow for your web and mobile clientes)
Just because noobs cant architect good systems you want to present a one size fits all as THE WAY. No, this will create a bias towards one way of doing things and if it's not that then 'you are doing it wrong'. People should think for themselves, combine parts themselves into a solution. Cant do that? Not my problem.
ABP ??
Java programmers are watching with interest. about half of them work on Java 8, although Java 22 has already been released.
Is something is stopping .NET developers to still use .NET Framework 4.8? ;-)
* It supports Windows 7+
* It's preinstalled with Windows 10
* It has 95% of all needed features
* It's still supported
* It generates small *.exe and *.dll files
So if you "just need .NET" - why not use 4.8?
It doesn't support Mac or Linux tho.
@@igorthelight yeah linux+docker
@@SpookFilthy That would help!
VS2022 can still build .NET framework 4.6.2 .... so you can share a VS12 project with a VS2022 one.
@@igorthelight Some people like me for example still use .NET Framework 4.8. We moved the code to Azure some time ago but at 4.7 version.
And we will migrated it to NET.Core. One of the reasons it for example azure functions v1.x will not be supported after 14th September in 2026. Kinda hard to predict how long it will take to actually do it. Of course users wont be happy as it will mean no new features for let say a month since the team will be ocuppied with this "unproductive change" ;).
As desktop app developer, I get quite frustrated that these days, .Net is synonymous with web development. Pretty much every .net youtube channel focuses around web. All the new features focus around web.
Sorry buddy. Would you like me to cover some Desktop stuff? If so what would be interesting?
@@edandersen We are stuck in .NET Framework 4.8, WinForms... some content on guidance from moving away, would be helpful but also, I'm aware that each situation is unique.
The main issue is that even desktop development is web development these days. WPF had a lot of layout improvements over winforms, but has since been completely eclipsed by html/css. That the libraries from MS shipped only half-baked didn't help adoption at all. WinUI? Even less baked than WPF. MAUI? Delivered at the same time as the ability to internally serve Blazor pages into a web control, like Electron devs have been doing with nodejs for years. Meanwhile our customers are asking for more cloud integration, more hosted, client-less solutions. The PC has been losing ground to phones and tablets for years now in the hands of the public, and zero-trust setups in Enterprise environments are making local installation increasingly problematic.
As far as desktop stuff goes, dives into what it takes to actually get WinUI or MAUI into a usable state for a real application. How many (obvious) value converters do I need to write, and what third party framework libraries making working with them workable? Or did they actually ship something usable out of the box? How does performance compare to the afore-mentioned Blazor-in-a-WinForms-web-control implementation?
Yes@@edandersen
Do desktop with Flutter
My biggest worry with .Net is that it often tries to push you towards their Azure Cloud Service.
I have noticed yes
This is true yep
It's called vendor login
Same with SQL Server and SSIS. At this point SSIS basically seems dead in the water, or at least it’s going to be re-branded soon to something with Azure in the name. They must think data centers are going extinct or that only luddites don’t fully embrace a cloud-first approach.
How come? any examples?
Some time ago I started using Go after more than 2 decades with C# and, because it gave me the comparative experience, I completely agree with you (I still use both). Too many features can indeed become a hindrance and I find myself actually more productive while using Go, and especially while maintaining Go code. Concerning breaking changes, Go was released to the public 12 years ago and the current version is still 1.x, which means minimal breaking changes, since initial release for 12 years, absolutely nothing compared to what we have with .Net.
That's great insight. Sometimes less is more. Thanks for the comment!
I love Go
C# is not a "web development framework", it's a programming language. Most the things you're asking should be directed at Aspnet team, you know, the ones working on a framework, not the language design team.
IMO, it's completely insane to ask for slowdown on language features. If you're ever impacted by a breaking change in the language, you can specify a language version in your project.
I see it as one team, they all come under devdiv. Thanks for the comment!
Seriously? One team?
@edandersen you set yourself up for confusion and failure by blending c# and. NET together. One is clearly a language and one is not.
So you're wrong on many levels. Securing an API is baked in. You do NOT have to use Entra, IS4 or Azure B2C. Any OpenID / OAuth provider will work. Also, you point to Django, Laravel and Ruby as better options, but find me a case where those are used in an enterprise? You typically see those in smaller projects, while the larger ones use .NET or Java. As for frequent releases - C# DOES NOT change its syntax each year, but adds new features. You can use them if you want, but you can also ignore them and do what you did 5 years ago. The point being is that with .NET / C#, you can constantly evolve your code with new features and new patterns, while Python is barely on v3 after 20+ years on the market (oh and v3 is not the same as v2 so go rewrite your code). Java just recently (within the last 5 years started to innovate and add new features). And lastly, .NET and C# are open source, so I'm not sure why you fixated on Ruby's MIT license in the video.
"Any OpenID / OAuth provider will work"
I want to RUN the OpenID provider without paying $$$.
@@edandersenI didn't see what auth provider Django includes. Laravel includes middleware targeting their own ORM, so if that's the standard, fully 2/3 of all the online examples I've seen for pre-Open ID .NET auth has used EF, so you're already there!
But, if I want OpenID /OAuth Laravel doesn't provide a provider either. And on most projects, the auth isn't standalone, it's integrated, and most integrated authentication these days is providable via OpenID / OAuth.
@@edandersen Why not run keycloak, zitadel or something similar? They are free for commercial use.
C# does change its syntax if your coworkers check in code that uses the new syntax. So it's a valid point.
@@marcotroster8247 He meant that old code can still work with modern frameworks without changes, except for a few classes that changed.
I am on the opposite side =) I'd like MSFT to release features as soon as they are ready as it was with .NET Core 2.1, 2.2
Yes, I would much prefer non-breaking point releases. Why can't we have 8.1, 8.2, 8.3?
As a beginner I always wondered when and how this new thing came up in C# and its kind of frustating
Thats what I worry about. It appears the team is focussing on language minutiae at the expense of making this a great experience for beginners, i.e. the next generation. Thanks for the comment.
My recommendation if you are a beginner focus on other questions, that's not something you need ( at the beginning) to become a proficient C# developer.
There is a little difference between C# 10 and C# 12 tbh. As compared to C# 7 and C# 8 for example. I think they should be called C# 9.1 and C# 9.3 and the problem wouldn't exist
Yup after some time of not working/learning on C#, I tried scaffolding a Console Application on dotnet 8 and thinking where is the main method?
The whole industry is addicted to the new shiny toy. Is it for developers and users that a new product is introduced every year? I don't think so. It seems like a good question for a new person, which version will they start learning from? What about the learning content producers? I think software development is now a fair that moves forward with decisions without deep thought. Every application is loose, full of bugs and seems to have been developed in a hurry. The applications I used on 386 sx 25 hz computers were more responsive and faster than the ones I use now. The whole industry has turned into a clown show.
If not it's certainly trending towards a circus at least. Thanks for the comment.
You cannot make any money without releasing new products. I've been happily using free software like vim and Window Maker for the past 20 years or so. They haven't changed much or at all, they didn't need to change, they are still as great as they were 20 years ago. The difference with Microsoft bs is that the developers who have worked on these fine products have not become millionaires (nor have they ever intended) by sucking out money of their hapless customers/users.
As someone that’s been supporting applications which have been built in .Net Core 2.1/2.2/3.1/5/6 and most recently 8. The hardest part is justifying an upgrade to an existing API which is working, to a new version without any “business benefits”. So whilst I like clicking file-new and using the latest framework. Companies need to understand that these applications when building on .Net Core or front-end technologies are never done, they require yearly/ 2 year upgrades just as companies do with hardware (eg laptops).
Yep, software is for life, not just for Christmas. Thanks for the comment.
@@edandersen Is this a quote of yours? it's cool, am gonna take it :D
Nah I stole it from somewhere but I can't remember where
@@edandersen I know of a .net core 3 app C# 6 API (MVC) with a REACT class UI code base (all pod deployed) to replace a VB6 desktop app from 2003. That 3.5 year long project went belly up and the new plan is to continue using the VB6 app that, so far, has been doing fine with win32 api legacy code. VB6 for life. lol Perhaps they'll try again, but this time to re-write it in Excel/VBA for some real LTS. 😀
My company has to maintain the bulk of code in .Net Framework 4.x because we still need to support legacy Windows (~Windows 7) in manufacturing equipment (and installing new stuff on them is tempting fate and the owners blame you when their manufacturing stuff breaks), with the occasional port to CE Framework for small devices.
The client side can't just retire their old machines without a whole chain of decision making. When I get involved in the task, the machine's existence is baked into the project.
So my experience with the wider .Net ecosystem has largely been personal pet projects.
I just started learning c# as well, 4 month ago, from python background, to build desktop app. And to be honest I am excited that the language is moving fast. I agree that the strongest push c# eco-system need is a well funded open source community to lift a wide array of well supported packages. Such as Pandas, Jupyter, Django, etc... for python
agree. some of that VS license money needs to fund OSS
I've been .NET developer for 20 years. I love how C# and .NET evolves. Keep it coming fellas!
I agree with you. A much longer term support period makes perfect sense to me. People have other, real, serious work to do, so they don't want to be constantly chasing new features that are of little benefit. My Customer for example does not care about these changes, they care about the business solutions that I write and if they keep running, ideally for many years, without needing to be constantly updated.
5:50
Identity Server uses a standard (openid connect, which sits on top of oauth 2.0), so any other identity provider/authorization server that uses this standard can be easily implemented too (I don't know about the 2 others).
The documentation is just lacking some details and make it seem like there are only these 3 solutions, but in fact there are many others (to name a few: keycloak, auth0, adfs).
And even that is non exhaustive, there are other ways to secure applications that .net supports but are poorly documented.
keycloak self hosted appears to be the only viable option if you want control. Thanks for the comment.
Also, if you need a simple authorization / authentication, why not simply start with asp net identity?
If you really need an identity provider, azure entra id or auth0 or keycloak (among others) will be the de facto choice
@@edandersenthere are authentik, authelia, fusionauth and many more options for self hosted IAM. And of course another 10 hosted options.
There is the self hosted dentity/auth solution which came with .net 7 and enhanced with 8.
You also have OpenIdDict.
Yes, duende identity server is commercial now, but it is quite a permissive license and the community edition is free for commercial companies with < 1 million USD projected gross revenue.Yes there's a lot of new versions, but the amount of breaking changes is quite limited. I'd be pretty comfortable working with most .NET projects from 10 years ago, but if I'd have to update a JavaScript / node.js project I most likely have to rewrite it to a completely different framework/paradigm.
You’re hitting the nail on the head with the issue and a related issue of “big languages”. They’re just unnecessarily big and it feels like the engineers that keep inventing all these things for C# just don’t know when to stop. They’ve turned C# into Windows, by which I mean, they’ve crapped it all up. There’s a reason why MS needs hundreds of PhDs to work on Windows. It’s overly complex crap. There’s a reason why Linux is the most used application hosting OS. They’re streamlined.
Thanks for the comment!
I find myself not wanting to invest the time to write code in any language when I know the language and libraries are a moving target. At some point we are going to have to develop some languages, libraries, and UI toolkits that are good enough to commit to supporting for 20 years instead of rushing after what is new and shiny every 3. All I want to do now is make console applications because at least that interface isn’t going to leave me high and dry anytime in the next decade.
@@JethroBodine1422 I do appreciate that. I built a windows forms app for someone in .net 1.1 and it’s great it has an upgrade path all the way forward to today. My only lament is that when I need to build apps for Linux that there isn’t anything with that level of api stability.
Hi there, great comment. What would be a good e-commerce stack that will be good going forward? Thanks!
Well, there are standardized languages, and we also have languages that do have standard libraries very stable so this is not a problem, just choose better tools.
In UI there are HTML, CSS and web components very stable. It is those Javascript libraries that live all the time.
I've been trying to learn C# on and off since the beginning of this year, and I've made almost zero progress precisely because of all that you're describing, especially the versioning convention change. .NET this, ASP that. It's indecipherable.
I started my c# journey by messing about with unity, this was 10 years ago though, then managed to get an mvc job as my first proper software job at the young age of 30
After years of using C#/Wpf/WinUI I needed a secure web project and so I went with Angular, node etc... There's not a day goes by that I don't miss C#.
can you compare an Angular migration with a .Net migration? Angular has an history of really deep changes to syntax and framework, i don't think .Net has ever had something that require that effort... biggest change was probably async/await
About time somebody said this. I mean you are supporting .NET 4.8 well into 2020s something that came in 2019 and would be supported through this decade. Enterprises don't like updating applications every 2 years else they switch to something else.
I also agree, after the introduction of linq, mostly all features in C# were nice-to-haves. Then there are some features that even break the original idea of the language, like tuples, which I believe are a benchmark of bad separation of concerns.
I quite like tuples but some of the recent stuff really is a head scratcher. Thanks for the comment!
C# itself is adding new features, but these aren't at all mandatory. C# will be as valid now as it will be in 10 years (the only possible exception being code where the name field is used for backing fields, and its the first time that they will make a change that breaks code from an older version). So no C# isn't at all becoming harder to do. It's becoming a bit like Python in a sense, where there are just different ways of doing things depending on what your style is. Right now, most changes are aimes at performance and functional features. As far as the dot net api goes, that rarely gets deprecated to a point where switching versions of dotnet changes your interactions with the dot net api. You don't need to have the latest most fancy code. You don't have to understand all of C# it's language features. You don't have to use features you don't understand. The dot net common api does not rely on any specific C# features. The changes don't affect your codebase, nor do they force you to change your code. Nugget packages are a different story. Don't just update them to the newest version.
It gets harder and harder to read C# every year, especially for beginners who might not know where these new languages features were borrowed from.
@@edandersenwhy should a language aim to be easy to read for beginners?
@@youse600because every one used to be a beginner
@@edandersen You can enforce style with .editorconfig and raising analyzer rules to errors to guide the developers to pick appropriate constructs and avoid the ones you feel that are improper for a particular use case. C# is not Java and never was one. It is closest to the metal language with automatic memory management out of all the viable alternatives, that covers both high-level business domain modeling and low-level systems programming. So it is beneficial to look at it while having experience both in, say Python and TS *and* C++/Rust/C. This allows you to decide what kind of C# you want to use. People writing long ass types, abusing interfaces and getting carried away with func composition is not idiomatic code, never was and existed even in the first versions.
@@youse600 Because beginners often like to read code written by experts to find out how to do things. That was my experience when I started out in software engineering in the late 1970s.
It was probably easier then because (at least in the field I worked in) a lot of stuff was written in assembly languages.
I don't think the pace of C# updates are too fast, I think they feel too "half backedy". DU's for example, I'm not even sure how they will be able to optimize them without some runtime changes on the generics reification. But other than that I don't think C# is "getting harder for newcommers", you can learn the basics of C# very fast if you just don't take the job of needing to learn .
I dunno if the newcomers are actually saying it's confusing them (which they are) then I believe them. Thanks for the comment 😊
I like the evolving language but spot on with the central point of the support cycle length. I stick with .Net Framework 4.8 for my main clients as they need to know there is at least 5 years support going forward without being forced into expensive release cycles.
Yes, you are really forced onto an average of a 2-year upgrade cycles even though technically LTS lasts 3-years. Staying on LTS for the full 3-years does not help the average, for example:
.NET 6 (Nov 2021)
.NET 9 (Nov 2024, but goes out of support before .NET 11 or 12 are released)
Thus: Must upgrade to .NET 10 (Nov 2025), so you are averaging an upgrade every 2-years.
You either upgrade annually (which I do), or on a 2-yearly schedule on the LTS. It would be nice if there was an extra 15 months on LTS, so people could decide to skip an LTS version (and have 3-months to do the migration).
I LOVE how fast the language and framework are evolving - new features, new syntax, and major performance improvements. Keep em coming!
This is really interesting. I like how Java and Python both have very long support periods so that it is possible to ship an app and barely touch it for years (assuming using mostly standard library). With Rust I find compatibility to be so good that upgrades barely take any effort at all, loving that too
Well said. I’m rather tired of the two year hamster wheel as well. C# has put food on my table since 2002, and I’m immensely grateful to Microsoft for what they’ve given/sold us. They seem to have lost touch with the fact that regular old working class companies don’t have thousands of developers devoted to keeping up with the thousands of developers pumping out code at Microsoft. This pace made sense in the early days of Core to stabilize it, but not any more. I TOTALLY agree with your idea that security patch only support should go into effect after year 2 until year 4 or 5. ALSO, I think we can safely say C# is feature complete at this point.
I for one love the pace at which C# is evolving. Contrast that to Java and you know how lucky we are. And not once have I come across a change that made my old, time-tested habits invalid.
That's great news! Thanks for the comment!
Since there are quite a few new nuget libs that support .net Standard 2.0, I also use the .Net Framework 4.8 again, since the support there is tied to the Windows OS. With web api, however, I'm sticking with .Net but would also like to see an LTS+ version with 5-6 years of support.
I think C++'s 3 year major language release cadence is the best frequency (and the additional time means they can ensure better backwards compatible non-breaking changes). The .NET team could do major releases every 2 years if they're feeling impatient, but every year is overkill. It's funny and perhaps a little sad to see a site like Pluralsight update their C# course path to what WAS the latest version only for Microsoft to already be coming out with the next release by the time this happens. Instructors have to be feeling a little like Sisyphus trying to keep up with this ridiculous pace.
I'd be happy with 3 years yeah. Thanks for the comment!
I see both sides to this coin. I understand the hassle with updating pipelines etc but 3 years for LTS should be enough time for preparing for these updates. For STS its 18 months, which is much shorter but that's the tradeoff you get new features in shorter period of time. It is very expensive to have to maintain and support older frameworks (believe me I know) so I get Microsoft's desire to shorten things, and keep pushing the envelop with new features. The example in the video of very long support for 4.8 Framework is comparing apples and oranges. That is a totally different technology, so they knew they needed to support that much longer before folks made the plunge to .Net Core.
As a professional full stack developer which codes C# for a living I totally agree with your point. Instead of adding all of the syntactic sugar to C# and adding breaking changes every year, let's add things that are actually helpful like admin panels (like filament for Laravel), reorganize the documentation to make it easier for newcomers.
Breaking changes??
I have been using C# since 1.0 and I have very very rarely had to deal with any breaking changes except, most have been on the plattform change from .net framework to netcore and net framework does still supported.
.Net team wants to make a more modern language and I want that too. Recently they started to introduce breaking changes therefore longer LTS support makes sense.
I think C# is modern enough to be honest. Showing my age probably.
@@edandersen modern in the term of wider developer adaptation, like it should be par with the feature available in new and evolving languages like: go, rust, etc.
Modern language ideas are ****** IMO.
Keeping it simple and limiting the scope of effects is VERY important for creating stable code.
The new trends do everything they can to break everything in ways even long time users do not understand.
Many barely understand multi-threading, let alone they ways in which it can break code, so anything that makes it less obvious where things (can) go wrong is bad.
And anything that hides functionality that needs to be on the top of a programmers mind is bad too.
Most new features/syntax tends to muddy the water and result in executing code in plates and times that are less predictable.
And also, the separation between database and language is wrong.
Database access is fundamental to most applications, so a language needs to deal with that well and not stuff that into libraries.
Because C# did this wrong, a mess evolved around ORMs and other frameworks.
A similar thing can be seen with regard to dealing with the web.
It's just very unbalanced IMO, resulting in an explosion of libraries/frameworks, each adopting different patterns and language styles.
Few will want to support the mess that this created, old an new alike.
New features will not address the core problem!
I totally agree with your main point about needing longer LTS versions. I'm also on the same page about Microsoft sometimes changing stuff just to try and attract fans of popular languages, even if it doesn’t always hit the mark. Lately, it feels like they’re adding a bunch of features to appeal to Rust developers, like option and result types, and all the things thy did with nullables.
On one hand, it’s annoying that C# seems to jump on every new bandwagon, piling on extra features and duplicating stuff for the same tasks.But on the other hand, I get that not updating the language at all wouldn’t be the way to go either. There are some new features I don’t really see the point of, like being able to write actual method bodies in interfaces since .NET 6. Still, there are other new features I can’t live without now. I’m really looking forward to implicit fields in C# 13-I always hated not being able to have implicit member variables like with auto properties while still managing setters and getters and working with WPF. Plus, the collection expressions in C# 12 are awesome because you can pass collections to methods without having to refactor when the collection type changes. And the performance improvements in the latest versions are insane. Just upgrading can double your LINQ performance without any code changes. Honestly, there’s rarely a new feature I don’t end up liking once I get how it works.
I also get that some new features overlap with old ones without fully replacing them, especially since Microsoft has a long history of supporting legacy stuff (remember when they skipped Windows 9? Afaik because they didn’t want to retire code still checking for Windows 95/98 for compatibility). My main concern is that the magnitude of features coupled with the short release cycle leads to oversights from the .NET team. All these features and the quick release cycle might lead to some things slipping through the cracks. For example, I heard the new null check (variable is not null) is faster than the previous (variable != null), and some LINQ methods are way quicker now because they use Span internally, while others still don’t. It’s frustrating because I have to keep learning different ways to do the same thing - not because it is better, but simply because the other option has not been properly updated - with every new .NET version, and it can get pretty tiring.
I think if they could double the release cycle and extend LTS support, it would give the .NET team more time to polish new features and give all of us C# developers more time to maintain our apps before jumping to the next LTS version. That would solve a lot of the issues.
Fantastic comment, thanks for taking the time to write it out.
After programming for 15 years in c#, I want to switch to Java. There's a lot of cat n mouse with c#.
I bet not even c# creators know all the features and can keep up with the ever changing syntax and nuances. There are more nuances than keywords now
I gave up lol. Thanks for the comment!
It's much more a problem of how long is a version going to be supported. The language and also .net HAS to evolve to stay competitive.
When moving a critical .NET Framework app to Core, we realized the .NET Core implementation had a bug. I made an upstream contribution with a fix that was approved but now my patch will only flow to .NET 9 as it looks like only absolutely important commits are being backported to .NET 8 even though EoL is almost 1.5 years away. So now we have to hold off the migration from Framework 4.8 until .NET 9 is GA :)
So imagine if the cycles were 3-5 years long…
@@EraYaN If the cycles were 3-5 years longer, it would be expected that the fix could be queued for .NET 8 (like an 8.1) because more attention would be around to maintain it.
From a security point: If you have an active app in production (or in a mobile app store) you should build (and probably upgrade) once or twice each month. There are vulnerabilities discovered all the time. Having a long LTS only makes this worse. If you are in the microservice hell/heaven, you already have pipelines, and they should be doing most of this for you.
You absolutely should do this yes, but minor versions are not supposed to break stuff. I'm moaning about frequent breaking major versions
It's already difficult to justify migrating away from 4.8 as most apps in the wild just work. The short life cycles of core makes it even harder to justify. The basic argument seems to be the cool kids are over there and it will just run faster, however I never found 4.8 to be slow 🤷♂️ Don't get me wrong I've spent a year migrating everything but I've had to kick new features down the road while I did it.
Thanks for the comment!
That's a very necessary conversation to be had
.NET is going through the same issue Java had 10-12 years ago. If you come in cold or need to take on a new paradigm (like switching to a 'thick' client), it's quite difficult to determine what APIs to adopt and what docs or blogs are current.
I love C# and Dotnet and i switch to golang now. I love the one binary deployment and the better memory usage of golang.
Personally, I never even saw much of a point with the whole LTS thing. Especially with .NET. In my experience, almost every recent .NET version (at least since .NET 5 or so) upgrade has basically just been doing a search and replace of the target name, and update dependencies. Ex. replace "net7.0" with "net8.0" in the entire solution, and double check the diff to make sure it didn't replace something it wasn't supposed to.
Basically every new C# version also has come with at least one new QoL feature or syntax improvement, that while it doesn't in any way revolutionize anything, at least makes the syntax look nicer and cleaner. These are also never compatibility breaking, and are optional to use, so it's not like you have to go through the entire codebase immediately and update it to use them.
Its not always as simple as a find and replace. There *are* breaking changes and third party packages are not always updated on time. Thanks for the comment!
After 3 years all the third party libraries have updated. comon!
As a seasoned ASP developer I totaly agree with you. They tried to avoid the .Net framework "infinite" support time frame but, in my opinion, they went too far regarding lts releases. It's daunting especially for smaller shops.
To be honest I think they just copied NodeJS. Thanks for the comment!
C# is a better language in so many ways than python but python is more widely adopted. There is still great mistrust of microsoft and .net lacks the ecosystem that python has (e.g., pyspark and NLP) including the nice integration with lower level components, such as direct integration with C and use in microcontrollers.
Having worked in the Go ecosystem, much of what you mentioned really resonates with me. Go releases are usually focused on security and runtime improvements, not introducing new syntax, and when it happens, the community has fair warning that a major change to the language is happening. Given how complex C# already is, i think it would benefit MS to glean some tips from Go.
The choice of philosophie between C# and Go are just different.. Go pursuits minimalist and "afraid" of breaking changes. C# introduces as much keywords as it can think of to make the codes as expressive as possible. It is the reason why Go stays with 1.x for more than 10 years.. while C# got new version for every 2 years... I prefer something in the middle balances
Yes but much like Go, .NET runtime never ever tries to break on you. When people talk about breaks they mean surrounding ecosystem which is less stringent with backwards compatibility. The thing is - Go does *not* provide it. Instead, you are at mercy of release cadence of separate dependencies, which, surprise can and do take breaking changes. In reality, if you assume that .NET 6 and newer is the only target worth even talking about, you never had or will have any breaks whatsoever. Updating is just bumping a target version, redeploying and enjoying another +5-35% of performance. I can't believe how clueless .NET community is in its lack of awareness of how bad everyone has it elsewhere, and how good we have it if just by a degree of improvement that .NET went through in the last 5 years.
That's quite accurate what you said, and I havent thought much about it, but it's true, when I have to create a .Net microservices with some standars security protocols as JWT or WSSE, have no support at all but community, well, except WSSE for oasis that I had to create it from scratch.
people ask why startups don't use .NET and using nodejs, i would share this video and say this is why
You're wrong, a lot of them do...
.NET and nodejs have wildely different usecases. I would *never* start a very complex app with a javascript framework...
@RaMz00z i didn't mean no startups using .NET but most prefer Node over .NET and i think because of following reasons.
1. one language for frontend and backend (no context switching)
2. npm packages for literally anything
3. easy to hire developers and easy to find replacements( big thing for startups)
4. for most cases nodejs is fast enough
But i don't like to be a fan boy for any language or framework. I'm just saying nodejs is good enough for most startups.
So, you're saying that C# has become the new equivalent of the next JS flavor of the year?
I'm fed up of every project I have to open using different C# for the same thing, yeah. even worse now it's forked with nullable and implicit usings
My problem with dotnet isn't c# so much. It's that I have to re-invent the wheel every time I create something. Example - every MVC web site I create I need to spend 2-3 days creating a user management system. Even just listing users in the system is something you need to manually create.
If there were some sort of repo for components like this, I would be so so so happy.
100%. Thank you for being brave and posting on the wild west which is Twitter. I decided to learn c#, and it's been confusing to say the least, especially when there are a number of different ways to do things. If Microsoft are serious about the next generation of developers choosing C# then they need to make it novice friendly, releasing the the versions of the framework/language for a longer period of time, before releasing new versions will definitely help.
Long story short: .NET Should have releases every 2 years. Standard support for a version should be 4 years. Long support should be 8 years. End of story.
Sounds good to me.
Why, what is wrong with current schedule? Updating to new version is usually matter of an hour top. There is so little breaking changes between .NET 7 and .NET 8 that update was a breeze.
@@petrmalecik5661beacuse you upgraded from 7 to 8... i encourage you to migrate an enterprise Blazor app from 6 to 8 with all of the runtime changes, they just reinvented runtime for fun
yes!!
This is the only correct answer
Been doing C++ native for over 30 years. Using Borland and now embarcadero C++ Builder
Borland C++ Builder! Used it for years... vers 3, 4, 5, 6 .... I loved it.
@@jamesross3939 Also the most recent compiler uses the C++17 standard, they are experimenting with 23. Also its all CLANG so quality is very good.
I've been working with .Net since ~3.5 and I definitely agree. I think the rapid pace was beneficial when .Net Core was introduced as it gave some time to quickly iterate and improve on what was a new and radical change at the time. At this point though .Net feels pretty solid. It'd be nice if the LTS release window started to lengthen.
yeah I just want at least an extended support window. thanks for the comment!
As a novice, one of the things that attracted me to C# instead of JavaScript was the simplicity and less sugar coating of C#.
most people say "you don't have to use it" but in reality...
Giving how the Enterprise system works, that's not a bad idea.
I feel the same way. At the same time, if the app has developers around, couple of minor releases a year is a good idea anyway, just to keep the supportability in sync
Hot takes? Oooh I love those like hot cakes.
You know, I am fully onboard with a longer LTS.
In exchange, because I'm a madman that never considers consequences of his actions, I would like to finally see some actual breaking changes: old API being deprecated and eventually fully removed (e.g. non-generic IEnumerable, IComparable, IEquatable, etc.), System.Void being promoted to a first class citizen (Func, Task, ValueTask instead of Action, Task, ValueTask), ability to define functions at namespace -level, etc.
Bring back ArrayList for one final hurrah. thanks for the comment!
It is difficult to keep up, and I also have experienced trying to upgrade a project over multiple major versions which is also challenging. IMHO, Node has the same problem with major versions and breaking changes. It is even worse with all of the packages that you end up having g to wait for them to fix or even if they are still being maintained. I am happy they cut support earlier so we don’t have as much legacy code running on “supported versions”. It also frees up the teams from maintaining more older versions.
I agree very much, personally, though I'd go with Lts every 4 patches at 6-8 year terms.
That way you get larger chunks of feature sets to work with.
Agreed. 100%. Been with C# and .NET since the beginning and it's become somewhat of a Frankenlanguage trying to be everything to everyone. It's great to innovate but not at the expense of losing sight of what's truly important.
The auth example is very good. If I had to make a new stack today using .NET, I would probably do the OAuth server in something else than .NET seeing how complicated/messy that is.
I loved how laravel used to have everything set up out of the box when i worked with it, from routes all the way to orm, you go straight into building things, also artisan is better than dotnet cli imo. But to be fair c# is goated.
It is indeed goated. Thanks for the comment!
People will always disagree on particular choices, but I love how almost any annoyance and redundancy in the code has got removed within the last years. If anything in your code is duplicated and verbose, it's purely your fault. And the fact that at the same time the performance only improves, is absolutely amazing
yeah the free performance upgrades are great. thanks for the comment!
Outstanding! Well stated and I agree with just about everything you said. I was an early adopter in the v1 days (circa 2003). The move from "full framework" to Core was jarring and marked the beginning of this insanely aggressive release cycle and short support periods. Not enough people raised their hands back then, but I appreciate people like you that are raising awareness. New subscriber here! :)
Thanks!
To be honest, early days of Core were great. Project K, JSON based project formats. Peak was probably 2.1 with the Framework runtime mode.
My thoughts? Rapid framework implementation for a language that's not really built for the web and is never given time to mature.
thanks for the comment!
C# is the Microsoft Word of programming. You use it mainly at work, in big companies, and what you do with it will still be used 15 years later. You can't say the same about a lot of other web frameworks.
Every few years, we compare C# to the current frameworks, and we forget that we did the same a few years ago and the previous other frameworks are no longer relevant.
Still, I welcome effort towards minimal API. And I would like to see more effort put towards Polyglot Notebooks, which allows to write C# in a friendly and visual environment.
So, yeah, if your .NET X framework is relevant to your company for 15 years, more than 3 years of long term service would be a good thing.
I predict that in the not too distant future, there is going to be a massive tech-debt problem caused by React and Node! At least with .NET apps, they all have the same foundational structure. The same cannot be said of React where every app is different because apparently, not being 'opinionated' is the holy grail! .NET may apply some opinionation, but at least with a base set of rules, you end up with a better structured, more maintainable application.
I agree with you. The most annoying aspect to me is that now when I write by-the-book C# code from two versions ago, Visual Studio is graying the code out and suggesting I "fix" or "simplify" the code, using (in my opinion) these uglier and less readable syntaxes I would rather not use.
yeah that's really annoying
I agree with Microsoft giving LTS releases more than 3 years of support, eg your 6 year proposal sounds good. I disagree with the idea that there should be long intervals of many years in which no new features are released. Those lists of features in new C# versions are actually VERY useful and make the language much MORE attractive to use, they did so for me. Those who want to use them shouldn't have to wait 5 years or whatever to get them. Those who don't want them can ignore them. Every other programming language has major feature releases around annually or so. See also Java.
Okay how about this
Release the new features but in non-breaking point releases. Why can't we have 8.1, 8.2, 8.3?
@@edandersen I would agree with that.
@@edandersen No. you can stay in the past, but many people want the fast pace of c# development
You’re right. I have been saying the same thing. The time you need to learn the new plus adaptation is not enough. When ever you think you’re almost there with the new features , there comes a new release.
Stay with .NET Framework if you don't want new features in framework or language because it's too much 'learning'.
I honestly, don't want .NET Framework 'grandpas' who thought that < 4.7 was good enough deciding whether and what we should have in .NET Core/5+.
Regarding LTS, I agree and would welcome longer LTS, 4 or 6 years. But feature-wise? C# is amazing but still we are missing a lot of features supported in other languages that would be great to have. Quicker release cycle also helped to shape the language to be so amazing today.
So in my opinion they should drop some of the dogmas they were following and start introducing more breaking changes if they will allow the language to improve.
.NET has the largest keyword count of all the major high level languages. Beats C++ by a mile. All the new stuff is literally catering to people who are lazy to type. Gone are the days of LINQ and WPF like features.
I do with they would remove some of the bloat and clean up the runtime a bit
Break backwards compatability if necessary
We cant let the past hold back the language
Why can't they add language features in a non-breaking 8.1, 8.2, 8.3 release and make that LTS last 4-6 years? Then everyone would be happy
Its absolutely true with each version they make change in a way that its a nightmare to upgrade. We just want to build something and live our lives.
I agree, for a beginner to work with . Net/ C# there are lost of confusion and feel like not stable after these many years in the industry.
Wow. I was actually thinking about this today. Change is good but At the current rate it is bad in my opinion. I started with .Net about 4 years ago and its hard as a new learner.
I've spent most of my career working in .NET and I enjoy it for the most part. The vocal online community is way behind the times and stuck in their ways. I finally found a job that is value to customer oriented and not fixated on design patterns and antiquated arbitrary rules that slow development to a crawl. All code bases become hard to maintain over time. Doesn't matter if you spend 80% of your time planning out your next move. Requirements change and tech debt is inevitable.
I also agree that not having good starter templates is a huge negative, especially the auth part. Massively hinders people that want to try it out when they're coming from frameworks that are vastly more developer friendly.
Thanks for the comment!
If there's an adoption problem for C#/.NET, it's likely not the fault of C#/.NET. It's possibly due to improvements in the JS/TS ecosystem reaching significant levels. Lack of adoption need not be caused by a "fault" in System A, but by improvements in System B.
System A needs to be better than System B. Especially if people are paying to use it.
I agree there should be longer-term supported versions. That Framework 4.8 is the currently longest-supported version is insane.
On the other hand, there's the opposite problem - look at Java, where a lot of devs are stuck on an old version of the language because it's the one with long-term support. I mean you CAN use more modern JDKs if you want, but getting started as a beginner right now is kind of frustrating - since there's no clear answer to which JDK to start with…
I agree that the LTS version should have a longer support cycle. If you are developing anything of reasonable complexity just managing update cycles can become a serious drain of resources on a three year cycle. Six years for LTS and two years per interim cycle seems very workable while allowing plenty of time for new features.
Some comments here are sort of insane to me. How can you be concerned about about updating .NET version often even if you needed to do it every year.
Do you guys seriously not keep your dependencies updated? This is not different than any other dependency. The amount of code changes you need to do in .NET is basically nothing.
People put way too much weight on .NET 6 vs .NET 7 etc. Think of it as .NET 1.6 to .NET 1.7 and keep your minds from rotting :)
1.6 to 1.7 would imply zero breaking changes and all dependencies keep working even without updates. This isn't the case from 6 to 7.
php/ts/go guy here. I just recently got into c# and I don't have that problem Just watch the whats new in c# 11-12-13 videos first, before doing the outdated tutorials and use the new versions of doing things.
but, on the other hand, I've been doing programming for 10 years. bugs anc console warnings never scared me.
I wish c# was a bit faster though. It has some nice syntactic sugar stuff, but, I quite like go right now, wich also destroys it in terms of performance.
I agree with you. C# is getting more and more complex. Too many ways to do one thing. I wish C# team could think more about simplicity. Sometimes less is more.
Your example about support life cycles. If you're releasing an app 1 month before .NET 8 stable is scheduled to come out, you should already have had months to years of advance knowledge of any breaking changes, and you should have made your app compatible with .NET 8 already long before it was released, so upgrading should have been trivial. It's not like no one knows what it contains before it comes out. For that matter, for a brand new app, you could have had it target .NET 8 from the start, even if its not quite final, because your app is brand new anyway.
Nah I don't think most normal orgs will be running a separate ".NET 8 Preview" build of their app during development.
If you release on the latest at the time LTS, sorry but I think you deserve way more than a year of support.
@@edandersen You don't have to run a Preview build, just read the occasional release notes leading up to it, and don't use the .NET 6 features that they removed in the first place. Then you can update to .NET 8 after it comes out stable with minimal fuss.
I hobby code and did many a project in C# and .NET, receiving praise from even professionals and having some projects on Github, but I think the kids don't like C# or MSFT, ironically since they often have the best tools. I loved Silverlight since it was so easy to build a professional looking UI. I worked in Silicon Valley in management for a couple of decades and retired in my 40s when my ship finally came in. Not an IPO, but a huge inheritance. Good luck to you reader.
'.NET AND C# ARE IN TROUBLE. HERE IS WHAT I'D DO!' - even this title arouses severe anxiety and depression.
Any suggestions for a better title?
@edandersen DOTNET is in a ickle pickle. BUT THERE'S A SOLUTION!
@@zebcode pretty good tbh
@edandersen yeah easy for me to critique something someone else has already made isn't it?
Not sure I follow
I think everything is fine with C#, except when it comes to Blazor. It should be something similar to Vuejs engine-wise with the razor syntax (which is beautiful). I mean, there's people literally using vuejs in the middle of blazor SSR projects. I don't like how bulky the page download is. Makes no sense.
I agree I love Razor syntax (apart from tag helpers). Thanks for the comment!
I think everyone thought of this but rarely going public about it. Really exhausting to catch up all these dynamics on .NET and C#. Now they want to add to C# even more of the functional programming paradigm on it, it might be great but also could render C# unlearnable. It become like riding a roller-coaster, which is exiting and exhausting at the same time
I wonder why they aren't going public about it? Thanks for the comment.
@@edandersen probably it is because it is like roller-coaster, it is exiting until it becomes exhausting. It seems that now the folks began to show the symptoms of exhaustion :)
@@kastriotgashi I think there is an economic angle. This was fun in 2018 when money was cheap. Not so much any more.
@@edandersen yeah, absolutely!
Started off my coding journey with C# and .NET, Razor, Blazor, MVC, API, WPF the whole shebang. Now I work in SvelteKit, being a beautiful language that it is the platform being a corporate cash cow really brings it down. If I pick up anything beside TS now I think it's gonna be Go.
Only issue I have with the pace of language development, is that several features come out half baked, and are either missing useful bits or have ramifications that must be supported forever more.
As an example of the former, introduced in C#8 is the amazing nullability annotations for references, but it has some glaring holes, like how Task functions will not respond to `NotNullIfNotNull` and similar attributes.
Maybe they rushed the features to hit arbitrary annual release dates. Thanks for the comment!
C# release schedule and short LTS 2 year time (don't even get the point of short term support in big corporate) is exhausting. Bigger problem is the cost of constantly updating existing Azure code bases. Big corporates are starting to put the breaks on coding. Maintenance is becoming a big headache for regular companies.
Being saying for years that - need more focus on WINDOWS frameworks, WINUI, WPF, ASP - expand them make them better, add controls, add generation, and make them look and interact better. Too much emphasis on the language and too much emphasis on development on non-windows platforms ( MAUI)
C# has become C++. Two developers can create code that looks like a completely different languages depending on the features they choose to use. It's maddening.
very well put, yes that's my key worry. it's multiple forked languages at this point. Go doesn't have this problem I'm told.
totally have this problem where I work apps get stuck with so much tech debt because they were written in earlier versions of .net core and quickly became unsupported, impossible to keep up all apps
8:05 If you are into microservices and you have got hundreds of them - .Net upgrades and C# versions are last things you should be worried about.
Agree