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.
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.
C# is probably my primary language, I can write code that with little to no third-party dependencies that runs for years. It may be a little harder to get into the .NET, but the ecosystem is fantastic and has batteries included. I work for a company who has a whole legacy of Node JS with hundreds of dependencies that are out of date, or worse outright abandoned. I couldn't recommend Node to any startup, keep that shit off the server. I'd pick a language with a quality standard library over a ecosystem flooded with low quality libraries any day, NPM is a cesspit in my opinion.
No startup would choose .net as starting point, due to the amount of resources that need to be put in the closed microsoft ecosystem just to make a basic product.
TS is my primary language with node. I'm the old school vb > vb.net > c#, f#, kind of guy. However, I had to leave that ecosystem many years ago due to their lagging behind in the technologies. If anything new is happening, it is happening on node, go and rust. You're talking SDKs, database providers, support, etc. The package issue is platform agnostic. Dependency hell can be mitigated by locking all packages and sticking to what you know and research it properly. The same issues that plague npm also plagued nuget. Another issue at the time of leaving MS ecosystem was the fragmented handling of .net core, .net 4.5, etc. There was just too much going on. However, I'm seeing this with node now. There's edge runtimes, node runtimes, native runtimes, deno, etc. My experience is with enterprises, banks, startups/hypergrowths > acquisition. I've seen .net work in startups, but we eventually moved services to node. Then in the hypergrowths, they started with node and moved services to go. At this point, my experience is stacks like this: Node | PHP | Python > Startups Go | Rust > Scaleups .NET > Enterprises It would be interesting to see what the next 2 years look like as these things move in waves.
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?
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?
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.
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.
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
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.
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.
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.
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 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.
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.
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?
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
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.
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 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 .
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).
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.
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.
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 :)
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.
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.
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.
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.
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.
.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.
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! :)
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
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.
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.
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.
.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!
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
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.
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.
I do not understand why the LTS being "only" 3 years long is a big deal, usually the only thing needed is change the target framework inside csproj. There are almost none breaking changes between versions.
@@edandersen Yes, you did but what is a chance of the breaking change affecting your project, if you go from previous to next version? I mean you can always update send it through CI/CD pipeline and see if some tests are broken or not.
Being a consultant, I can say the short LTS is ridiculous. We have customers that we finish some project for and in a very short time they have unsupported frameworks running in production. They have to hire expensive consultants to fix it because they have no in-house developers. And they see literally zero business benefits going from e.g .NET 6 to 8.
@petrmalecik5661 Unfortunately the breaking changes do really affect applications and it is sometimes hard to spot. In my company we have about 50% success rate of the upgrade being indeed “just change the target framework and build stuff”. Unfortunately the other 50% is much harder to deal with. I do want to note that this is mainly due to behavioural changes in EFCore, rather than the .NET runtime itself, or when dealing with Azure Functions.
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.
Yes .NET has a bigger problem - it's a tightly controlled ecosystem. Microsoft needs to ask themselves - what are the best open-source projects that exist in C#? Why none of the widely used framework/libraries are in C#? Example Kafka, Airflow, Cassandra, Elasticsearch, Hadoop, Kubernetes, Docker, Temporal, Jaeger, Prometheus, Redis, MongoDB ... the list is endless.
I don't even use C#, but the message you are relaying is a widespread issue, not confined to C# and I agree. There is enough to do, without having to trawl through changelogs & perform version migrations, so often. I love new shiny things, but there is a time & place for it - not in production apps that I want to ship & essentially forget about for years. With people saying "well, if you don't need the new features, it is easy to upgrade".. Not exactly, I mean, the thought process is that if you are already taking the time to migrate, you should probably be migrating to newer features as well - especially where the way it is implemented has been improved with the new features. When someone else looks at the implementation in 2-3 years time, they will be expecting to see & will want to use, the newer features.. which becomes an even bigger migration process, as you have let your codebase get years behind.
Agree with you, Ed. In my enterprise - getting the latest version of Visual Studio installed is a real pain. Not to mention getting our shared build servers and release pipelines updated.
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.
@@petrmalecik5661 In a small or medium personal project, yes, you’re right. But remember that supposedly one of .NET’s strengths is fitting very well into large corporate environments, and this is where you can’t expect to provide maintenance for only 3 years. Where is the advantage it provides to corporates then? That’s what I mean, and even though the changes between versions are "minimal," they force you to review everything, and you lose a lot of time doing this, while you leave other sections like Swashbuckle, Identity, EF Core, and a thousand other more important things starving.
@@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
The last years of C# language/syntax enhancements felt like Microsoft had a bunch of fresh university graduates knock themselves out. Just as if someone had a "Coding for Dummies 101" book for breakfast and then puked all over the C# spec sheet. I am not saying I am against well thought progress and reasonable evolvement, but for Pete's sake, we are doing C# here and not Haskell or Python or Rust or whatnot. On top of that, those changes were not even improvements in the sense of stuff you couldn't do before, it's mostly syntactic sugar coating.
I think you hit the nail on the head when you said "I don't work for Microsoft". I.E. You don't have the right context to truly answer the question of why they do these things. So you're not in a position to state that ".Net and C# are in trouble". Oh, you're also completely wrong about not being able to write a secure API without using Azure or Duende. There are many 3rd party options - Auth0, Okta, and of course you can also use the big tech third party auth options too: Twitter/X, Google, Amazon, etc.
I want to issue the JWT tokens myself. Auth0, Okta, Azure, Twitter, Google etc are all outside my infrastructure. Now that using Duende involves getting the procurement department involved, Keycloak is the best bet I think.
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.
My biggest problem with C# is that Microsoft has abandoned Xamarin's mission to keep mobile bindings up to date. Xamarin always tried to get bindings for new APIs out as soon as possible. Also, Xamarin Forms is losing support, even for security updates, and MAUI is a gong show.
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 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.
Dropping general C# advances for webdev tools is a very limited view on the net ecosystem. I'm happy if they continue with things like spans and finer control over memory. My big wish would be stealing compile time expressions.
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.
4 Different ways to declare / define / write the same thing is a problem not just for beginners. However, when you are looking for examples / documentation when trying to solve problem, the solutions are either out of date and don't follow the syntactic pattern you have adopted, So now you got to interpret different syntactic styles when looking at different answers to the same problem, and either convert to your current style in order to keep the code cohesive, or else just copy in the proposed solution is the different style - cos nobody has that much time. Its like learning 3 different languages, piled on top of that the various libraries and object models. Way Too Much!!! I wish the team would stop introducing shortcuts for keywords., just so we can type less letters on the keyboard. Seriously Auto-complete has come a long way. They need to spend more time on bringing legacy libraries up to date - thinking about asynch / winforms / oledb for instance. Tens of thousand of developers are still using these libraries every day. It would be a good investment of time for microsoft.
If they were to slow down, adoption would only get worse. Make it even more of a legacy language. They have to keep up with alternatives. And the upgrade paths are honestly not that bad unless you are mucking with internals you shouldn’t.
I don't think people switch platforms because the language now has some missing syntax. c# was never a problem, it's an amazing language. The ecosystem and what you get out of the box for building apps with is IMO. Thanks for the comment!
@@edandersen but it does matter for the perception and it’s already really hard in technology selection meetings to even get .NET considered. And honestly the LTS duration is rarely a consideration. Developer “feel” and stereotypes are much more important.
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
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.
C# leans towards overly complex solutions, which will generally require integration with Microsoft components for complete solutions. In addition to MS targeting management and project managers with unrealistic benefits and ROI, the strategy smells of 'lock in'! BUT, resistance is futile and only leads to despair.
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 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.
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.
There is a Windows problem, and a desktop application problem. Whats the platform we’re supoosed to use? Not wpf? Not Winform? WinUI version something?
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.
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.
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.
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.
you are right Ed , I Am new and I am learning .Net and Microservices and i Found Not just Identity but everything observability and tracing and monitoring depend on Azure . Forgive My English it is not good
I started by thinking you were plain wrong. I thought the post shared was pretty agist and unnecessary to prove your point. But I saw the video through to the end because I wanted to understand what you're saying. I have to say it was very interesting. I think I agree with you.
@@edandersen Yes I understand it wasn't your post but I wouldn't have highlighted it. Honestly though it's a minor criticism for what was otherwise a very interesting angle. I think agism in tech is an issue that is seldom discussed. So much experience goes down the drain when we devalue developers based on their age / perceived slowness. Every good developer knows that often you need to "go slow in order to go fast", in other words "think twice, code once". Perhaps this could also make for an interesting talking point in on of your videos in the future? Of course I'm not dictating what you should post on your own channel but I think it would be great to raise awareness.
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.
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.
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!
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 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 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.
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.
What is the .NET Team exactly? How many people? Working on what exactly? With .NET being open source, the difference is blurred between .NET Team, Microsoft employees working on a repo, and everyone else. Also, what is the focus of the .NET Team? What is their official purpose, or stated goal? I would be glad to get answers on this topic!
Exactly 😂 its like I started yesterday learning .Net 6 and out of nowhere there is .Net 8...same goes for the servers on azure. You just planed everything, got the budget and so with the customers and you can start all over again. Projects are taking sometimes 1-2 years until go live. You can upgrade directly after...😢
100% agree. We are still starting new client and server projects in .net4.8 since it’s the only .net supported into the 2030’s We are doing limited MAUI it is shocking buggy. Why don’t they just fix what they have.
I personally have found many of the new features to solve problems I have naturally identified. To me, this is not only desirable, but makes it easy to learn. However, giving new devs new syntactic sugar too early is confusing and counterproductive. Microsoft docs do need improvement. And AI can’t help because they are trained on that garbage. It is a very human problem and Microsoft has never excelled at UX polish. The only reason all this stuff is good for devs is because they are devs and they dogfood it. Customers that aren’t already in the MS loop will be the ones to run into their lack of UX focus.
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.
i 100% agree that it needs to have FEATURES like python or rails, not simplifying the syntax to look like them 😂, for auth, absolutely they'd shell auzure 😂 but you can always implement auth urself using jwt
hummm well for the authentication and authorization you have identity framework core ( not the duende one, I'm talking about the core framework ) and it is way better than something as passport js, but yeah, the admin dashboard panel its something that is missing compared to alternatives, and I also agree c# features are too much sometimes
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.
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.
C# is probably my primary language, I can write code that with little to no third-party dependencies that runs for years. It may be a little harder to get into the .NET, but the ecosystem is fantastic and has batteries included.
I work for a company who has a whole legacy of Node JS with hundreds of dependencies that are out of date, or worse outright abandoned. I couldn't recommend Node to any startup, keep that shit off the server. I'd pick a language with a quality standard library over a ecosystem flooded with low quality libraries any day, NPM is a cesspit in my opinion.
An astute observation. Thanks for the comment
No startup would choose .net as starting point, due to the amount of resources that need to be put in the closed microsoft ecosystem just to make a basic product.
@@ZiosNeonall 3 startups I worked for are .Net 😅
Ah man, it's not closed, everything is open source, no one is forcing you to do things a certain way.
TS is my primary language with node.
I'm the old school vb > vb.net > c#, f#, kind of guy.
However, I had to leave that ecosystem many years ago due to their lagging behind in the technologies.
If anything new is happening, it is happening on node, go and rust. You're talking SDKs, database providers, support, etc.
The package issue is platform agnostic. Dependency hell can be mitigated by locking all packages and sticking to what you know and research it properly. The same issues that plague npm also plagued nuget.
Another issue at the time of leaving MS ecosystem was the fragmented handling of .net core, .net 4.5, etc. There was just too much going on.
However, I'm seeing this with node now. There's edge runtimes, node runtimes, native runtimes, deno, etc.
My experience is with enterprises, banks, startups/hypergrowths > acquisition.
I've seen .net work in startups, but we eventually moved services to node. Then in the hypergrowths, they started with node and moved services to go.
At this point, my experience is stacks like this:
Node | PHP | Python > Startups
Go | Rust > Scaleups
.NET > Enterprises
It would be interesting to see what the next 2 years look like as these things move in waves.
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?
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?
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.
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 ??
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.
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
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.
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?
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.
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 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.
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.
Maybe it is just slow developers and developers "stuck" in their spaghetti code from all the free JavaScript based frameworks!
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
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.
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.
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.
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 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 😊
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 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?
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!
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.
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.
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.
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.
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.
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.
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.
That's a very necessary conversation to be had
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.
.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.
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.
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!
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!
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.
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.
.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!
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
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.
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.
Yes. Have a .NET version 10 and freeze it 5 years
I do not understand why the LTS being "only" 3 years long is a big deal, usually the only thing needed is change the target framework inside csproj. There are almost none breaking changes between versions.
I think I put on screen lists of breaking changes.
@@edandersen Yes, you did but what is a chance of the breaking change affecting your project, if you go from previous to next version? I mean you can always update send it through CI/CD pipeline and see if some tests are broken or not.
Being a consultant, I can say the short LTS is ridiculous. We have customers that we finish some project for and in a very short time they have unsupported frameworks running in production. They have to hire expensive consultants to fix it because they have no in-house developers. And they see literally zero business benefits going from e.g .NET 6 to 8.
@petrmalecik5661 Unfortunately the breaking changes do really affect applications and it is sometimes hard to spot. In my company we have about 50% success rate of the upgrade being indeed “just change the target framework and build stuff”. Unfortunately the other 50% is much harder to deal with. I do want to note that this is mainly due to behavioural changes in EFCore, rather than the .NET runtime itself, or when dealing with Azure Functions.
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!
Yes .NET has a bigger problem - it's a tightly controlled ecosystem.
Microsoft needs to ask themselves - what are the best open-source projects that exist in C#?
Why none of the widely used framework/libraries are in C#?
Example Kafka, Airflow, Cassandra, Elasticsearch, Hadoop, Kubernetes, Docker, Temporal, Jaeger, Prometheus, Redis, MongoDB ... the list is endless.
I don't even use C#, but the message you are relaying is a widespread issue, not confined to C# and I agree.
There is enough to do, without having to trawl through changelogs & perform version migrations, so often.
I love new shiny things, but there is a time & place for it - not in production apps that I want to ship & essentially forget about for years.
With people saying "well, if you don't need the new features, it is easy to upgrade".. Not exactly, I mean, the thought process is that if you are already taking the time to migrate, you should probably be migrating to newer features as well - especially where the way it is implemented has been improved with the new features. When someone else looks at the implementation in 2-3 years time, they will be expecting to see & will want to use, the newer features.. which becomes an even bigger migration process, as you have let your codebase get years behind.
Agree with you, Ed. In my enterprise - getting the latest version of Visual Studio installed is a real pain. Not to mention getting our shared build servers and release pipelines updated.
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.
@@petrmalecik5661 In a small or medium personal project, yes, you’re right. But remember that supposedly one of .NET’s strengths is fitting very well into large corporate environments, and this is where you can’t expect to provide maintenance for only 3 years. Where is the advantage it provides to corporates then? That’s what I mean, and even though the changes between versions are "minimal," they force you to review everything, and you lose a lot of time doing this, while you leave other sections like Swashbuckle, Identity, EF Core, and a thousand other more important things starving.
@@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!!
The last years of C# language/syntax enhancements felt like Microsoft had a bunch of fresh university graduates knock themselves out. Just as if someone had a "Coding for Dummies 101" book for breakfast and then puked all over the C# spec sheet. I am not saying I am against well thought progress and reasonable evolvement, but for Pete's sake, we are doing C# here and not Haskell or Python or Rust or whatnot. On top of that, those changes were not even improvements in the sense of stuff you couldn't do before, it's mostly syntactic sugar coating.
Yeah they are definitely borrowing from elsewhere. Thanks for the comment!
I think you hit the nail on the head when you said "I don't work for Microsoft". I.E. You don't have the right context to truly answer the question of why they do these things. So you're not in a position to state that ".Net and C# are in trouble".
Oh, you're also completely wrong about not being able to write a secure API without using Azure or Duende. There are many 3rd party options - Auth0, Okta, and of course you can also use the big tech third party auth options too: Twitter/X, Google, Amazon, etc.
I want to issue the JWT tokens myself. Auth0, Okta, Azure, Twitter, Google etc are all outside my infrastructure.
Now that using Duende involves getting the procurement department involved, Keycloak is the best bet I think.
@@edandersen roll your own security is an anti-pattern, my friend. And you can still use Identity Server 4. You just won't get support for it.
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.
My biggest problem with C# is that Microsoft has abandoned Xamarin's mission to keep mobile bindings up to date. Xamarin always tried to get bindings for new APIs out as soon as possible. Also, Xamarin Forms is losing support, even for security updates, and MAUI is a gong show.
Xamarin was great in it's hey day absolutely.
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 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!
Dropping general C# advances for webdev tools is a very limited view on the net ecosystem.
I'm happy if they continue with things like spans and finer control over memory.
My big wish would be stealing compile time expressions.
I love C# and Dotnet and i switch to golang now. I love the one binary deployment and the better memory usage of golang.
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!
Yes, agreed. .NET updates are as frequent as changing underwear. And as one other commented, is reaching the law of diminishing returns.
4 Different ways to declare / define / write the same thing is a problem not just for beginners. However, when you are looking for examples / documentation when trying to solve problem, the solutions are either out of date and don't follow the syntactic pattern you have adopted, So now you got to interpret different syntactic styles when looking at different answers to the same problem, and either convert to your current style in order to keep the code cohesive, or else just copy in the proposed solution is the different style - cos nobody has that much time. Its like learning 3 different languages, piled on top of that the various libraries and object models. Way Too Much!!! I wish the team would stop introducing shortcuts for keywords., just so we can type less letters on the keyboard. Seriously Auto-complete has come a long way. They need to spend more time on bringing legacy libraries up to date - thinking about asynch / winforms / oledb for instance. Tens of thousand of developers are still using these libraries every day. It would be a good investment of time for microsoft.
You are so right, and I am so happy I found your channel.
If they were to slow down, adoption would only get worse. Make it even more of a legacy language. They have to keep up with alternatives. And the upgrade paths are honestly not that bad unless you are mucking with internals you shouldn’t.
I don't think people switch platforms because the language now has some missing syntax. c# was never a problem, it's an amazing language. The ecosystem and what you get out of the box for building apps with is IMO. Thanks for the comment!
@@edandersen but it does matter for the perception and it’s already really hard in technology selection meetings to even get .NET considered. And honestly the LTS duration is rarely a consideration. Developer “feel” and stereotypes are much more important.
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
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.
C# leans towards overly complex solutions, which will generally require integration with Microsoft components for complete solutions. In addition to MS targeting management and project managers with unrealistic benefits and ROI, the strategy smells of 'lock in'! BUT, resistance is futile and only leads to despair.
Blimey
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!
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!
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
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
There is a Windows problem, and a desktop application problem.
Whats the platform we’re supoosed to use? Not wpf? Not Winform? WinUI version something?
Who knows
Isn't that what they're trying to solve with the .net aspire. A battery included version? or am I missing something?
That's my hope. I talk about it in this video: th-cam.com/video/9dOKLRbDem4/w-d-xo.html
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.
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.
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.
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.
you are right Ed , I Am new and I am learning .Net and Microservices and i Found Not just Identity but everything observability and tracing and monitoring depend on Azure . Forgive My English it is not good
I started by thinking you were plain wrong. I thought the post shared was pretty agist and unnecessary to prove your point. But I saw the video through to the end because I wanted to understand what you're saying. I have to say it was very interesting. I think I agree with you.
Blimey, thanks!
For the record it wasn't my post. But it was the most important response. .NET is in danger of being aged out IMO.
@@edandersen Yes I understand it wasn't your post but I wouldn't have highlighted it. Honestly though it's a minor criticism for what was otherwise a very interesting angle. I think agism in tech is an issue that is seldom discussed. So much experience goes down the drain when we devalue developers based on their age / perceived slowness. Every good developer knows that often you need to "go slow in order to go fast", in other words "think twice, code once". Perhaps this could also make for an interesting talking point in on of your videos in the future? Of course I'm not dictating what you should post on your own channel but I think it would be great to raise awareness.
@@zebcode Agism in tech is an extremely important issue, I agree. Food for thought. Thanks!
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.
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.
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.
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!
'.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
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 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 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.
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.
What is the .NET Team exactly? How many people? Working on what exactly?
With .NET being open source, the difference is blurred between .NET Team, Microsoft employees working on a repo, and everyone else.
Also, what is the focus of the .NET Team? What is their official purpose, or stated goal?
I would be glad to get answers on this topic!
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 think the biggest problem is the way M$ deals with open source packages. some are consumed by corporation discouraging comunity to develop more libs
Can you elaborate
Exactly 😂 its like I started yesterday learning .Net 6 and out of nowhere there is .Net 8...same goes for the servers on azure. You just planed everything, got the budget and so with the customers and you can start all over again. Projects are taking sometimes 1-2 years until go live. You can upgrade directly after...😢
Just update your csproj file bro! It's easy bro!
@@edandersen did you watched your video? 😉😃 I wish it was that easy irl
100% agree. We are still starting new client and server projects in .net4.8 since it’s the only .net supported into the 2030’s
We are doing limited MAUI it is shocking buggy. Why don’t they just fix what they have.
I personally have found many of the new features to solve problems I have naturally identified. To me, this is not only desirable, but makes it easy to learn. However, giving new devs new syntactic sugar too early is confusing and counterproductive. Microsoft docs do need improvement. And AI can’t help because they are trained on that garbage. It is a very human problem and Microsoft has never excelled at UX polish. The only reason all this stuff is good for devs is because they are devs and they dogfood it. Customers that aren’t already in the MS loop will be the ones to run into their lack of UX focus.
Giving how the Enterprise system works, that's not a bad idea.
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.
i 100% agree that it needs to have FEATURES like python or rails, not simplifying the syntax to look like them 😂,
for auth, absolutely they'd shell auzure 😂 but you can always implement auth urself using jwt
hummm well for the authentication and authorization you have identity framework core ( not the duende one, I'm talking about the core framework ) and it is way better than something as passport js, but yeah, the admin dashboard panel its something that is missing compared to alternatives, and I also agree c# features are too much sometimes