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.
Microsoft shops: "I want better user experiences for my devs and clients, so I can make more money." Microsoft: "What the hell is a 'User'... 😮?" Devs: * still reading the stack trace*
@@anthonylosegoexcept LLMs are complete retards and can barely get a documentation page as pretty and functional as Django's up. Also, you really don't need AI to do this...
@blo0m1985 skill issue. C# is not bad at all to read. It's the organization of code and learning to not spew LOC past the monitor width that escapes some devs....they know who they are....
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...
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.
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.
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?
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.
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?
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.
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
Is something is stopping .NET developers to still use .NET Framework 4.8? ;-) * It supports Windows 7+ * It's preinstalled with Windows 10 * It has 95% of all needed features * It's still supported * It generates small *.exe and *.dll files So if you "just need .NET" - why not use 4.8? It doesn't support Mac or Linux tho.
@@igorthelight Some people like me for example still use .NET Framework 4.8. We moved the code to Azure some time ago but at 4.7 version. And we will migrated it to NET.Core. One of the reasons it for example azure functions v1.x will not be supported after 14th September in 2026. Kinda hard to predict how long it will take to actually do it. Of course users wont be happy as it will mean no new features for let say a month since the team will be ocuppied with this "unproductive change" ;).
As desktop app developer, I get quite frustrated that these days, .Net is synonymous with web development. Pretty much every .net youtube channel focuses around web. All the new features focus around web.
@@edandersen We are stuck in .NET Framework 4.8, WinForms... some content on guidance from moving away, would be helpful but also, I'm aware that each situation is unique.
The main issue is that even desktop development is web development these days. WPF had a lot of layout improvements over winforms, but has since been completely eclipsed by html/css. That the libraries from MS shipped only half-baked didn't help adoption at all. WinUI? Even less baked than WPF. MAUI? Delivered at the same time as the ability to internally serve Blazor pages into a web control, like Electron devs have been doing with nodejs for years. Meanwhile our customers are asking for more cloud integration, more hosted, client-less solutions. The PC has been losing ground to phones and tablets for years now in the hands of the public, and zero-trust setups in Enterprise environments are making local installation increasingly problematic. As far as desktop stuff goes, dives into what it takes to actually get WinUI or MAUI into a usable state for a real application. How many (obvious) value converters do I need to write, and what third party framework libraries making working with them workable? Or did they actually ship something usable out of the box? How does performance compare to the afore-mentioned Blazor-in-a-WinForms-web-control implementation?
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.
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.
Some time ago I started using Go after more than 2 decades with C# and, because it gave me the comparative experience, I completely agree with you (I still use both). Too many features can indeed become a hindrance and I find myself actually more productive while using Go, and especially while maintaining Go code. Concerning breaking changes, Go was released to the public 12 years ago and the current version is still 1.x, which means minimal breaking changes, since initial release for 12 years, absolutely nothing compared to what we have with .Net.
99% apps don't have to worry about the service period, 1 or 3 or however long time that is, it just need rebuild and republish, what's the pain in that? I try to keep up with newest beta version to enjoy the performance boosts between versions.
I agree with you. The most annoying aspect to me is that now when I write by-the-book C# code from two versions ago, Visual Studio is graying the code out and suggesting I "fix" or "simplify" the code, using (in my opinion) these uglier and less readable syntaxes I would rather not use.
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 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
The whole industry is addicted to the new shiny toy. Is it for developers and users that a new product is introduced every year? I don't think so. It seems like a good question for a new person, which version will they start learning from? What about the learning content producers? I think software development is now a fair that moves forward with decisions without deep thought. Every application is loose, full of bugs and seems to have been developed in a hurry. The applications I used on 386 sx 25 hz computers were more responsive and faster than the ones I use now. The whole industry has turned into a clown show.
You cannot make any money without releasing new products. I've been happily using free software like vim and Window Maker for the past 20 years or so. They haven't changed much or at all, they didn't need to change, they are still as great as they were 20 years ago. The difference with Microsoft bs is that the developers who have worked on these fine products have not become millionaires (nor have they ever intended) by sucking out money of their hapless customers/users.
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've been trying to learn C# on and off since the beginning of this year, and I've made almost zero progress precisely because of all that you're describing, especially the versioning convention change. .NET this, ASP that. It's indecipherable.
I started my c# journey by messing about with unity, this was 10 years ago though, then managed to get an mvc job as my first proper software job at the young age of 30
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 think C++'s 3 year major language release cadence is the best frequency (and the additional time means they can ensure better backwards compatible non-breaking changes). The .NET team could do major releases every 2 years if they're feeling impatient, but every year is overkill. It's funny and perhaps a little sad to see a site like Pluralsight update their C# course path to what WAS the latest version only for Microsoft to already be coming out with the next release by the time this happens. Instructors have to be feeling a little like Sisyphus trying to keep up with this ridiculous pace.
I like the evolving language but spot on with the central point of the support cycle length. I stick with .Net Framework 4.8 for my main clients as they need to know there is at least 5 years support going forward without being forced into expensive release cycles.
Yes, you are really forced onto an average of a 2-year upgrade cycles even though technically LTS lasts 3-years. Staying on LTS for the full 3-years does not help the average, for example: .NET 6 (Nov 2021) .NET 9 (Nov 2024, but goes out of support before .NET 11 or 12 are released) Thus: Must upgrade to .NET 10 (Nov 2025), so you are averaging an upgrade every 2-years. You either upgrade annually (which I do), or on a 2-yearly schedule on the LTS. It would be nice if there was an extra 15 months on LTS, so people could decide to skip an LTS version (and have 3-months to do the migration).
14 วันที่ผ่านมา
Hm.. Breaking changes are few and far between. I don't mind the language extension schedule.
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
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.
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.
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.
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!
I find myself not wanting to invest the time to write code in any language when I know the language and libraries are a moving target. At some point we are going to have to develop some languages, libraries, and UI toolkits that are good enough to commit to supporting for 20 years instead of rushing after what is new and shiny every 3. All I want to do now is make console applications because at least that interface isn’t going to leave me high and dry anytime in the next decade.
@@JethroBodine1422 I do appreciate that. I built a windows forms app for someone in .net 1.1 and it’s great it has an upgrade path all the way forward to today. My only lament is that when I need to build apps for Linux that there isn’t anything with that level of api stability.
Well, there are standardized languages, and we also have languages that do have standard libraries very stable so this is not a problem, just choose better tools. In UI there are HTML, CSS and web components very stable. It is those Javascript libraries that live all the time.
Yes, that’s a great point. When we invest time and effort into learning a programming language and its features, it becomes more than just a skill-it’s an emotional and heartfelt commitment. However, the rapid evolution of some languages can make it feel like we’re constantly playing catch-up. This can be discouraging, as it creates a sense that the knowledge we gain today might be obsolete by next year. Such uncertainty can deter us from fully investing ourselves in mastering 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.
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.
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'm a C# desktop app builder, and I constantly need to use P/Invoke to do something interesting. My 2 cents, .NET team needs to expand the BCL coverage to the full Win32 API stack. What is current percentage anyone know? How much does it grow year over year?
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.
As an ameture programmer I often leave a project for a while (using visual studio) only to come back a month or so later and find that I have to rebuild it from scratch because it doesn't open or compile. I'm not sure it's because of my naivety or because of VS upgrades. I wouldn't want to have to do this in a major business project. I want to be able to save the project and continue where I left off. For a business long term stability is vital to save having to reinvent the wheel every year. Personally I think there are to many designers reinventing things. Take the humble tap for instance. For nearly 100 years we had a tap design whick could be repaired with a small washer about the size of a dime. Today every time you go to the hardware store you have to buy a whole new tap because you can't buy parts for the tap you bought two years ago, as the design has been reinvented. As for the proliferation of programming languages. How many new programming languages do we really need?
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.
totally have this problem where I work apps get stuck with so much tech debt because they were written in earlier versions of .net core and quickly became unsupported, impossible to keep up all apps
Long story short: .NET Should have releases every 2 years. Standard support for a version should be 4 years. Long support should be 8 years. End of story.
Why, what is wrong with current schedule? Updating to new version is usually matter of an hour top. There is so little breaking changes between .NET 7 and .NET 8 that update was a breeze.
@@petrmalecik5661beacuse you upgraded from 7 to 8... i encourage you to migrate an enterprise Blazor app from 6 to 8 with all of the runtime changes, they just reinvented runtime for fun
I totally agree with your main point about needing longer LTS versions. I'm also on the same page about Microsoft sometimes changing stuff just to try and attract fans of popular languages, even if it doesn’t always hit the mark. Lately, it feels like they’re adding a bunch of features to appeal to Rust developers, like option and result types, and all the things thy did with nullables. On one hand, it’s annoying that C# seems to jump on every new bandwagon, piling on extra features and duplicating stuff for the same tasks.But on the other hand, I get that not updating the language at all wouldn’t be the way to go either. There are some new features I don’t really see the point of, like being able to write actual method bodies in interfaces since .NET 6. Still, there are other new features I can’t live without now. I’m really looking forward to implicit fields in C# 13-I always hated not being able to have implicit member variables like with auto properties while still managing setters and getters and working with WPF. Plus, the collection expressions in C# 12 are awesome because you can pass collections to methods without having to refactor when the collection type changes. And the performance improvements in the latest versions are insane. Just upgrading can double your LINQ performance without any code changes. Honestly, there’s rarely a new feature I don’t end up liking once I get how it works. I also get that some new features overlap with old ones without fully replacing them, especially since Microsoft has a long history of supporting legacy stuff (remember when they skipped Windows 9? Afaik because they didn’t want to retire code still checking for Windows 95/98 for compatibility). My main concern is that the magnitude of features coupled with the short release cycle leads to oversights from the .NET team. All these features and the quick release cycle might lead to some things slipping through the cracks. For example, I heard the new null check (variable is not null) is faster than the previous (variable != null), and some LINQ methods are way quicker now because they use Span internally, while others still don’t. It’s frustrating because I have to keep learning different ways to do the same thing - not because it is better, but simply because the other option has not been properly updated - with every new .NET version, and it can get pretty tiring. I think if they could double the release cycle and extend LTS support, it would give the .NET team more time to polish new features and give all of us C# developers more time to maintain our apps before jumping to the next LTS version. That would solve a lot of the issues.
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.
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.
.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!
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.
.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.
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
for me problem with new things in c# is that when i write dll for apps it is hard to tell what thing where implemented. for exemple in unity what thing we can use what we can't. In revit api even when it shows it can be used it sometimes don't work as intended. For that reason I most often write basic c# with out fancy things, Im no risking searching for bug that not throw errors.
My career was built on .NET from the first betas in 2001, all the way up to 2017…when I realized I could build all the same things with far less code and effort, in the Node/JavaScript ecosystem. Dotnet went from a rock solid, stable, predictable dev platform to chasing trends. C# is a great language but it changes far too often. The whole platform has become a constantly shifting, hard to follow mess. Startups don’t typically reach for it and being a dotnet dev professionally, today, more often than not means working for stodgy old companies doing outdated, legacy things.
.NET isn't "cool". If it was it would be way more used. Currently working with a old ruby on rails project, something that's common among startups, or used to be. It's complete dogshit.
@@Mazzphysics It definitely used to be! That's the MVC model that inspired so many other projects. PHP is another legacy technology that's still popular, and I personally hate. I get slapped for saying that but I think it's just a terrible language.
@VincentJenks As a soon to be graduate in CS, this really threw me off. I was learning PHP/Laravel and making projects with it, then decided to move to .NET because it looked like it had better prospects in terms of the types of projects / companies it's used in. In short, a better career choice. Now your comments make me rethink my decision...
@@Labadabadubdub Well, I'm just one guy on the internet and this is/was my experience. Every language/stack goes through this process; from the new hotness to legacy. Depending on your interests and desires, you have to continually renew and grow in the direction that best satisfies you, personally and professionally. For me, that was recognizing the onset of legacy status in .NET around 2015 and the rise of the JavaScript universe - particularly in the easy money startup era from 2012-2022. Personally, I wanted more greenfield projects with more exciting companies, using more cutting-edge tech. Many peers stuck with .NET and didn't want to move as quickly. Many people went into Python, especially if you were data engineering-focused. Cloud tech became critical, of course. But here we are, in the midst of a great correction in tech labor, and there will be changes to adjust to yet again. Startup money has dried up and a return to sanity is underway. Think of it this way; you'll never hurt for work if you specialize in C# and .NET, you just may get stuck using older technology in that market, more often than not. TL;DR - always grow and learn if you want to remain relevant, and keep your ear to the ground when it comes to the economic climate.
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'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.
Having worked in the Go ecosystem, much of what you mentioned really resonates with me. Go releases are usually focused on security and runtime improvements, not introducing new syntax, and when it happens, the community has fair warning that a major change to the language is happening. Given how complex C# already is, i think it would benefit MS to glean some tips from Go.
The choice of philosophie between C# and Go are just different.. Go pursuits minimalist and "afraid" of breaking changes. C# introduces as much keywords as it can think of to make the codes as expressive as possible. It is the reason why Go stays with 1.x for more than 10 years.. while C# got new version for every 2 years... I prefer something in the middle balances
Yes but much like Go, .NET runtime never ever tries to break on you. When people talk about breaks they mean surrounding ecosystem which is less stringent with backwards compatibility. The thing is - Go does *not* provide it. Instead, you are at mercy of release cadence of separate dependencies, which, surprise can and do take breaking changes. In reality, if you assume that .NET 6 and newer is the only target worth even talking about, you never had or will have any breaks whatsoever. Updating is just bumping a target version, redeploying and enjoying another +5-35% of performance. I can't believe how clueless .NET community is in its lack of awareness of how bad everyone has it elsewhere, and how good we have it if just by a degree of improvement that .NET went through in the last 5 years.
This is really interesting. I like how Java and Python both have very long support periods so that it is possible to ship an app and barely touch it for years (assuming using mostly standard library). With Rust I find compatibility to be so good that upgrades barely take any effort at all, loving that too
I spend every November - December upgrading packages, but I like to have regular updates if it adds value. The latest .NET 9 has a lot of performance improvements so that is worth it.
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.
"If you do not accept change, be prepared to be stagnated". If the change does not break you but gives you a more concise, intuitive way of programming and improves on development/testing/deployment speed and makes your application run faster, ask your programmers to not be lazy and learn. The learning curve really is negligible, anyway.
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?
The best years of C# and .NET were the WinForms years, even today that's the one desktop framework most used across multiple industries. And that's the kind of spirit we need to bring more innovation to the language and .NET technology going forward.
I've been updating projects since .NET Core 2, and it's always been smooth sailing. As long as you keep up with regular updates, it’s quick-usually less than a day of work. But if you let things fall behind, it can turn into a massive headache (as with any language or framework)
@@MatheusDasuke Just had to drag MediatR and Autofac kicking and screaming up to the latest versions to keep compatibility with .net 8. Had lots of code changes to make, took quite a while.
@@edandersenpersonally I find the "no more support" a good boogieman argument *for* "fast" update schedules like these. It's not like you can't just not upgrade, between docker support and literally going AOT and just baking the runtime in your app in newer NET versions. But it's just as bad of a problem if applications aren't incentized to upgrade, especially not in this age of massive cybercrime. I've worked with systems where Java is *still* stuck at 11 despite Java 23 being a thing, with companies only budging because of the sl4j exploit. The current lifecycle is, for all intents and purposes, fine in an enterprise setting. And for libraries, they can just go use NET Standard as the minimum supported language and stick to it.
Just like these UI library companies create a bunch of temples with best practices the life of developers using these UI libraries becomes easy. Microsoft should also have similar projects maintained where developers can choose from when starting a new project. Current .NET templates have bare minimum functionality readymade
I'm not sure if it was only me, but where ever I worked, and whatever I do, I had less problem with non-LTS version than the LTS ones,... like they are experimenting on them that make them live longer, not because they actually better. specially most issue I had and still have in my current company are with .NET 6 and mostly with EF query parsing. Secondly, you are right, even I an exprienced one in .Net who started with .NET 2, am always curious why something is there, what is that, and I spend lot of time decide which approach to choose than actually doing that... I'm not saying its a bad thing, its a dual edge sward, but still the time for micro-performance management is past, we keep writing code that have issue or problem in structure and substructure but keep saying oh this piece that run once a while or at all, has 0.000001 better performance than other...
Yeah, but there is also another problem of reported issues being closed down, simply because the originator stopped responding to a thread for period of time (for whatever reason). This means that a lot of issues/bugs go on unresolved, which eventually leads to devs to turn to other technologies.
I've heard of people still using .NET Standard and I'm not talking about some small organization I'm talking about a bank. Honestly if you don't want to upgrade you shouldn't otherwise do it and deal with the breaking changes. Security should not be dependent on the application but it needs to exist in other forms too in web apps!
Almost need 3 versions: C# Core (beginners, game dev, embedded systems), C# Enterprise Edition (business logic, desktop app), and C# for Continuous Deployment (web, server API's).
There are a few things i don't understand here. How can you evolve anything with 6 years lts? Companies move to lts, so every 6 years you have 6 years of breaking changes instead of 2. It works for 4.8 because it's static. Who pay for c#? Vs is free, rider is free, omnisharp is free. If you pay, you pay for the cloud, which apply to any language. As for the JWT, JWT is just a format, and used for federation in Oauth2.0. You can get a token from net 7 or 8 out of the box with Identity Endpoints. Or write your logic with SignInManager class anyway. The problem with net is a PR problem, and the only way to improve that is what they are doing by getting closer to node and appeal to younger people. Which they cant to with 6y lts
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! :)
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.
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.
Please consider subscribing if you haven't already 🙏 Hot takes and coding tutorials guaranteed.
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.
they say "dont have to learn it", and then you can't even read code until you learn it.
Microsoft shops: "I want better user experiences for my devs and clients, so I can make more money."
Microsoft: "What the hell is a 'User'... 😮?"
Devs: * still reading the stack trace*
@@anthonylosegoexcept LLMs are complete retards and can barely get a documentation page as pretty and functional as Django's up.
Also, you really don't need AI to do this...
@blo0m1985 skill issue. C# is not bad at all to read. It's the organization of code and learning to not spew LOC past the monitor width that escapes some devs....they know who they are....
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...
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.
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 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?
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 ??
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?
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?
As a beginner I always wondered when and how this new thing came up in C# and its kind of frustating
Thats what I worry about. It appears the team is focussing on language minutiae at the expense of making this a great experience for beginners, i.e. the next generation. Thanks for the comment.
My recommendation if you are a beginner focus on other questions, that's not something you need ( at the beginning) to become a proficient C# developer.
There is a little difference between C# 10 and C# 12 tbh. As compared to C# 7 and C# 8 for example. I think they should be called C# 9.1 and C# 9.3 and the problem wouldn't exist
Yup after some time of not working/learning on C#, I tried scaffolding a Console Application on dotnet 8 and thinking where is the main method?
@@carlosromero-sn9nm well that is just top level statements, it was an easy thing to look it up. But I get what you say.
Java programmers are watching with interest. about half of them work on Java 8, although Java 22 has already been released.
Is something is stopping .NET developers to still use .NET Framework 4.8? ;-)
* It supports Windows 7+
* It's preinstalled with Windows 10
* It has 95% of all needed features
* It's still supported
* It generates small *.exe and *.dll files
So if you "just need .NET" - why not use 4.8?
It doesn't support Mac or Linux tho.
@@igorthelight yeah linux+docker
@@SpookFilthy That would help!
VS2022 can still build .NET framework 4.6.2 .... so you can share a VS12 project with a VS2022 one.
@@igorthelight Some people like me for example still use .NET Framework 4.8. We moved the code to Azure some time ago but at 4.7 version.
And we will migrated it to NET.Core. One of the reasons it for example azure functions v1.x will not be supported after 14th September in 2026. Kinda hard to predict how long it will take to actually do it. Of course users wont be happy as it will mean no new features for let say a month since the team will be ocuppied with this "unproductive change" ;).
As desktop app developer, I get quite frustrated that these days, .Net is synonymous with web development. Pretty much every .net youtube channel focuses around web. All the new features focus around web.
Sorry buddy. Would you like me to cover some Desktop stuff? If so what would be interesting?
@@edandersen We are stuck in .NET Framework 4.8, WinForms... some content on guidance from moving away, would be helpful but also, I'm aware that each situation is unique.
The main issue is that even desktop development is web development these days. WPF had a lot of layout improvements over winforms, but has since been completely eclipsed by html/css. That the libraries from MS shipped only half-baked didn't help adoption at all. WinUI? Even less baked than WPF. MAUI? Delivered at the same time as the ability to internally serve Blazor pages into a web control, like Electron devs have been doing with nodejs for years. Meanwhile our customers are asking for more cloud integration, more hosted, client-less solutions. The PC has been losing ground to phones and tablets for years now in the hands of the public, and zero-trust setups in Enterprise environments are making local installation increasingly problematic.
As far as desktop stuff goes, dives into what it takes to actually get WinUI or MAUI into a usable state for a real application. How many (obvious) value converters do I need to write, and what third party framework libraries making working with them workable? Or did they actually ship something usable out of the box? How does performance compare to the afore-mentioned Blazor-in-a-WinForms-web-control implementation?
Yes@@edandersen
Do desktop with Flutter
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.
@@DE-sf9sr I see it as one overall offering. Both are useless currently without the other.
@@edandersen agree to disagree
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.
Some time ago I started using Go after more than 2 decades with C# and, because it gave me the comparative experience, I completely agree with you (I still use both). Too many features can indeed become a hindrance and I find myself actually more productive while using Go, and especially while maintaining Go code. Concerning breaking changes, Go was released to the public 12 years ago and the current version is still 1.x, which means minimal breaking changes, since initial release for 12 years, absolutely nothing compared to what we have with .Net.
That's great insight. Sometimes less is more. Thanks for the comment!
I love Go
I think you nailed it. Absolutely exhausting trying to stay up to date while doing your actual job which is building and maintaining!!!
nah, just one more way of instantiating lists and we are all good ;-) thanks for the comment!
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?
99% apps don't have to worry about the service period, 1 or 3 or however long time that is, it just need rebuild and republish, what's the pain in that? I try to keep up with newest beta version to enjoy the performance boosts between versions.
I agree with you. The most annoying aspect to me is that now when I write by-the-book C# code from two versions ago, Visual Studio is graying the code out and suggesting I "fix" or "simplify" the code, using (in my opinion) these uglier and less readable syntaxes I would rather not use.
yeah that's really annoying
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 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
The whole industry is addicted to the new shiny toy. Is it for developers and users that a new product is introduced every year? I don't think so. It seems like a good question for a new person, which version will they start learning from? What about the learning content producers? I think software development is now a fair that moves forward with decisions without deep thought. Every application is loose, full of bugs and seems to have been developed in a hurry. The applications I used on 386 sx 25 hz computers were more responsive and faster than the ones I use now. The whole industry has turned into a clown show.
If not it's certainly trending towards a circus at least. Thanks for the comment.
You cannot make any money without releasing new products. I've been happily using free software like vim and Window Maker for the past 20 years or so. They haven't changed much or at all, they didn't need to change, they are still as great as they were 20 years ago. The difference with Microsoft bs is that the developers who have worked on these fine products have not become millionaires (nor have they ever intended) by sucking out money of their hapless customers/users.
I've been .NET developer for 20 years. I love how C# and .NET evolves. Keep it coming fellas!
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've been trying to learn C# on and off since the beginning of this year, and I've made almost zero progress precisely because of all that you're describing, especially the versioning convention change. .NET this, ASP that. It's indecipherable.
I started my c# journey by messing about with unity, this was 10 years ago though, then managed to get an mvc job as my first proper software job at the young age of 30
I don't think the pace of C# updates are too fast, I think they feel too "half backedy". DU's for example, I'm not even sure how they will be able to optimize them without some runtime changes on the generics reification. But other than that I don't think C# is "getting harder for newcommers", you can learn the basics of C# very fast if you just don't take the job of needing to learn .
I dunno if the newcomers are actually saying it's confusing them (which they are) then I believe them. Thanks for the comment 😊
I think C++'s 3 year major language release cadence is the best frequency (and the additional time means they can ensure better backwards compatible non-breaking changes). The .NET team could do major releases every 2 years if they're feeling impatient, but every year is overkill. It's funny and perhaps a little sad to see a site like Pluralsight update their C# course path to what WAS the latest version only for Microsoft to already be coming out with the next release by the time this happens. Instructors have to be feeling a little like Sisyphus trying to keep up with this ridiculous pace.
I'd be happy with 3 years yeah. Thanks for the comment!
Hey I'm a fresh grad, where do you to build career in backend stack of java or c# dotnet
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 LOVE how fast the language and framework are evolving - new features, new syntax, and major performance improvements. Keep em coming!
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).
Hm.. Breaking changes are few and far between. I don't mind the language extension schedule.
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
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.
Been doing C++ native for over 30 years. Using Borland and now embarcadero C++ Builder
Borland C++ Builder! Used it for years... vers 3, 4, 5, 6 .... I loved it.
@@jamesross3939 Also the most recent compiler uses the C++17 standard, they are experimenting with 23. Also its all CLANG so quality is very good.
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.
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!
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!
I find myself not wanting to invest the time to write code in any language when I know the language and libraries are a moving target. At some point we are going to have to develop some languages, libraries, and UI toolkits that are good enough to commit to supporting for 20 years instead of rushing after what is new and shiny every 3. All I want to do now is make console applications because at least that interface isn’t going to leave me high and dry anytime in the next decade.
@@JethroBodine1422 I do appreciate that. I built a windows forms app for someone in .net 1.1 and it’s great it has an upgrade path all the way forward to today. My only lament is that when I need to build apps for Linux that there isn’t anything with that level of api stability.
Hi there, great comment. What would be a good e-commerce stack that will be good going forward? Thanks!
Well, there are standardized languages, and we also have languages that do have standard libraries very stable so this is not a problem, just choose better tools.
In UI there are HTML, CSS and web components very stable. It is those Javascript libraries that live all the time.
Yes, that’s a great point. When we invest time and effort into learning a programming language and its features, it becomes more than just a skill-it’s an emotional and heartfelt commitment. However, the rapid evolution of some languages can make it feel like we’re constantly playing catch-up. This can be discouraging, as it creates a sense that the knowledge we gain today might be obsolete by next year. Such uncertainty can deter us from fully investing ourselves in mastering the language.
You can write your own security into your app you do not need to use Azure
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.
only thing i need is casting from and to derived type without any mappers. if B derived from A i want to cast A to B and B to A
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.
As for Auth Provider, how about OpenidDict ?
I'll take a look, cheers!
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'm a C# desktop app builder, and I constantly need to use P/Invoke to do something interesting. My 2 cents, .NET team needs to expand the BCL coverage to the full Win32 API stack. What is current percentage anyone know? How much does it grow year over year?
that's a great idea!
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!
As an ameture programmer I often leave a project for a while (using visual studio) only to come back a month or so later and find that I have to rebuild it from scratch because it doesn't open or compile.
I'm not sure it's because of my naivety or because of VS upgrades.
I wouldn't want to have to do this in a major business project. I want to be able to save the project and continue where I left off.
For a business long term stability is vital to save having to reinvent the wheel every year.
Personally I think there are to many designers reinventing things.
Take the humble tap for instance. For nearly 100 years we had a tap design whick could be repaired with a small washer about the size of a dime. Today every time you go to the hardware store you have to buy a whole new tap because you can't buy parts for the tap you bought two years ago, as the design has been reinvented.
As for the proliferation of programming languages.
How many new programming languages do we really need?
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.
totally have this problem where I work apps get stuck with so much tech debt because they were written in earlier versions of .net core and quickly became unsupported, impossible to keep up all apps
Long story short: .NET Should have releases every 2 years. Standard support for a version should be 4 years. Long support should be 8 years. End of story.
Sounds good to me.
Why, what is wrong with current schedule? Updating to new version is usually matter of an hour top. There is so little breaking changes between .NET 7 and .NET 8 that update was a breeze.
@@petrmalecik5661beacuse you upgraded from 7 to 8... i encourage you to migrate an enterprise Blazor app from 6 to 8 with all of the runtime changes, they just reinvented runtime for fun
yes!!
This is the only correct answer
In our company we completely skip non lts versions, we can’t spent 2 month out of every year upgrading the systems. It is not sustainable for us.
Yeah I hear that alot.
I totally agree with your main point about needing longer LTS versions. I'm also on the same page about Microsoft sometimes changing stuff just to try and attract fans of popular languages, even if it doesn’t always hit the mark. Lately, it feels like they’re adding a bunch of features to appeal to Rust developers, like option and result types, and all the things thy did with nullables.
On one hand, it’s annoying that C# seems to jump on every new bandwagon, piling on extra features and duplicating stuff for the same tasks.But on the other hand, I get that not updating the language at all wouldn’t be the way to go either. There are some new features I don’t really see the point of, like being able to write actual method bodies in interfaces since .NET 6. Still, there are other new features I can’t live without now. I’m really looking forward to implicit fields in C# 13-I always hated not being able to have implicit member variables like with auto properties while still managing setters and getters and working with WPF. Plus, the collection expressions in C# 12 are awesome because you can pass collections to methods without having to refactor when the collection type changes. And the performance improvements in the latest versions are insane. Just upgrading can double your LINQ performance without any code changes. Honestly, there’s rarely a new feature I don’t end up liking once I get how it works.
I also get that some new features overlap with old ones without fully replacing them, especially since Microsoft has a long history of supporting legacy stuff (remember when they skipped Windows 9? Afaik because they didn’t want to retire code still checking for Windows 95/98 for compatibility). My main concern is that the magnitude of features coupled with the short release cycle leads to oversights from the .NET team. All these features and the quick release cycle might lead to some things slipping through the cracks. For example, I heard the new null check (variable is not null) is faster than the previous (variable != null), and some LINQ methods are way quicker now because they use Span internally, while others still don’t. It’s frustrating because I have to keep learning different ways to do the same thing - not because it is better, but simply because the other option has not been properly updated - with every new .NET version, and it can get pretty tiring.
I think if they could double the release cycle and extend LTS support, it would give the .NET team more time to polish new features and give all of us C# developers more time to maintain our apps before jumping to the next LTS version. That would solve a lot of the issues.
Fantastic comment, thanks for taking the time to write it out.
I am on the fence having body in abstract classes but writing actual method bodies in interfaces is so stupid on so many levels...
@@fullmetalbiatch Shhh... that was someone's annual performance review KPI
Have you tried OpenIddict yet?
Nope, might do though
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.
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.
.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!
Giving how the Enterprise system works, that's not a bad idea.
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.
.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.
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!
for me problem with new things in c# is that when i write dll for apps it is hard to tell what thing where implemented. for exemple in unity what thing we can use what we can't.
In revit api even when it shows it can be used it sometimes don't work as intended.
For that reason I most often write basic c# with out fancy things, Im no risking searching for bug that not throw errors.
Yep, some C# doesn't work in all places. It's kind of forked.
My career was built on .NET from the first betas in 2001, all the way up to 2017…when I realized I could build all the same things with far less code and effort, in the Node/JavaScript ecosystem. Dotnet went from a rock solid, stable, predictable dev platform to chasing trends. C# is a great language but it changes far too often. The whole platform has become a constantly shifting, hard to follow mess. Startups don’t typically reach for it and being a dotnet dev professionally, today, more often than not means working for stodgy old companies doing outdated, legacy things.
This 💯
.NET isn't "cool". If it was it would be way more used.
Currently working with a old ruby on rails project, something that's common among startups, or used to be. It's complete dogshit.
@@Mazzphysics It definitely used to be! That's the MVC model that inspired so many other projects. PHP is another legacy technology that's still popular, and I personally hate. I get slapped for saying that but I think it's just a terrible language.
@VincentJenks As a soon to be graduate in CS, this really threw me off. I was learning PHP/Laravel and making projects with it, then decided to move to .NET because it looked like it had better prospects in terms of the types of projects / companies it's used in. In short, a better career choice. Now your comments make me rethink my decision...
@@Labadabadubdub Well, I'm just one guy on the internet and this is/was my experience. Every language/stack goes through this process; from the new hotness to legacy. Depending on your interests and desires, you have to continually renew and grow in the direction that best satisfies you, personally and professionally. For me, that was recognizing the onset of legacy status in .NET around 2015 and the rise of the JavaScript universe - particularly in the easy money startup era from 2012-2022. Personally, I wanted more greenfield projects with more exciting companies, using more cutting-edge tech. Many peers stuck with .NET and didn't want to move as quickly. Many people went into Python, especially if you were data engineering-focused. Cloud tech became critical, of course. But here we are, in the midst of a great correction in tech labor, and there will be changes to adjust to yet again. Startup money has dried up and a return to sanity is underway. Think of it this way; you'll never hurt for work if you specialize in C# and .NET, you just may get stuck using older technology in that market, more often than not. TL;DR - always grow and learn if you want to remain relevant, and keep your ear to the ground when it comes to the economic climate.
My thoughts? Rapid framework implementation for a language that's not really built for the web and is never given time to mature.
thanks for the comment!
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.
So, you're saying that C# has become the new equivalent of the next JS flavor of the year?
I'm fed up of every project I have to open using different C# for the same thing, yeah. even worse now it's forked with nullable and implicit usings
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.
It seems like C# is repeating the same issues as .Net Framework. Are we going to get a C# Targeted (since Core could be confused with .Net Core)?
It's basically already forked. There are Nullable and Implicit Usings versions of code out there
Having worked in the Go ecosystem, much of what you mentioned really resonates with me. Go releases are usually focused on security and runtime improvements, not introducing new syntax, and when it happens, the community has fair warning that a major change to the language is happening. Given how complex C# already is, i think it would benefit MS to glean some tips from Go.
The choice of philosophie between C# and Go are just different.. Go pursuits minimalist and "afraid" of breaking changes. C# introduces as much keywords as it can think of to make the codes as expressive as possible. It is the reason why Go stays with 1.x for more than 10 years.. while C# got new version for every 2 years... I prefer something in the middle balances
Yes but much like Go, .NET runtime never ever tries to break on you. When people talk about breaks they mean surrounding ecosystem which is less stringent with backwards compatibility. The thing is - Go does *not* provide it. Instead, you are at mercy of release cadence of separate dependencies, which, surprise can and do take breaking changes. In reality, if you assume that .NET 6 and newer is the only target worth even talking about, you never had or will have any breaks whatsoever. Updating is just bumping a target version, redeploying and enjoying another +5-35% of performance. I can't believe how clueless .NET community is in its lack of awareness of how bad everyone has it elsewhere, and how good we have it if just by a degree of improvement that .NET went through in the last 5 years.
@@neonmidnight6264 you make it sound easy, but there is also a matter of breaking changes in .NET releases
This is really interesting. I like how Java and Python both have very long support periods so that it is possible to ship an app and barely touch it for years (assuming using mostly standard library). With Rust I find compatibility to be so good that upgrades barely take any effort at all, loving that too
'.NET AND C# ARE IN TROUBLE. HERE IS WHAT I'D DO!' - even this title arouses severe anxiety and depression.
Any suggestions for a better title?
@edandersen DOTNET is in a ickle pickle. BUT THERE'S A SOLUTION!
@@zebcode pretty good tbh
@edandersen yeah easy for me to critique something someone else has already made isn't it?
Not sure I follow
I spend every November - December upgrading packages, but I like to have regular updates if it adds value. The latest .NET 9 has a lot of performance improvements so that is worth it.
Yeah the free performance each year is great
That's a very necessary conversation to be had
I was really looking for some major point and all I got O_o weak arguments. Really really weak
Other TH-cam channels are available, Nick Chapsas is better than the weaksauce you'll find here. Go watch Nick 👍
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.
"If you do not accept change, be prepared to be stagnated".
If the change does not break you but gives you a more concise, intuitive way of programming and improves on development/testing/deployment speed and makes your application run faster, ask your programmers to not be lazy and learn. The learning curve really is negligible, anyway.
Idk, sounds like a skill issue.
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
The best years of C# and .NET were the WinForms years, even today that's the one desktop framework most used across multiple industries. And that's the kind of spirit we need to bring more innovation to the language and .NET technology going forward.
IMO discriminated unions is a big thing (not yet in the language) only thing we should have instead of the nonsense addings
Yeah looking forward to them
I've been updating projects since .NET Core 2, and it's always been smooth sailing. As long as you keep up with regular updates, it’s quick-usually less than a day of work. But if you let things fall behind, it can turn into a massive headache (as with any language or framework)
Its easy enough as long as your third party dependencies are also still actively being updated.
@edandersen, can you give a few examples of third parties that you have had issues?
@@MatheusDasuke Just had to drag MediatR and Autofac kicking and screaming up to the latest versions to keep compatibility with .net 8. Had lots of code changes to make, took quite a while.
Bro. If you want to use .NET 6 for the next ten years, just do it. No one is stopping you.
Apart from it won't be supported past next year yeah
@@edandersenpersonally I find the "no more support" a good boogieman argument *for* "fast" update schedules like these. It's not like you can't just not upgrade, between docker support and literally going AOT and just baking the runtime in your app in newer NET versions. But it's just as bad of a problem if applications aren't incentized to upgrade, especially not in this age of massive cybercrime. I've worked with systems where Java is *still* stuck at 11 despite Java 23 being a thing, with companies only budging because of the sl4j exploit.
The current lifecycle is, for all intents and purposes, fine in an enterprise setting. And for libraries, they can just go use NET Standard as the minimum supported language and stick to it.
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.
I do not mind updated framework/API stuff. But the language changes need to slow waaaaaaaay down. Pause that part for a couple releases.
The new syntaxes and frameworks align with the "let there be" approach, I am good with that!
They can stop once maui/blazor and entra external id is fully mature
Just like these UI library companies create a bunch of temples with best practices the life of developers using these UI libraries becomes easy.
Microsoft should also have similar projects maintained where developers can choose from when starting a new project.
Current .NET templates have bare minimum functionality readymade
I'd like to know how much it has slowed down over the years? Compile time and runtime? Because I remember with each new VS it was slower.
It's way faster than it used to be and gets faster every year. One of the good bits. Thanks for the comment!
I'm not sure if it was only me, but where ever I worked, and whatever I do, I had less problem with non-LTS version than the LTS ones,... like they are experimenting on them that make them live longer, not because they actually better. specially most issue I had and still have in my current company are with .NET 6 and mostly with EF query parsing.
Secondly, you are right, even I an exprienced one in .Net who started with .NET 2, am always curious why something is there, what is that, and I spend lot of time decide which approach to choose than actually doing that... I'm not saying its a bad thing, its a dual edge sward, but still the time for micro-performance management is past, we keep writing code that have issue or problem in structure and substructure but keep saying oh this piece that run once a while or at all, has 0.000001 better performance than other...
amazing comment, thanks!
Yeah, but there is also another problem of reported issues being closed down, simply because the originator stopped responding to a thread for period of time (for whatever reason). This means that a lot of issues/bugs go on unresolved, which eventually leads to devs to turn to other technologies.
That is a very good point.
I've heard of people still using .NET Standard and I'm not talking about some small organization I'm talking about a bank. Honestly if you don't want to upgrade you shouldn't otherwise do it and deal with the breaking changes. Security should not be dependent on the application but it needs to exist in other forms too in web apps!
.NET Standard was so helpful for migrations... thanks for the comment!
That post applies for the Angular team as well
Almost need 3 versions: C# Core (beginners, game dev, embedded systems), C# Enterprise Edition (business logic, desktop app), and C# for Continuous Deployment (web, server API's).
You are wrong. Working on jason api secured with jwt right now. Nothing external or commercial involved.
ok
I love C# and Dotnet and i switch to golang now. I love the one binary deployment and the better memory usage of golang.
There are a few things i don't understand here. How can you evolve anything with 6 years lts? Companies move to lts, so every 6 years you have 6 years of breaking changes instead of 2. It works for 4.8 because it's static.
Who pay for c#? Vs is free, rider is free, omnisharp is free. If you pay, you pay for the cloud, which apply to any language.
As for the JWT, JWT is just a format, and used for federation in Oauth2.0. You can get a token from net 7 or 8 out of the box with Identity Endpoints. Or write your logic with SignInManager class anyway.
The problem with net is a PR problem, and the only way to improve that is what they are doing by getting closer to node and appeal to younger people. Which they cant to with 6y lts
every time they have a PR opportunity, like the masterful launch of .NET Core, they tank it by doing things like renaming it back to ".NET".
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.
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.
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
It is difficult to keep up, and I also have experienced trying to upgrade a project over multiple major versions which is also challenging. IMHO, Node has the same problem with major versions and breaking changes. It is even worse with all of the packages that you end up having g to wait for them to fix or even if they are still being maintained. I am happy they cut support earlier so we don’t have as much legacy code running on “supported versions”. It also frees up the teams from maintaining more older versions.
I'm new for the .NET C#. I'm used to breaking neck changes that was in Angular, Next.js, Django. I'm fine with this rate of new changes.
That's great! Welcome to the ecosystem.