Another feature that I think few people use: value tuples & tuple destructuring assignments. Especially with async methods, where you can't use out parameters, it's super comfortable to return and assign multiple values. (I always find it odd how many developers seem to hate tuples, and they'd rather define a pointless class or struct just to be able to return multiple pieces of data from a single method)
The required keyword makes parameter objects so much more useful as well. The pattern matching I’ve seen abused pretty badly though but I suppose any feature can be abused
not to be "that guy" but my OCD is getting itchy. @ - at sign & - ampersand { } - braces or curly braces ( ) - brackets or round brackets [ ] - square brackets if English isn't your first language, these things have different names than those used in the **otherwise wonderful** video
I think that the backwards compatibility is getting a bit excessive, and it would be a good idea to "purge" every once in a while to avoid having a system that carries your 20 years old mistakes and now-obsolete approaches. I don't think everything can be handled in a purely additive fashion, and as the options to do the exact same thing grow, it gets more and more confusing, especially for new developers. But of course I do love C#, and I appreciate the innovations which were introduced - my biggest real issue with the language is actually that the type system feels extremely rigid these days. As another commented mentioned, we'd arguably really need discriminated unions. I personally also really miss the literal types that I use in TypeScript - it feels like C# is not just rigid, but also lacks expressive power and precision with that "a string is a string is a string" behavior. And if you want to avoid primitive obsession, it's always an overhead, even in the simplest cases.
All C# really needs is discriminated unions. F# type system is as good as Rust one. If C# had F# type system while still being C# it would be perfect... I like F# but I hate lack of { and } that makes code so much harder to track... I'm not a fan of trying to make everything backward compatible because it leads to weird design decisions and it doesn't leave much room for innovation - making the language feel "outdated". Would be cool if M$ actually created new language that is compatible with .NET ecosystem and takes all the best from Rust, F#, C#, Kotlin
I agree, after having worked a lot with TypeScript in recent years. I'm originally coming from a dotnet/C# background, and I loved C# to no end, but these days I feel that its type system is sadly getting highly antiquated, often forcing you to jump through so many unnecessary hoops due to its rigidity. For example we have a model-driven application platform that is based on a JSON schema contract system from the consumer side, and it's virtually impossible to precisely model the component hierarchy in C# with inheritance (e.g. oneOf). I often feel like screaming when I have to resort to something crude or time-consuming while knowing that it would be the most trivial and elegant thing in TypeScript.
First off, F# (being a functional-first language) has an older, better and more powerful inference and pattern matching model than Rust does, by a mile. And inference and pattern matching, make all the difference when using Algebraic Data Types like Discriminated Unions. Not to mention the immutable data types, which empower functional programming. I feel like dismissing and not using a really powerful functional language that has interoperability with the whole .Net ecosystem and seems to suit your requirements, only because of something as superfluous as handlebars { }, is preposterous. It takes about 1 day of programming in F# or Python to get used to it. Certainly not something as important to create a whole new .Net language around. Otherwise, patience, Discriminated Unions are coming to C#
@@michaelgaziotis2538 It's not only { and } but other stuff like args as well... No ( and ) you just separate it by space. I really love certain stuff F# has to offer, but I also don't want to write everything in purely functional manner. C# is simply more readable to me and doesn't make my eyes sore. V lang looks neat. I know I would be missing a lot of stuff from .NET ecosystem though... I might try it out for fun tho.
10:50 if Microsoft cared about how much horizontal space we have for code, they'd do something about the ludicrous number of margins for indicators, code folding and other junk to the left of the VS editor window.
I really wish they'd: (a) Stop trying to turn C# into JavaScript, (b) Stop overloading every keyword into the ground, (c) Stop making C# as unreadable and cryptic as possible, (d) Stop trying to make C# overly terse... really, you type it once and the IDE helps you type it in most cases.
I think that they're doing great design on the language. But to each their own! 😊 All of the changes listed in the video (except file scoped namespaces and strings literals) do not ONLY make the language more terse, but also improve the correctness of code. A regular switch statement is more prone to errors than a switch expression (this is true for statements VS expressions in a lot of cases). Init and required improves correctness when you are forced to use property setters instead of constructor arguments, deserialization being the prime example. Records improve value semantics and are immutable and therefore increase correctness. Etc
a) Is false b) there's no way to evolve a language without new keywords. c) Modern C# code is quite more readable than equivalent code written in say C#1.1 imagine that string mess without interpolated raw string literals. d) We have a VB programmer over here ... Relax it's not Perl, and new syntax in C# rarely for terseness but instead for new abstractions.
(a) i don't want my language to have modern features (b) i don't want my language to have more features (c) i have difficulty learning new syntax (d) i want my language to stay exactly as it was when i learned it so i don't have to learn new things
02:26 Pattern matching
10:04 File scoped namespaces
12:12 Init and required;
16:04 String literals
22:23 Records
Thanks 👍
Another feature that I think few people use: value tuples & tuple destructuring assignments. Especially with async methods, where you can't use out parameters, it's super comfortable to return and assign multiple values. (I always find it odd how many developers seem to hate tuples, and they'd rather define a pointless class or struct just to be able to return multiple pieces of data from a single method)
What ur talking about.
The required keyword makes parameter objects so much more useful as well. The pattern matching I’ve seen abused pretty badly though but I suppose any feature can be abused
not to be "that guy" but my OCD is getting itchy.
@ - at sign
& - ampersand
{ } - braces or curly braces
( ) - brackets or round brackets
[ ] - square brackets
if English isn't your first language, these things have different names than those used in the **otherwise wonderful** video
Here is some features you might not be using : DARK MODE!
is there a book to incorporate all new features , remove outdated or old ones? a simplify , up to date best practice C#.
Wonderful session!! Thanks!!
I think that the backwards compatibility is getting a bit excessive, and it would be a good idea to "purge" every once in a while to avoid having a system that carries your 20 years old mistakes and now-obsolete approaches. I don't think everything can be handled in a purely additive fashion, and as the options to do the exact same thing grow, it gets more and more confusing, especially for new developers. But of course I do love C#, and I appreciate the innovations which were introduced - my biggest real issue with the language is actually that the type system feels extremely rigid these days. As another commented mentioned, we'd arguably really need discriminated unions. I personally also really miss the literal types that I use in TypeScript - it feels like C# is not just rigid, but also lacks expressive power and precision with that "a string is a string is a string" behavior. And if you want to avoid primitive obsession, it's always an overhead, even in the simplest cases.
All C# really needs is discriminated unions. F# type system is as good as Rust one. If C# had F# type system while still being C# it would be perfect... I like F# but I hate lack of { and } that makes code so much harder to track... I'm not a fan of trying to make everything backward compatible because it leads to weird design decisions and it doesn't leave much room for innovation - making the language feel "outdated". Would be cool if M$ actually created new language that is compatible with .NET ecosystem and takes all the best from Rust, F#, C#, Kotlin
I agree, after having worked a lot with TypeScript in recent years. I'm originally coming from a dotnet/C# background, and I loved C# to no end, but these days I feel that its type system is sadly getting highly antiquated, often forcing you to jump through so many unnecessary hoops due to its rigidity. For example we have a model-driven application platform that is based on a JSON schema contract system from the consumer side, and it's virtually impossible to precisely model the component hierarchy in C# with inheritance (e.g. oneOf). I often feel like screaming when I have to resort to something crude or time-consuming while knowing that it would be the most trivial and elegant thing in TypeScript.
It’s called V
First off, F# (being a functional-first language) has an older, better and more powerful inference and pattern matching model than Rust does, by a mile. And inference and pattern matching, make all the difference when using Algebraic Data Types like Discriminated Unions. Not to mention the immutable data types, which empower functional programming.
I feel like dismissing and not using a really powerful functional language that has interoperability with the whole .Net ecosystem and seems to suit your requirements, only because of something as superfluous as handlebars { }, is preposterous. It takes about 1 day of programming in F# or Python to get used to it. Certainly not something as important to create a whole new .Net language around.
Otherwise, patience, Discriminated Unions are coming to C#
@@michaelgaziotis2538 It's not only { and } but other stuff like args as well... No ( and ) you just separate it by space. I really love certain stuff F# has to offer, but I also don't want to write everything in purely functional manner. C# is simply more readable to me and doesn't make my eyes sore. V lang looks neat. I know I would be missing a lot of stuff from .NET ecosystem though... I might try it out for fun tho.
Great showcase thanks
Fine to resume all these new features, Thanks
C #이 언어 사양으로 개발되지 않기를 바랍니다.
그리고 golang과 같은 플랫폼 멀티 플랫폼에 더 중점을 두었으면 좋겠습니다.
그리고 성능에 더 중점을 두어야 합니다.
Windows와 같은 운영 체제에 의존하는 언어는 지금 미래가 없습니다.
C# does not depend on windows, its cross platform, you can run it anywhere, it is also getting much more faster in new versions with help of spans
10:50 if Microsoft cared about how much horizontal space we have for code, they'd do something about the ludicrous number of margins for indicators, code folding and other junk to the left of the VS editor window.
File scoped namespaces : One more thing that has been around in VB since forever.
I'm mostly baffled by the fact that people still default to fields and then use underscore prefixes to make sense of things.
I really wish they'd:
(a) Stop trying to turn C# into JavaScript,
(b) Stop overloading every keyword into the ground,
(c) Stop making C# as unreadable and cryptic as possible,
(d) Stop trying to make C# overly terse... really, you type it once and the IDE helps you type it in most cases.
I think that they're doing great design on the language. But to each their own! 😊
All of the changes listed in the video (except file scoped namespaces and strings literals) do not ONLY make the language more terse, but also improve the correctness of code. A regular switch statement is more prone to errors than a switch expression (this is true for statements VS expressions in a lot of cases). Init and required improves correctness when you are forced to use property setters instead of constructor arguments, deserialization being the prime example. Records improve value semantics and are immutable and therefore increase correctness. Etc
a) Is false
b) there's no way to evolve a language without new keywords.
c) Modern C# code is quite more readable than equivalent code written in say C#1.1 imagine that string mess without interpolated raw string literals.
d) We have a VB programmer over here ... Relax it's not Perl, and new syntax in C# rarely for terseness but instead for new abstractions.
you either don't know C# or you don't know Javascript. Which is it?
(a) i don't want my language to have modern features
(b) i don't want my language to have more features
(c) i have difficulty learning new syntax
(d) i want my language to stay exactly as it was when i learned it so i don't have to learn new things
@@NickMaovichperhaps both?