Mads is one of my favorites. Fun guy and always well structured talks. Good knowing C# is in capable hands. The approach to extension everything sounds fantastic!
Great talk! - Very hyped about finally getting Extension Everything! Sad there is no timeline. - I wonder if Generic Math could've been made better if it was implemented with this, or if it could be moved to use this and brought back to older runtimes. Not being able to use features bound to static interface members is a pain when you have to support netstandard2.0 target... - Very glad the way to handle breaking changes is figured and there will be less compromises caused by someone somewhere wasn't able to foresee the future language. - Happy to see collection expressions. - I've seen Primary Constructors hinted by Nick Chapsas, but now they finally make sense to me and now I'm Ok with this feature (still afraid of having to explain even more of this to older colleagues though).
Because very few people were using C#1. They added generic support as soon as they could, then basically never touched the runtime again until .Net Core (all new C# features were syntax sugar).
@@protox4That's only kinda true. There were changes in the runtime for .NET 4, the most breaking change was the removal of the ability to catch exceptions like AccessViolationException. But yeah, only (major) versions 1, 1.1, 2, and 4 existed. They of course got some updates and bugfixes, but no new features or breaking changes, until .NET Core, which added plenty.
"Sometimes" is what I'd debate here. Improving is removing things just as much as adding things. If you only add things, you can only create dinosaurs. If you assume a limit on feasible complexity, in the long run, you need to remove at least as much as you add.
explicit extensions will revolutionize primitive obsession in C#. I can't wait for it personally. Having to manually create guid-wrappers just to enforce type safety around different types of Guid - causing worsened performance and awkwardness around serialization - is terrible.
This!!! I have so many "public readonly struct BlahId : IEquatable { public readonly ushort Raw; ... boilerplate for equality, serialization, etc }" A way to remove members by extension would be cool too, but the majority of cases only needs an alias for some integer type.
I'm happy that you noticed that the small percentage of old legacy code shouldn't stop the language from moving forward - sometimes breaking is good! Maybe you should have reserved keywords for the future like rust
Breaking things is never good. Most only think it is ok when what is broken is not his/hers. In the case of "field", what you call old legacy code is something that could have been written yesterday. Starting to think it is "okay" to break things is opening the door at getting sloppy in the design and at starting to ship incomplete or inconsistent features. Improving the language is very much appreciated but stability and consistency are valuable too.
@@vincentjacquet2927 but making language ugly because of few people doesn't make sense - so there are situations where breaking is good and they should adjust their code
I guess a type alias such as : using Grade = double; is scoped to the class where it is defined. Could you have larger scoping of this, i.e. will all objects in same namespace have the type alias defined ?
i remeber Mr.Bjarne Stroustrup saying that back compatibility is a feature, yeah sure, but not if it break the language known of its elegance on doing things and stop it advancement, pls lets us not redo c++ mistakes 🙏 🤜 so go for it (a new field key word 🥳🥳🥳 🍻). Hyped about the new way of doing extensions 😎🚀🔥🔥🔥 (kinda hated the old one) Tanks for the great talk
Mads and his team are such good stewards of C#. They really strike an excellent balance for how to handle blazing a trail into the future without setting the past on fire to do it.
The #1 thing overshadowing everything here is tackling breaking changes. If version upgrades require semi-automatic code transformation, this allows "less but better" upgrades instead of patches only! Legacy issues accumulate. If you only accumulate weird issues for decades and never clean up, the language gets stuck eventually. But if you have a process in place to phase out the old, you have a fundamentally adaptive system.
BTW: I checked c# grammar and loots like keyword "new" is kind of non-mandatory meaning we could simply do: var s = Student(a, b, 10), which is pythonish but why not anyways? Do we need to stick with c++ legacy?
I had almost the exact same idea as the one in that last example except i had explicit/implicit using instead of extension. Also I dislike how the extension can affect the original type. I think it would be better if explicit/implicit affected casting to the alias.
I don't think it's that bad, it's just like the extension methods, where you still need to explicitly add 'using xxx' for the new type to be able to make it extend the original type in the given scope
instead of using a new keyword "field", reuse an existing one. I would be using "internal" in this case. So no breaking whatsover, no new keyword for one purpose and I believe "internal" makes sense in this context.
While I mostly agree, fire talks light mode is better. On the big screen behind him, on a projector or whatever, light theme is way more visible. But when I watch it on YT, on a phone or a laptop, dark theme would be so much better. I guess, adjusting so that people attending in person should be more important in this case. If you are making just a yt video with a light theme, well, karma is a bitch :D
If you are doing functional programming in C# you kind of need to use this heavily, otherwise your function signatures span three of four lines and are *really* unreadable.
26:37 my opinion: it's get and set by default, it is an auto property only. if you need get only, specify readonly, if you need private set that's a bit more difficult but I guess could also be done. ```csharp public class MyClass( public string Name, // equiv. to public string Name { get; set; } public readonly string Name2, // equiv. to public string Name2 { get; } public string Name3 private set, // equiv. to public string Name3 { get; private set; } public string Name4 init // equiv. to public string Name4 { get; init; } ); ``` you may also allow specifying the getter's visibility (e.g. `public string Name protected get private set`) but that's too cumbersome and nobody should ever have their getter's visibility different than the property's visibility itself.
Dude,,, nice info but.... you really need some language Architects for the using -side,,, for the years I've been using C# there is always some annoying thing that puts me away... for example... why yield should return a generator?? create another keyword for that behaviour (in fact you did--- it is "return yield") if the using side was done right I should be able to write something like: int f(){ yield 1; yield 3; yield 3; } and consume it anywhere in my code (in broad scope of course)... f() // return 1 f() // return 2 in any other part of my code f() // return 3 anywhere --- much like the example you gave for the primary constructors... when you were talking I was thinking... why this guys don't just implement the possibility on including a scope-accessor in the class signature and auto-declare the property... so I can declare a class with initialized members even without declaring a constructor (and parameter use also makes this dynamic) class1( public int x ) // x should be public/0 class1( public x=1 ) // x should be public/1 class1( public x=1; public =2 ) etc. etc. much more I wanted to rant... but now I have other earthly thins to attend...
Am I the only one who thinks that those extensions are kinda overkill? Yes, the "slippery slope" mentioned in the beginning is a real danger, and postponing the problem by "we will evaluate later" is not solving it. Don't get me wrong, I have enjoyed C# for many years, until about 3-4 years ago. I love extension methods (esp. generic ones), generators, iterators, you name it. But modifying the syntax for such nuisance like "primary constructors", is it really worth it? Or capturing behavior of field data... yeah, great, but for me that feels like a workaround for issues which in the other languages might not even exist, because they did their homework better in the first place.
c# / .net core is missing ONE BIG THING: machine learning libraries and integrations and unfortunately many of my colleagues with 20+ years of c#/.net experience are moving away towards python... Data is the future so what did you do in order to improve the situation?
The Python ecosystem is subverting people's minds. There is a lot of shitty Python code around (while typically the Python performance is a about an order of magnitude slower than native code, sometimes even 2x orders of magnitude). While C# performance is also not perfect but in many cases still quite close to native performance. Not a good world we live in. OTOH, my Rust code for our applications is running in circles around the equivalent C++ implementation. But people want Python because it' "that popular and easy" ... OMG.
why don't extend existing discard pattern with '_' as a default parameter value, instead of providing '[]' explicitly? Like in example public class Student(string name, int id, Grade[] grades) : this(name, id, _)
array expression, array spread, and extension for everything is a fucking game changer, composition on steroid, this feature alone could've saved me dozens of hours trying to bend some code or library that i don't have access to its source
When C# was first launched it was an amazing language. It was really simple. It struck a good balance between simplicity and features. It actually started slightly unbalanced to the poor side until they introduced generics in 2.0. Then came Linq, which introduced a layer of complexity to the language. However, because Linq was so useful, it was a very welcome addition to the language. Back then, the balance between features and simplicity was still optimal. Ever since, however, they have been adding features, and features and features... While each of the added features since Linq (not including) has been useful for a particular use case, I seriously doubt that the aggregate complexity they've added to the language has been balanced by the actual aggregate value of the new features, maybe with the exception of async tasks. Feature-wise, the language has become too unbalanced to the rich side. If they keep going down this road, C# will become the 21st century's C++, and I am not saying this in a complimentary way.
@@runninggames771 The internet... the place where people are unable to keep a civil discussion without resorting to making idiotic assumptions about the people they're talking to or about people that see things differently from what they do. Have a nice day.
I was thinking exactly what you stated here about C# becoming to complex and almost advocating for over-engineered solutions. I think many people, specially those more senior/experienced with multiple languages share the same thoughts.
still no discriminated unions, even typescript has had it for a while, with good syntax, not Java like verbose syntax - F#/typescript style is what we want; and no tail recursion. please up the game ...
It's what I want too. I can't think of anything else after that. I love how they allow me to limit exceptions to exceptional things and handle my success/fail flow control without a try/catch
They are still discussing discriminated union. They have not finalised the syntax and whether it should have tag union and union type, and if it should be based on struct.
Changing the places of the terms does not change the sum. If you think that by changing the syntax a little, you are improving the language, then you are deeply mistaken. The more ways you can do the same thing with different syntax, the more fragmentation you introduce into your clients' projects. Because programmers inside one project will start holy wars out of nothing on how to do it right.
@@obinnaokafor6252 I cannot answer for @ivendrofly but, for my part, I would say all of C# 12 features presented here. Do not get me wrong, I do not mean they are bad or useless. They are convenient but, as such, they are simply other way of doing something we can already do and therefore they are not necessary. ref return values or ref structs were necessary, as there was no other way of doing what they do. explicit/implict extensions would be necessary as it is a way to add static members or operators, something we cannot do for now. Please note that I did not included instance properties or events. As properties and events are methods with special names under the hood, I never understood why they could not support this with "regular" extensions. They have to do better than "we tried" to convice me.
You're not forced to use C# 12 - and if you are, you're not forced to use the new features. Just because you don't need a feature, doesn't mean someone else doesn't, and it certainly doesn't make it bloated. 🤦♂
I've listened to a lot of his talks before, and I haven't noticed the quantity of "umms" and long "ahhs" until this one. I love his talks and I hope he works on that, because I find it extremely distracting.
i’ve heard it in his previous talks at a mild level. yes always something to work on. you never know what may have been going on behind the scene maybe distracting his mind which often amplify verbal ticks
Mads is Danish, i.e. english isn't his native language, although he's a fluent speaker. I think he's doing a great job, and a much better job than most other non native speakers.
His twitter says opinions are his own, except it seems he is wearing a political shirt to make a statement while he talks work. The shirt SEEMS to be palestine red and green freedom?
I just love listening to Mads while learning more about the language!
Mads is one of my favorites. Fun guy and always well structured talks. Good knowing C# is in capable hands. The approach to extension everything sounds fantastic!
thanks for re-uploading, this is a great talk
Extraordinary talk! Thank you!!
Great talk!
- Very hyped about finally getting Extension Everything! Sad there is no timeline.
- I wonder if Generic Math could've been made better if it was implemented with this, or if it could be moved to use this and brought back to older runtimes. Not being able to use features bound to static interface members is a pain when you have to support netstandard2.0 target...
- Very glad the way to handle breaking changes is figured and there will be less compromises caused by someone somewhere wasn't able to foresee the future language.
- Happy to see collection expressions.
- I've seen Primary Constructors hinted by Nick Chapsas, but now they finally make sense to me and now I'm Ok with this feature (still afraid of having to explain even more of this to older colleagues though).
"extension everything" FTW! I can't tell you how many times I could have used something like this.
inheritance becomes basically obsolete, true composability of types is finally possible
This is all very promising, really excited about the extension everything proposal, hopefully it makes it to C# 13.
Super pumped for New Extension and Semi Auto Props. Hope we'd get it in C# 13
Well, I think C# requires breaking changes sometimes. You did this in version 2.0 when you introduced generics, why do you fear to do it now?
Because very few people were using C#1. They added generic support as soon as they could, then basically never touched the runtime again until .Net Core (all new C# features were syntax sugar).
@@protox4That's only kinda true.
There were changes in the runtime for .NET 4, the most breaking change was the removal of the ability to catch exceptions like AccessViolationException.
But yeah, only (major) versions 1, 1.1, 2, and 4 existed. They of course got some updates and bugfixes, but no new features or breaking changes, until .NET Core, which added plenty.
"Sometimes" is what I'd debate here. Improving is removing things just as much as adding things. If you only add things, you can only create dinosaurs.
If you assume a limit on feasible complexity, in the long run, you need to remove at least as much as you add.
explicit extensions will revolutionize primitive obsession in C#. I can't wait for it personally. Having to manually create guid-wrappers just to enforce type safety around different types of Guid - causing worsened performance and awkwardness around serialization - is terrible.
This!!! I have so many "public readonly struct BlahId : IEquatable { public readonly ushort Raw; ... boilerplate for equality, serialization, etc }"
A way to remove members by extension would be cool too, but the majority of cases only needs an alias for some integer type.
very excited to see that semi-auto properties are on their way!!
each year C# gets harder and harder to learn as an outsider - are there core guidelines for how to differentiate features like C++ has?
C# is certainly _bloated_ :/
Who is the David that Mads is chatting with at 35:45?
Probably David Fowler
Thank you
I'm happy that you noticed that the small percentage of old legacy code shouldn't stop the language from moving forward - sometimes breaking is good! Maybe you should have reserved keywords for the future like rust
Breaking things is never good. Most only think it is ok when what is broken is not his/hers. In the case of "field", what you call old legacy code is something that could have been written yesterday.
Starting to think it is "okay" to break things is opening the door at getting sloppy in the design and at starting to ship incomplete or inconsistent features. Improving the language is very much appreciated but stability and consistency are valuable too.
@@vincentjacquet2927 but making language ugly because of few people doesn't make sense - so there are situations where breaking is good and they should adjust their code
What’s the cliffnotes? Is there an article version of this?
I guess a type alias such as :
using Grade = double;
is scoped to the class where it is defined. Could you have larger scoping of this, i.e. will all objects in same namespace have the type alias defined ?
i’ve literally been drooling over extension everything for years now, i want it so badddddddd
i remeber Mr.Bjarne Stroustrup saying that back compatibility is a feature, yeah sure, but not if it break the language known of its elegance on doing things and stop it advancement, pls lets us not redo c++ mistakes 🙏 🤜 so go for it (a new field key word 🥳🥳🥳 🍻).
Hyped about the new way of doing extensions 😎🚀🔥🔥🔥 (kinda hated the old one)
Tanks for the great talk
no need for a new "field" keyword in that instance. I believe the existing keyword "internal" would be adequate.
The extensions are very similar to traits in rust.
Re-learn C# every year! But I'm happy to do that.
Mads and his team are such good stewards of C#. They really strike an excellent balance for how to handle blazing a trail into the future without setting the past on fire to do it.
he's the goat
Maybe I'm just failing to understand, but in which way does Extension Everything differ from just classic inheritance?
Didn't watch the whole video, did we get better Type Inference?
The #1 thing overshadowing everything here is tackling breaking changes.
If version upgrades require semi-automatic code transformation, this allows "less but better" upgrades instead of patches only!
Legacy issues accumulate. If you only accumulate weird issues for decades and never clean up, the language gets stuck eventually. But if you have a process in place to phase out the old, you have a fundamentally adaptive system.
BTW: I checked c# grammar and loots like keyword "new" is kind of non-mandatory meaning we could simply do: var s = Student(a, b, 10), which is pythonish but why not anyways? Do we need to stick with c++ legacy?
I had almost the exact same idea as the one in that last example except i had explicit/implicit using instead of extension.
Also I dislike how the extension can affect the original type. I think it would be better if explicit/implicit affected casting to the alias.
I don't think it's that bad, it's just like the extension methods, where you still need to explicitly add 'using xxx' for the new type to be able to make it extend the original type in the given scope
instead of using a new keyword "field", reuse an existing one. I would be using "internal" in this case. So no breaking whatsover, no new keyword for one purpose and I believe "internal" makes sense in this context.
Who out there is naming things 'field'???
I think a breaking change of this magnitude could be coped with.
They need to make light theme visual studio illegal for these conferences
😂
I hate the dark mode, it's way harder for me to read it. For each their own.
While I mostly agree, fire talks light mode is better. On the big screen behind him, on a projector or whatever, light theme is way more visible.
But when I watch it on YT, on a phone or a laptop, dark theme would be so much better.
I guess, adjusting so that people attending in person should be more important in this case.
If you are making just a yt video with a light theme, well, karma is a bitch :D
I hate dark mode.
First world problems. lol
using Grade = decimal
reminds me of c/c++ typedef which make code totally unreadable.
If you are doing functional programming in C# you kind of need to use this heavily, otherwise your function signatures span three of four lines and are *really* unreadable.
26:37 my opinion:
it's get and set by default, it is an auto property only.
if you need get only, specify readonly, if you need private set that's a bit more difficult but I guess could also be done.
```csharp
public class MyClass(
public string Name, // equiv. to public string Name { get; set; }
public readonly string Name2, // equiv. to public string Name2 { get; }
public string Name3 private set, // equiv. to public string Name3 { get; private set; }
public string Name4 init // equiv. to public string Name4 { get; init; }
);
```
you may also allow specifying the getter's visibility (e.g. `public string Name protected get private set`) but that's too cumbersome and nobody should ever have their getter's visibility different than the property's visibility itself.
It's quite disappointing that neither records nor these pimary constructos provide possibility for validation.
Dude,,, nice info but.... you really need some language Architects for the using -side,,, for the years I've been using C# there is always some annoying thing that puts me away...
for example... why yield should return a generator?? create another keyword for that behaviour (in fact you did--- it is "return yield")
if the using side was done right I should be able to write something like:
int f(){ yield 1; yield 3; yield 3; }
and consume it anywhere in my code (in broad scope of course)...
f() // return 1
f() // return 2 in any other part of my code
f() // return 3 anywhere
---
much like the example you gave for the primary constructors... when you were talking I was thinking... why this guys don't just implement the possibility on including a scope-accessor in the class signature and auto-declare the property... so I can declare a class with initialized members even without declaring a constructor (and parameter use also makes this dynamic)
class1( public int x ) // x should be public/0
class1( public x=1 ) // x should be public/1
class1( public x=1; public =2 )
etc. etc.
much more I wanted to rant... but now I have other earthly thins to attend...
Am I the only one who thinks that those extensions are kinda overkill? Yes, the "slippery slope" mentioned in the beginning is a real danger, and postponing the problem by "we will evaluate later" is not solving it.
Don't get me wrong, I have enjoyed C# for many years, until about 3-4 years ago. I love extension methods (esp. generic ones), generators, iterators, you name it. But modifying the syntax for such nuisance like "primary constructors", is it really worth it? Or capturing behavior of field data... yeah, great, but for me that feels like a workaround for issues which in the other languages might not even exist, because they did their homework better in the first place.
c# / .net core is missing ONE BIG THING: machine learning libraries and integrations and unfortunately many of my colleagues with 20+ years of c#/.net experience are moving away towards python... Data is the future so what did you do in order to improve the situation?
The Python ecosystem is subverting people's minds. There is a lot of shitty Python code around (while typically the Python performance is a about an order of magnitude slower than native code, sometimes even 2x orders of magnitude). While C# performance is also not perfect but in many cases still quite close to native performance.
Not a good world we live in.
OTOH, my Rust code for our applications is running in circles around the equivalent C++ implementation. But people want Python because it' "that popular and easy" ... OMG.
why don't extend existing discard pattern with '_' as a default parameter value, instead of providing '[]' explicitly? Like in example public class Student(string name, int id, Grade[] grades) : this(name, id, _)
It's new syntax for array so it is in line with var too = […]
array expression, array spread, and extension for everything is a fucking game changer, composition on steroid, this feature alone could've saved me dozens of hours trying to bend some code or library that i don't have access to its source
When C# was first launched it was an amazing language. It was really simple. It struck a good balance between simplicity and features. It actually started slightly unbalanced to the poor side until they introduced generics in 2.0. Then came Linq, which introduced a layer of complexity to the language. However, because Linq was so useful, it was a very welcome addition to the language. Back then, the balance between features and simplicity was still optimal. Ever since, however, they have been adding features, and features and features... While each of the added features since Linq (not including) has been useful for a particular use case, I seriously doubt that the aggregate complexity they've added to the language has been balanced by the actual aggregate value of the new features, maybe with the exception of async tasks. Feature-wise, the language has become too unbalanced to the rich side. If they keep going down this road, C# will become the 21st century's C++, and I am not saying this in a complimentary way.
Just dont use the features you dont need then.
@@runninggames771 Look for Rob Pike's presentation about simplicity being complicated and you'll get a better understanding of what I mean.
@@rui.craveiro Nah, id rather a language not be gimped because people are too scared to read the documentation on stuff they dont know.
@@runninggames771 The internet... the place where people are unable to keep a civil discussion without resorting to making idiotic assumptions about the people they're talking to or about people that see things differently from what they do. Have a nice day.
I was thinking exactly what you stated here about C# becoming to complex and almost advocating for over-engineered solutions. I think many people, specially those more senior/experienced with multiple languages share the same thoughts.
C ♭?
Si Hash you mean?
still no discriminated unions, even typescript has had it for a while, with good syntax, not Java like verbose syntax - F#/typescript style is what we want; and no tail recursion. please up the game ...
It's what I want too. I can't think of anything else after that. I love how they allow me to limit exceptions to exceptional things and handle my success/fail flow control without a try/catch
They are still discussing discriminated union. They have not finalised the syntax and whether it should have tag union and union type, and if it should be based on struct.
Enums (tag unions) from rust are great examples of how this should be done
Changing the places of the terms does not change the sum. If you think that by changing the syntax a little, you are improving the language, then you are deeply mistaken. The more ways you can do the same thing with different syntax, the more fragmentation you introduce into your clients' projects. Because programmers inside one project will start holy wars out of nothing on how to do it right.
Some of the new stuff is just unnecessary!
Could you give examples of those which are not necessary?
@@obinnaokafor6252 I cannot answer for @ivendrofly but, for my part, I would say all of C# 12 features presented here. Do not get me wrong, I do not mean they are bad or useless. They are convenient but, as such, they are simply other way of doing something we can already do and therefore they are not necessary. ref return values or ref structs were necessary, as there was no other way of doing what they do.
explicit/implict extensions would be necessary as it is a way to add static members or operators, something we cannot do for now. Please note that I did not included instance properties or events. As properties and events are methods with special names under the hood, I never understood why they could not support this with "regular" extensions. They have to do better than "we tried" to convice me.
C# gets more and more bloated! Just fire the C# team.
You're not forced to use C# 12 - and if you are, you're not forced to use the new features. Just because you don't need a feature, doesn't mean someone else doesn't, and it certainly doesn't make it bloated. 🤦♂
@@impero101
I am forced to learn and use it because I work in a team full of NPC's like you and most people.
I've listened to a lot of his talks before, and I haven't noticed the quantity of "umms" and long "ahhs" until this one. I love his talks and I hope he works on that, because I find it extremely distracting.
i’ve heard it in his previous talks at a mild level. yes always something to work on. you never know what may have been going on behind the scene maybe distracting his mind which often amplify verbal ticks
Mads is Danish, i.e. english isn't his native language, although he's a fluent speaker. I think he's doing a great job, and a much better job than most other non native speakers.
Now you made me notice it. I was fine before you did 🙂
@@marklord7614 I'm sorry. I was really disappointed that I couldn't listen to the talk. We need AI that will automatically remove them from the video.
12 minutes in any Nothing of value. Wow.
If it is not valuable to you, it is to others. lol
His twitter says opinions are his own, except it seems he is wearing a political shirt to make a statement while he talks work. The shirt SEEMS to be palestine red and green freedom?
It's not. It's a Juneteenth t-shirt - a federal holiday in US commemorating the end of slavery.
What’s next in C#? If the answer is anything other than its total downfall I don’t care. I hate that language.
Why?
What a useless comment; nothing to back your statement up, just your simple opinion.
Your comment added absolutely NOTHING.
you can always dream about it
No one cares. No one asked.
Okay, then don't use it. That simple.