Why Developers Already Hate .NET 9
ฝัง
- เผยแพร่เมื่อ 21 ก.พ. 2024
- Use code MODULAR20 and get 20% off the brand new "Deep Dive into Modular Monoliths" course on Dometrain: dometrain.com/course/deep-div...
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video, I will address the criticism of The Vision for .NET 9 blog that was posted by Microsoft a few days ago.
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet
![[4K] BABYMONSTER(베이비몬스터) “FOREVER” Band LIVE Concert “영원히” 베몬만을 사랑하게 되…💗 [it’s KPOP LIVE 잇츠라이브]](http://i.ytimg.com/vi/TQfC0xdpiw4/mqdefault.jpg)
If C# developers unite, and if Microsoft laughs at them, we'll have a discriminated union.
I really, really hope that will never happen. It defies the purpose of static typed language, just as keyed services defy the purpose of DI
@@Nworthholf unless if keyed services are based on dynamically loaded modules, where the module may expect specific keys
Java already has it so... maybe they can do it... though not quite in the same fashion i imagine in dotnet
I wish some of the arrays, imaging, and data manipulation from python would be included.
I feel like the people here in the comments missed your pun
Year 2034, .NET 19 comes out. But we will still maintain vertically scaled .Net Framework 4.7.1 solutions.
Actually, I should say that most of Azure income is by vertically scaled poop code up to Premium levels. I have worked on a solution with less than 20k users overall, and our team solved performance issues just... by switching to premium 3 tier ...
No one in the team has heard of async code. No one has heard of caching and data reusability. No one is updating any package unless it shows up in owasp report.
And we are a big company with many projects, all in azure.
Just imagine how many other companies do the same.
Lol 😂 I still maintain .Net FW 4.5
Even I am with 4.5
God damn man im tired of that shit
"F# is a language that exists" 😅
hopefully it will bring more attention in the future, it is better than scala in FP terms imo
too sad microsoft doesn't give it enough love
Does it really?
gold 😆
Well... we have DUs ;-) Looooooooong ago
I heard a talk recently about F# Myths, and the guy and his team actually adopted F# for production code (for some microservices IIRC), and were happy about it.
3 years is laughably short for an LTS. Almost nobody switches to a new LTS within the first year of release, making this effectively a 2 year "long" term support. This time frame needs to be increased to 5 years at a minimum. We're not talking about JavaScript front ends that change with the seasons but enterprise back-end code that will likely last 10 to 15 years, if not longer.
I was on .net framework 4.8, blinked, and now we're on .net 9
and yet your .net framework is supported as long as windows exists and only .net 6+ is supported (for now). :)
Blink? Or a coma?
That doesn't even tell the full story. They went back to v1 w/ Core.
.NET Core was 2016. Sleeping Beauty didn't blink for that long.
Yep, we've still got a lot of FW4 products to upgrade.
Please add all links you visited in the video to the description so it's easily accessible to us as well. Thank you.
Dude. When posting a video like this, essentially just breaking down an article, please link the article in the description.
3 seconds to google it.
@@swordblaster2596 Shouldn't have to google it!
@@swordblaster2596still not wrong tho
then you wouldn't be forced to watch the video though
What I really want is "readonly required record struct" and for everything to support these as DTOs everywhere. The perf and memory improvements for APIs and SignalR, GRPC etc. would be significant. And by using required, that says "every property must have a value" which eliminates an entire class of coding issues of accidental nulls, default values being implied, etc.
Sadly, SignalR and MassTransit to name 2 don't support structs.
And maybe one day discriminated unions 😢
Do you realize that using structs are DTO means that you'll have to copy the struct everytime you pass it? and passing it by ref will not be any different than just using a class. So in terms of performance and memory improvements, you won't really gain anything for using structs over classes. Specially for DTOs which can be really big.
@@JustNrik you’re only copying if you’re mutating.
And it works on the stack which is easier to GC and you have not overhead versus the class as the struct is only the sum of the contents.
I’ve tested with json doing this by hand with minimal APIs and it’s a 2-3% increase in performance and over time it saves significant GC cycles.
I am always interested how and where people acquire knowledge about the performance of specific data structures, approaches, and related topics. Could you recommend some books that can help me become familiar with such subjects?
@@konstantinkurtev3396 the best way to learn about this topic is to learn that books won't help you, and the only source of knowledge is your own experimentation following guidelines from online resources at Microsoft's doc pages
8:45-8:51 using olympics as a time measure reminding us that Nick is greek after all
He's Greek? I always thought he was German. Well, except at first when I thought he was an Arab but somehow also white. I'm not good with accents.
@@EdKolis i thought he was just american lol
I don't mind the promos in the videos and they historically haven't really been much of a problem. But I have to say, lately it's gotten a bit absurd. Over a minute of ads, and in some videos they're even also promoted by other companies in addition to the self promo. Is it possible to tone it down somewhat?
Get the sponsorblock extension for your browser.
@@__Tweek I have no idea how it works, how does it know what content is sponsored? Very cool
@@Efemyay I think people mark sections of the video that are sponsored and that's how it knows
Year 2030, still waiting for Blazor WASM multi-threading... (scheduled initially for .NET 8)
No rush, waiting line is long. I am still waiting for a proper hotreload.
IMHO Blazor is a really bad architecture for 90% of the web challenges. Any client side logic with server side rendering is trying to solve the wrong thing in the wrong place. Rendering is easy on the client side and hard on the server side. Logic is hard on the client side and easy on the server side. Blazor makes the worst possible decision, run the logic on the client side with WASM that sends the state to the server to render the html.
Sure, you might say you don't have to do this and just render WASM on the client side, but then you need to send your entire DotNet Runtime to the client side, bloating the entire thing.
Don't get me wrong, I would love for nothing more than to be able to program web in something different than Javascript and building through Node. WASM has great potential.
But as it is, its just another Silverlight waiting to happen.
@@rodrigoserafim8834 why would you send the entire runtime to the client? it just needs to render the UI based on data from the server. in my projects I shared a Dto class library with the clent and the client talks to a web api on the server. It's quite nice to use c# on the client side. works great so far. most of the client logic is based on communicating with the api. Your main logic should always stay on the server for security
If you are making a website versus a webapp, then i wouldn't use blazor, because it loads way too slow and you get into more the issues you describe where you might want to render on the server and send that to the client.
@@rodrigoserafim8834 Have you heard of Blazor United in .NET 8? Now you can create an app that starts with server-side, downloads the runtime in the background and then switches to client side when it's downloaded. Or you can configure it however else you want. If none of them work for you, then have fun with JS.
I have mixed projects with C# projects referencing domain models and functions written in F# and it works just fine, however there are days where I feel DUs are main reason those F# projects exists, on other days I feel like F# modeling is really superior.
Overall I wouldn't mind having an easy way to define DUs in C# as they are now then you look up what F# code produces but that is another whole topic, as most people don't know how much working with both C# and F# in same solution improved over last 3-4 years.
Maybe time to revisit F#? Ran into bunch of weird things at .Net 6 mostly with EF core that were just killing my spirit :(
I love F# other than lack of "break" and "continue" for loops. You can't test recursive functions very well and sometimes iteration is the best/more practical way to handle algorithms. Please, someone prove me wrong and I will pick up F# again.
I guess the only thing I really want is the new extensions feature so I can have nice property extensions
Kotlin actually has these! Also extensions that don't need to be defined in a static class. It's awesome, you can just put them in whatever scope you want. Why can't C# do the same? Did Jetbrains patent this stuff? 😂
Seems like a memo was received: “write something about AI”
MAUI and Blazor dropped to the backlog bottom is frankly a slap. We switched from typescript/vue2/3 to Blazor and never looked back. Improve the diamonds you have already
What about the Blazor?
What is roles extensions?
Microsoft thought they were being clever releasing half baked MAUI with dotnet 6. Its literally frustrated the heck out of anyone wanting to adopt it in last couple of years. Not to forget they launched it twice (once with dotnet 6, and then 8). So these vision articles mean nothing to be honest. MSFT needs to focus on delivering something consumers find useful, rather than spending dev time in making marketing videos for a technology thats difficult to adapt specially when its not a monopoly.
Current Microsoft is unable to finish any of their projects, as they don't commit to any of their products, Windows itself is half baked nowadays.
"And then, F# is a language that exists"
Very underrated language. Even in a non-production sense it’s good for utilities.
Two killer features are Type Providers and Units of Measure if you’re doing numerical computing.
IMO, thanks to discriminated unions, units of measure and computation expressions, it's lightyears ahead of C# for decent domain modelling.
I *want* to like F#, but its syntax is so off-putting it's hard. I get that the syntax came from OCaml, but I'm not a fan of it.
@@colejohnson66 Easy enough to get used to and more concise than C-syntax languages.
I understand the pervasiveness of Python for AI, but I have been writing using large language models using C# just fine. 👽👍
A lot of the pioneering was done in python because that was what the academics are used to, but the python itself is not the AI. The models are language agnostic. If my entire application is C# then I'm going to need the reliability, type safety and speed of C# for my local AI work loads.
@@johndenver8907But the AI ecosystem is Python, so you have to deal with it. Soon you will get the strongly typed Mojo. But in the meantime if you want to be in the .NET space then go with F# which has a mature data science story with the flexibility of Python.
What makes discriminated unions so hard to implement on C#?
I though they will just be syntax sugar for "sealed abstract class" and generate each class on the union or maybe some magic with structs and an enum to identify the union tag
Same question I had in mind. Can someone give us a clue please? I remember Nick making a video talking about them about a year ago, and they looked really cool.
The LDT is struggling to figure out what they want to achieve with DUs. Implementing them in any way is very easy by itself, let alone for the devs behind it. What we really care about is whether they will be blazing fast, or if we will sacrifice too much performance. Adding DUs is a commitment, so it has to be a feature that is prepared to stand for a long time in the language. Meanwhile all these other features and expansions are being given time, in other working groups. So it's primarily a matter of longevity and careful planning.
We can already do DU using StructLayout and LayouKind.Explicit. There's just no language support.
@k72 Only with value types though, you can't have an explicitly layouted struct with an int, float, and a string (or any other reference type) where they overlap for instance.
@@_profan you can, but since strong is a reference type you have to be careful about how you treat the value. Same with arrays... although it's useful if you want to do quick and dirty value type conversion to/from byte arrays. Nasty, but it works.
1. May I know, in future Angular and databases can be a part of dometrain?
2. How can someone, who is new to .net and without being overwhelmed and learn all the courses in a practical sense with building side projects?
It's definitely a communication issue that the dotnet stuff is all managed by slightly different teams, but they're all expected to release features in November for the latest dotnet version. My opinion is that they should move to a cadence of releasing things as they're ready. EF, STJ, and MAUI seem like they could benefit from not being tied so much to the dotnet release cycle.
It's also a little confusing to see a library that was updated to v7 for dotnet 7 but still works with dotnet 6.
Static variables at the method level would be wonderful and painless to implement.
I'm am curious why this would be necessary. you can implement static variables in the same class. if your passing a non static variable as a parameter to a static function I understand the frustration, but I think you need to rethink your design. too many static variables == no garbage collection and memory problems/crashes down the road. IMP... but I am junior dev so I may be wrong
I toyed with the idea of learning XAML last week (in Avalonia UI which uses WPF and Google's Skia under the hood) after frustrations with MAUI and Microsoft's lack of commitment to really fixing the issues with it. Then I thought based on research and general user experience, WPF and XAML can't be the future, but neither can MAUI unless Microsoft does something about it.
I kinda wish Microsoft would purchase Avalonia UI and then not make the mistakes that they made with Xamarin, namely not listening to the users that are enthusiastic and use the framework.
I found using abstract classes with private constructors useful, like using discriminate unions.
This is very similar to sealed classes in cotlin.
What would I like to see are interfaces that are "internaly extensible"
Which alow user code to depend on interfaces but not to implement them
The fact that people are mad about their platforms actually receiving regular updates and QoL changes in these comments is fascinating to me. I'm personally glad I don't work with a language like C where you have to wait ten years for a committee to approve every change (and then another five years for some compilers to support it, maybe, potentially). If you dislike a new feature in .NET, consider not using it. Microsoft's backwards compatibility promises exist for you.
It's fatigue. It's not a matter of "not using" features. You have to learn and know all of them (and I mean all of them) if you work on a dev team, in case they decide to use them. When you're 20+ years into your career, the breakneck release schedule becomes more of a burden than a bonus. It can almost be seen as technical debt for all .NET developers that keeps getting piled on. You can't just ignore it. In fact, staying up to date almost becomes a full-time job in and of itself.
And then they keep changing how the "startup" works with a million different ways to do application builders, services, etc. I'm still to see how a console app is "supposed" to look these days with DI, etc as the documentation is sketchy.
Don't worry kid, one day you'll be a senior developer and will finally understand why C is still around despite not having an update every few weeks.
@@gbjbaanb I also understand why the industry is desperate to get away from it, and inventing 'C killer' languages roughly every year to do just that.
"If the focus on AI brings in some Python developers, let us all hope they can actually code"
XD XD XD
His Digs at F#, we’re never getting tired of it 😂
I still have many packages .preview-8 and they already moving to 9 ??? There are 314 issues open now - could you please fix everything before moving forward ? I don't need more new features - I need stability and performance !
Lovely sense lf homour man. Keep it coming. Keep us entertained while updated on these daf industrial communications.
Just switch to F# if you want DUs
I always thought one major release per year was too much. Why not one major release every two years, and then an update in the in-between years.
That's pretty much what they do, that is why 1 of the releases is long term support, and the other is not. So 6, 8, 10 etc are the major releases (3 years support), and 5, 7 and 9 are the 'minor' releases (18 month support). They don't leave major features till major releases however, so that is why from another point of view there is no real difference between the minor and major releases.
@@SamJudson In .NET they're usually doing their own thing but in C# what they usually do is release a major feature in (a C# version released along) an STS version and then improve and polish it for the following LTS version.
They think it's another product like Windows
Because every major language has a faster cadence. It makes no sense to wait years for a feature. Java and Go do it every 6 months, Rust every six weeks!
Look at where Java and .NET Framework was before a faster release cycle… dying. No one wants another “java 8”
And seriously about AI: I actually WANT to be able to do it in DotNet and to be able to use as little different programming languages as possible. In terms of language and environment, I prefer DotNet (C#) over Python. So let it happen.
Working with MAUI daily now. MAUI is amazing. It has bugs though, like hot reload just stops working on Android once in a while for no reason. Usually fixed when I reboot. No other indication of what's going on. But usually I will just switch to using the Windows side of things for stuff I would need Hot Reload for anyhow. That happens fast and then all the code shared between IOS, Windows, Android. Then we have a WPF and Linux version setup in separate projects while still sharing all the major code. Performance of MAUI has been exactly the same as the java version on android. Business App though.
Hello, "Performance of MAUI has been exactly the same as the java version on android" - meaning it is slow? Please give more details on issues with MAUI. Thanks
Sorry I mean a Java version of the app. The UI looks much different, but then I'm talking about controls and responsiveness of clicks.@@queenstownswords
I was dealing with machine learning in python. it was a terrible experience, because of the community and library developers, it is not customary for them to make a convenient API and write adequate code. It’s better to write more code in .net than to Google 1 line of python code for 2 hours.
I think we are starting to experience how the new stuff, that would be useful. clash with the old and would confuse people. The platform is very mature. And Microsoft's policy is not to break stuff, because then their customers get angry. And they are usually don't the ones who want to deal with change. Whereas the people of the community would embrace that change. So it is a battle.
I have a list of things that I now wished that C# and .NET had .For instance discriminated unions for application Errors, instead of Exceptions.
I also would move all generic collections to the System.Collections namespace, as .Generic is quite redundant. Even scrap the IFoo interface naming convention.
Nullability should be a runtime feature. And you should even scrap the idea that the full runtime would always be there.
Those would require big changes to the runtime and affect billions of lines of code.
Not sure I understand what you mean by moving out generic collections? Do you mean to another namespace, or remove them entirely? Generics are essential for collections and I use them all the time, it would be absurd to get rid of them.
As for nullability, I am confused about this as well. You can enable nullability since C# 8, and enforce nullable code as a compiler error by modifying your project file (although you can still use the “!” operator to bypass it).
@@11clocky I meant move the classes from the the .Generic namespace to Collections namespace. I know that it was because of compatibility when generics was introduced.
Isn't .NET technically open source now? I wonder why no one has forked it yet.
I'm ambivalent about Discriminated Unions in C#. I love using them in functional or multi-paradigm languages like F# and typescript, but I can achieve the same thing using subclasses in C# (the class's type is essentially already a tag). Especially in combination with C#'s pattern matching which has really advanced the language IMHO.
They surely could do DU like in Java, Scala, Kotlin, or even their own F#.
MS needs to declare its ongoing support for MAUI. The lack of MAUI specific documentation for .net 9 is concerning.
They need to buy Avalonia and make it first party.
They are probably already working on its replacement, don'tcha know?
I rather wish they just dropped it instead of pretending it's viable
Discriminated unions is the one thing I want. I am predominantly C#, but I go to F# all the time to play with that. It's such a great way to tackle so many things.
I used MAUI for about a year, we started a project with native with XAML, then moved to MAUI Blazor and then eventually ditched MAUI and moved to Angular. Blazor Components are awesome but are still sorely lacking. XAML is horrible, you want to do conditional rendering? Haha, jokes on you... Would love to see more development on Blazor as a whole, not just a way to write SPA type web applications but as a replacement to XAML for MAUI and WPF etc.
I love F# other than lack of "break" and "continue" for loops. You can't test recursive functions very well and sometimes iteration is the best/more practical way to handle algorithms. Please, someone prove me wrong and I will pick up F# again.
I think Native AOT will be pushed in a way that gets easier access to python and vice versa. So, we can benefit from the AI capabilities implemented in python/C. Like rust and Python. What do you think about it?
I don't understand what vision do people want for DU? Since we already have type/pattern matching, you can use that instead to accomplish the same thing. Maybe you can make a video explaining what you think DU should look like?
Plus it will never have the elegance of a DU in F#, no matter how hard they try.
For me it's mostly about far better error handling. C# still has a system of throwing exceptions and try catch, which are very problematic, because they form a way of error handling which is not well encoded in the type system, based on method contract it is totally unclear if a method possibly throws anything. DUs make it possible to handle that issue.
But more generally speaking it is about clear ways of being able to know and handle which variants of a type are possible. The current C# pattern matching based on just OOP inheritance allows for infinite possible values, because an interface or class can have unlimited derived types.
So pattern matching is very frequently not exhaustive. Unless being done on an enum.
But enums cannot contain any other direct values. If they did, then you exactly had what we called a DU. And this is exactly Rust has for example. Enums as DUs.
I guess people wanted DUs to be able to use the same error handling as Rust.. but come on! if your function return error as value and sometime throw some exception, then it will become a mess! consumers have to deal with both errors as values and exception handling..
@@duongphuhiep an easy solution is for all dotnet devs to agree to return exceptions as return values in a tuple. If we all do it at the same time then problem solved. Let’s go. Staring right…..now 😂
Good im still using .net 6 :D
I would love to see linux support for MAUI, make it truly cross platform
i still use .net 2.0 :-) prefire QT on Linux
Discriminated Unions is the only 'killer feature' I would look forward to in C# at this point.
Would be great to plug the podcast with Mads Torgersen talking about DU's. Care to add a link?
We need DU for stability on models. please Microsoft, do it!!
you understand why some of us are dumping MS for Elixir
NativeAot is an interesting experiment, but I also consider it too niche and limited in principle. You remove a lot of what makes .NET powerful by ditching the JIT.
All time JIT does is what nativeAot does, but worse. The theory is what Jit *could* do is just that, theory. AOT can do a lot more optimisations than you would ever get in a JIT.
C# is just realising all the things it should have had from the start, but were ignored because they weren't cool enough, are good. Whats old is new again.
@@gbjbaanb Performance was never the reason ‒ you've had tools like ngen for decades; you can even pick methods for AOT in code by calling PrepareMethod... You don't get anything by removing JIT from a system where both JIT and AOT is already possible.
You don't pick NativeAOT for performance; you pick it because you are working in a constrained environment where having the CLR is a burden or outright impossible, such as native plugins/libraries or similar. The "AOT" part in the name is a limitation, not a selling point ‒ by removing the JIT, you lose the possibility to run *any* code that the static analysis skipped in a performant manner, having to interpret at best or breaking it at worst.
You don't get anything in terms of power by downgrading C# to C++. You can't accept .NET assemblies, your reflection is limited, you can't interact with dynamic assemblies, and your generics effectively turn into templates since you can only use them statically. That is not something that may improve over time, that is *by design*.
.NET 8 needs some fixes. We are seeing increased memory usage and even OOM in some of our services which were working fine on .NET 7. May be a leak in unmanaged memory as memory dumps don't show anything.
"and F#is a language that... exist!" you kill me on this one XD
It seems like everyone wants discriminated unions. And if it's not quite possible to do them like in F#, I would love for a way to use a DU like feature for type constraints. INumber is great and all, but being able to say where T : float | int |MyClass to contrain the incoming data.
Also Microsoft, should fix up things that don't make sense anymore due to new features. E.g. you cannot cast a Delegate variable to a more specific delegate type because you get a compile error BUT you can do so if you define the same delegate as a type alias?!?
5:40 "And F# is a language that exists." lol
MAUI UI is not really cross-platform, still lacking Linux support, and it does not look like it is coming soon at any time. You might take a look at Avalonia UI, which is sort of evolution of WPF into an open-source and more (than MAUI) cross-platform that works on Win, Mac, Linux, Mobile. So, I do not see why you say (7:15) that XAML is "kill it" since MAUI is not XAML and vice versa.
You said you did not use XAML in MAUI, and the only thing I can assume is that you created the UI using C# MAUI classes. That is possible to do obviously, but my question is why? I mean, we can write code in a notepad and use the command line to compile and run the code, but there is a reason why we agree to pay money for tools like Rider. Maybe the implementation of XAML editor sucks big time in MAUI, (I have no experience with that). But if the UI XAML IDE sucks with MAUI, it is not the fault of XAML but MAUI Editor. To compare, look at how Avalonia/XAML works with Rider, for instance. Kill it? Really?
I prefer always Flutter over Avalonia. Avalonia miss a lot of features that is shipped with MAUI, like routing and navigation. At least Flutter and MAUI has a big company behind.
Just to make sure, the discussion is about C# and XAML (as in Avalonia and MAUI) and you are bringing Dart and Flutter? I don't think it is fair pears to pears comparison.
As for the big companies, I am not sure what you mean by that. For example, Silverlight and later UWP had a big company behind them.
@@tridy7893 yeah, Microsoft and Google abandon project with lower market, like any intelligent business.
I loved NET Maui, but lack of Linux support from Microsoft just make me migrate to another language.
We tryed to use Avalonia a lot, but its just familiar for WinUI/WPF developers. Missing routing funcionality, its not easy to just show a dialog from anywhere.
Yeah, i mentioned Flutter because its a good alternative to Avalonia.
What about Uno? That is truly cross-platform.
"F# is a language that exists" Nick, they're our sisters, mate. We're all in the same family 😋
"getting a new feature every... Olympics!... " 😂😂
It's a shame that you can emulate DU with sealed classes in Java (in Java!!!) and compiler will check it in switch cases etc. But you can't do similar in the C# language.
Microsoft killed VS for Mac?
Yes. Again.
You said discriminated unions clash with things already in C#. That's the first time I've heard this. Would you elaborate?
XAML is fine. MAUI flavor was a mistake. Microsoft bought the wrong thing to get to the market quickly and just poisoned itself forever.
4:10 it's nothing like a monopoly as that would be where a single supplier assumes a dominant position. Anaconda groups compatible libraries from many suppliers, they are vast in number and use python bindings written in c or c++ so they are performant too.
"understatement of British Proportions" that was direct, and it hurt because its true.
Roles/Extensions is hawt.
What is it?
Yet another attempt at making us forget that we still have no mixins nor multiple inheritance
"F# is a language that exists" lol!
3 years == “Long Term Support” 🤦🏼♂️
In IT that's like eternity.
@@krccmsitp2884 yeah, it’s depressing
Become truly multiplatform.
The distinction between dotnet, C# and all other teams is understandable. But it gets me every time with these blog posts.
If they have a checklist for things to be accounted for on every post, starting with a clarification and directions section should be in it!
Like "this post is about X, the post about Y will be/is there; and look at that other place to find out more about other projects..."
I think adding enums that are able to have multiple types like Rust has would make it easy to have more functional concepts in the language.
Rust enums and pattern matching are awesome.
Even if it would require a new keyword to use them, it would always be possible because F# has them and both languages have to be lowered to the same base code of .net.
Why tf kill XAML?? It was so easy to work with.
Unpopular opinion here. I love XAML.
Fine if you do. But please. React, SwiftUI, Jetpack Compose, Flutter, etc. are superior. I don't think it can be disputed at this point, especially since the latter three all copied React. And so did Microsoft with WinUI 3, and they really just need to get on with it. Or get dusted, as per usual, leaving us dry
React? No thanks. htmx all the way for me.
@@71Jay17 If you prefer htmx, I'm guessing XAML is a hard pass
Well, it's not very convenient for advance scenarios, but in general, it's not a big issue. The main issue is that the MAUI is still not usable, the MAUI team lacks hardcore developers, MS lacks large MAUI based projects developed not using students and interns.
@@bondarenkodf Microsoft uses React and React Native internally. It is sad
I still don't care about MAUI as long as we don't get Linux support it's not usable for me professionally and for personal projects.
AI development on Microsofts platform is nothing short of hilarious.
Mojo is fast becoming the standard and python.
MAUI improved a lot in .NET 8 with many bug fixes, but the features are still very limited compacted to Jetpack Compose or SwiftUI.
it'd be nice if .NET 8 is available on Azure App Services and not clear out the tech stack every time because there's a known bug. Microsoft knows it exists but in the github issue they claim that not enough of us are complaining to make it a priority.
My dotNET feature requests:
- GPU acceleration
- Distributed computing support
- Decimal floating point operations
That's all I ask for, Microsoft.
lol, search for 3. c# floating-point-numeric-types, 2. orleans. why tf would u do GPU acceleration in c#, maybe try Skia
Nothing about Blazor? Are they already killing it?
No, in the contrary. It just wasn't in the scope of the team writing that article.
Means there will be some improvements for Blazor too? @@krccmsitp2884
Meanwhile, I'm still upgrading projects to .NET Framework 4.7.2 at work... I can't keep up with these .NET versions anymore, and I don't like some of the new features they keep adding to C#. They're turning it into some abomination like Perl.
Considering Google's use of Go, is there potential in exploring a combined C# and Rust language (C#Rust)? or maybe improving runtime or AOT 😂
Title actually : "Why Nick Chapsas already hates .Net 9"
In my opinion, azure is crap. Every time I tested it, it was far more expensive and slower than just renting a full blown virtual server and deploying my apps on there. Shouldn't it be the other way around? If Microsoft starts forcing us to use Azure (either by introducing arbitrary limitations or by making other paths deliberately difficult), then I will turn my back on the MS dev world and consider PHP or other technologies.
We don't need DU's just like we don't need Enums that can have code and behave like classes. I imagine there is some DU framework out there somewhere that would allow you to create a base class for your discriminated Union results. I think the pattern matching system more than compensates for that.
Enums that can have methods like classes would be great. The current workaround of using extension methods is pretty cumbersome.
The Rust DUs and pattern matching are the best examples of these implementations.
I'd tried a little bit of F# and missed the "If.. let" and "let .. else" operators. By the other hand C# allows to define guard clauses using type matching. If they combine some features from F# with C# then it will be the best language.
Rust is the best example for inspiration. The way they have the Enum is very useful. If the current C# Enum has a way to store generic values it would be very great.
You can tell the guy is Greek, if he measures time in olimpics 😂
I think, as I've said many times, the iteration cycle for a lot of .Net official libraries and frameworks is too long. We shouldn't need to wait a year(multiple years) for STJ enhancements like polymorphic deserialization when the type discriminator is not the first field. Or for reusing existing fields as a type discriminator. For stuff like MAUI and Blazor this is also a very long release cycle. Oh, when the hell will SignalR support compression(Microsoft srsly you are the only source of CRIME/BREACH FUD on the internet for over a decade)?!
It is actively holding back a lot progress and inhibiting contributions. 1 year release is great for the core runtime, but for libraries and frameworks in 2024 this is forever(nvm it gets no official attention, and no outside contributions, so it's kicked out another full year in July).
You don’t really need discriminated unions when you use interfaces. Sure they close on type, but why would you actually want that?? Closed on type is good until you need to support more types.
When MAUI for Linux? Such a lie that MS "loves Linux", but years pass and no official MAUI support. Only community driven attempts.
What about a proper supported LSP for C#? We know Dev Kit comes with one. Let us use it for other editors, besides VSCode.
If you want Linux then use Uno instead.
Microsoft likes Linux on the server. On the desktop, not so much (no good RDP client, no Office, etc).
The main reason I just cannot care for MAUI is it has no linux support while avalonia exists and supprots it p well..
I have projects and plans to ship to linux + windows, MAUI not having that kinda kills any excitement I could have tbh.
I don't get it, why is the content and the title are different? Not cool.
Nick, I love your content. But, these thumbnails are so CRINGE😂
"Cloud native"? Not thanks.
Imagine C#, but with a feature rich type system such as TypeScript
That would be my dream. Typescript as a first class .NET lang
What feature ? I just hate TS because its not a big thing.
Not really typed, interfaces that actually is just a class, enums which we can't parse in runtime and another problems.
Yeah, is good to predict common mistakes in JS, but not a great thing.
I think JS must be replaced by Dart.
@@zoiobnu You talk about TypeScript as its current "frontend for JavaScript". Image it would stand on its own and compile down to CIL and have access to the .NET standard libs. In that regard it would have a far superior type system than C# and all the other shortcomings you mentioned would fall away. It would be superior to C# in every way.
.net NEIN
After 15 years on .NET left it for Kotlin. Never looked back, despite all the good things. Switched to Mac OS along the way. I wish I’ve done it way sooner. Ecosystem is way more important than syntax sugar here and there, you can figure it out by counting top systems implemented outside MS world. Happy coding, friends.
You just don't say anything.
What's wrong with XAML?
I like it, reminds me of web programming using AngularJS without the nauseous Javascript.
Asparate video please
Why do you think discriminated unions will never going to be a thing in C#? They are literally extremely easy to implement compared to a bunch of stuff in their proposals
yeah, didn't get that either. I don't see anything fundamentally incompatible in current C# that prevents DUs like in F#.
@@ChyK24
I mean, you can literally implement them by hand in the current C# using explicit struct layouts, so what is the "clashing" (in fact, I have a crate that uses source generation to do exactly this, called 'EasyUnions')? The most problematic stuff I see is with things like interfaces and stuff, but I don't think they are a good thing to use on DU's in C# anyway.
@@diadetediotedio6918 Also check out Dunet
the main issue is the LDT is still figuring out exactly how they want DU to behave and be represented
the addition itself isn't complicated
Ruh roh