6 ms·

C# 7.0 – What to Expect

105 points by chachram 10y ago

rco8786 10y ago
C# is basically becoming Scala
- steego 10y ago
  Minus the type system that is itself Turing complete. In all seriousness, the culture behind C# is way too conservative for it to ever to become like Scala. They add features, but they're nowhere near as bold and daring as the Scala team. As a language, Scala's is both incredibly impressive and terrifying from an Abstraction Astronaut's perspective. Even F# is very conservative compared to Scala.
  - algorithmsRcool 10y ago
    I had a lot of hope for some wilder C# changes with the .Net core change. But i see a lot of hold back from established codebases. I almost wish we could fork the language to target the Java-esque crowd and the Go/Swift/Scala crowd.
  - premium-concern 10y ago
    Yes, C# really prefers adding two dozen special cases and language features instead of providing one generic way of achieving something like in Scala. :-(
danielvf 10y ago
C# continues its tradition of stealing the good stuff from other languages. I'm really impressed. Pattern matching and immutable objects? This is great!
- hd4 10y ago
  “Good artists borrow, great artists steal.”
- matthewwarren 10y ago
  It doesn't always steal, AFAIK is was the first language to introduce "async" and the compiler magic that goes with it, i.e. so you don't have to use callbacks everywhere.
  - yareally 10y ago
    Async/await started with F# and was added to C# later.
    - soulbadguy 10y ago
      While booth F# and C# have the same aim, they have totaly unrelated implementation and are quite different beats. IMO the C# design wasnt derived from F#.
    - edgyswingset 10y ago
      They are similar in that F# was the first .NET language to say, "what could language constructs for asynchrony look like?" and implement it. They are fundamentally different models, though. F# uses a "cold task" model where invoking an async function returns a specification of work, which you must then start. You can start this work in different ways so that you have control over the semantics of how it executes. C# uses a "hot task" models, where invoking the async method returns a handle to background work that has already been "kicked off". This is actually an oversimplification, because the semantics of what is actually the asynchronous thing you're awaiting can differ. But the overall concept follows this pattern.
  - algorithmsRcool 10y ago
    I think F# had similar syntax prior to C# with Async Workflows. But C#'s refinement of this syntax seems to have caught a lot more attention. I can't wait to have Async + ValueTask in C# 7 to help reduce the penalty of Async a bit more.
  - PeCaN 10y ago
    Alice ML¹ had that in 2000², and the idea of promises/futures dates back to the 70s. async/await to flatten promise hierarchies is decidedly _not_ a new idea. ¹ http://www.ps.uni-saarland.de/alice/manual/futures.html http://www.ps.uni-saarland.de/alice/manual/futures.html ² Well, it used "spawn" instead of "await". The semantics are very similar though.
- Analemma_ 10y ago
  IMO, C# is the language that best hits the sweet spot of evolution pace: not so slow that it becomes stagnant and outdated, but not so fast that people feel adrift and confused. C# 6 may not have had any show-stopper features like Linq or async/await, but the syntactic sugar all aimed at immutable/functional styles have let me clean up my code tremendously, and it looks like 7 is going to be more of that. Looking forward to it very much. Edit: I stand by my statement even though I guess pattern matching and immutable types will have to wait for C# 8. The Python-esque tuples allowing for multiple return values without out params or Tuple<> is enough to keep me happy :)
  - biot 10y ago
    I'd say they added a dash of Erlang to C# with the tuples and pattern matching.
- Const-me 10y ago
  This is a two-way street. For example, many languages (Python, JavaScript, Scala, C++) already “stole” async-await stuff from C#. As long as they don’t break IP or patent laws, I don’t see any problems with that.
  - merb 10y ago
    definitly not. Python was late too the game yes, but I guess all the others had it way before C# (since 2012) https://en.wikipedia.org/wiki/Futures_and_promises https://en.wikipedia.org/wiki/Futures_and_promises The only one that "stole" it was maybe Swift.
    - Const-me 10y ago
      Async-await isn’t just futures or promises. It’s compile-time + runtime mechanism that builds those promises from the code that looks like blocking calls (i.e. easy to read, write and debug), but uses asynchronous IO under the hood (i.e. scalable). BTW, have you read the article you linked? Because among other things, it currently says the following: Several mainstream languages now have language support for futures and promises, most notably popularized by the async and await constructions in .NET 4.5 largely inspired by the asynchronous workflows of F#, which dates to 2007. This has subsequently been adopted by other languages, notably Dart (2014), Python (2015), Hack (HHVM), and drafts of ECMAScript 7 (JavaScript), Scala, and C++.
greenspot 10y ago
Since I haven't see many new Windows apps the recent years, who is actively developing new apps in C# and if yes, what kind of apps, which platforms, etc.? Is it mainly games?
- shinymark 10y ago
  Lots of games use C# because the popular Unity engine uses Mono as a runtime for user code. Anecdotally I have some friends writing business software at various BigCo companies that use C#. Edit: it's perhaps worth mentioning that there is some more nuance to the Unity situation with their IL2CPP tech. Bottom line: engine users are writing C#.
- Gmo 10y ago
  Our web stack is in C#
- pjmlp 10y ago
  .NET has won the war over the desktop in what concerns native applications for Windows on the big corporations. On all enterprise customers that we work with, think DAX, if the application is to run native on the desktop, which is usually means Windows workstations, the software stack tends to be .NET with some C++ here and there. Sun never managed to understand the desktop and Oracle even less. So unless the customer has requirements for portable desktop applications, the solution is .NET.
  - greenspot 10y ago
    Totally clear that mainstream desktop is Windows, native and .NET but the question again and since there are rarely new apps on Windows: who is actively developing new desktop apps in C#, .NET on Windows which are not games?
    - coldtea 10y ago
      >who is actively developing new desktop apps in C#, .NET on Windows which are not games? Almost everybody doing in-house enterprise desktop apps (and those are a heck of a lot) and tons of people doing desktop Windows apps that don't need to be C++ (e.g. not Photoshop, Office and co). Again, those are in the tens or hundreds of thousands. Check any Windows app review site or repo for examples.
recursive 10y ago
I'm curious how array slicing is any different from ArraySegment<T>, which is very old.
- algorithmsRcool 10y ago
  ArraySegment<T> is just a array reference with range delimiters. Slice/Span gives you a low overhead, type safe window into a block of memory that can be reinterpreted without allocating new memory. It's implementation involves some IL level pointer hacks to keep it fast. Joe Duffy's first implmentation of it is here: https://github.com/joeduffy/slice.net https://github.com/joeduffy/slice.net The more recent work for CoreFX is here: https://github.com/dotnet/corefxlab/tree/master/src/System.Slices https://github.com/dotnet/corefxlab/tree/master/src/System.S...
  - premium-concern 10y ago
    So instead of improving the implementation of ArraySegment they just add yet another way of doing it? This is of course expected for languages which keep piling up stuff but still disappointing.
    - pjmlp 10y ago
      Because of backwards compatibility.
      - premium-concern 10y ago
        How is that impacted by a faster implementation technique? Are you arguing that some people rely on ArraySegment being slow?
        pjmlp 10y ago
        No, it isn't compatible with any of the existing APIs that accept array or strings. So making it compatible would probably require breaking its semantics.
vmarsy 10y ago
The feature below amazing, I wonder how Visual studio will display it, I like it when above Properties it adds the ref count across the Solution: 3 references public int Damage { get; } 4 references public int Durability { get; } public class Sword(int Damage, int Durability); This single line will result in a fully functional class: public class Sword : IEquatable<Sword> { public int Damage { get; } public int Durability { get; } public Sword(int Damage, int Durability) { this.Damage = Damage; this.Durability = Durability; } public bool Equals(Sword other) { return Equals(Damage, other.Damage) && Equals(Durability, other.Durability); } public override bool Equals(object other) { return (other as Sword)?.Equals(this) == true; } public override int GetHashCode() { return (Damage.GetHashCode() * 17 + Durability.GetHashCode()) .GetValueOrDefault(); } public static void operator is(Sword self, out int Damage, out int Durability) { Damage = self.Damage; Durability = self.Durability; } public Sword With(int Damage = this.Damage, int Durability = this.Durability) => new Sword(Damage, Durability); }
dodyg 10y ago
This article is out of date. Feature such as With expression has been pushed to version 7+. They have also trim down the ambition of pattern matching for c# 7. The best way to keep track of C# 7 feature is through their public roadmap https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md https://github.com/dotnet/roslyn/blob/master/docs/Language%2...
algorithmsRcool 10y ago
Amoungst other things, this article covers Pattern Matching, Record Types and Non-Nullable Reference types. All of which are great features but all of which will likely not be in C# 7 unfortunately due to shipping timelines [0]. 0: https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md https://github.com/dotnet/roslyn/blob/master/docs/Language%2...
algorithmsRcool 10y ago
In addition to the new language features there are some very exciting new APIs being designed at: https://github.com/dotnet/corefxlab https://github.com/dotnet/corefxlab Including a new higher performance/lower allocation text formatting API: https://github.com/dotnet/corefxlab/wiki/System.Text.Formatting https://github.com/dotnet/corefxlab/wiki/System.Text.Formatt...
srean 10y ago
No biggie, but I do miss rotate, partition, nth_element from STL. Its just that when I came to C# i came with an expectation that it would have all of STL covered and more.
jmartinpetersen 10y ago
Object orientation and pattern matching is not an obvious mix. A lot of OO is about dependency inversion, which is more or less the exact opposite of what pattern matching gives you. It can be a powerful tool in the right hands but could also lead to absolute horror. Sometimes it feels like Mads and co. are too focused on making C# functional-like and in the process encourages a lot of foot-shooting.
- ahartman00 10y ago
  "Sometimes it feels like Mads and co. are too focused on making C# functional-like and in the process encourages a lot of foot-shooting" I agree. When they added dynamic and functional concepts, I though: great, a dynamic/statically typed imperative/functional oo language. Too many different ways to do things, makes it harder to understand code written in a different style. Basically the opposite of python's "pythonic way" idiomatic style. I do love functional programming, which is why I am trying to move to f#. People at work are open to the idea!!

105 points by chachram 10y ago

rco8786 10y ago

C# is basically becoming Scala

steego 10y ago
Minus the type system that is itself Turing complete. In all seriousness, the culture behind C# is way too conservative for it to ever to become like Scala. They add features, but they're nowhere near as bold and daring as the Scala team. As a language, Scala's is both incredibly impressive and terrifying from an Abstraction Astronaut's perspective. Even F# is very conservative compared to Scala.
- algorithmsRcool 10y ago
  I had a lot of hope for some wilder C# changes with the .Net core change. But i see a lot of hold back from established codebases. I almost wish we could fork the language to target the Java-esque crowd and the Go/Swift/Scala crowd.
- premium-concern 10y ago
  Yes, C# really prefers adding two dozen special cases and language features instead of providing one generic way of achieving something like in Scala. :-(

danielvf 10y ago

C# continues its tradition of stealing the good stuff from other languages. I'm really impressed. Pattern matching and immutable objects? This is great!

hd4 10y ago
“Good artists borrow, great artists steal.”
matthewwarren 10y ago
It doesn't always steal, AFAIK is was the first language to introduce "async" and the compiler magic that goes with it, i.e. so you don't have to use callbacks everywhere.
- yareally 10y ago
  Async/await started with F# and was added to C# later.
  - soulbadguy 10y ago
    While booth F# and C# have the same aim, they have totaly unrelated implementation and are quite different beats. IMO the C# design wasnt derived from F#.
  - edgyswingset 10y ago
    They are similar in that F# was the first .NET language to say, "what could language constructs for asynchrony look like?" and implement it. They are fundamentally different models, though. F# uses a "cold task" model where invoking an async function returns a specification of work, which you must then start. You can start this work in different ways so that you have control over the semantics of how it executes. C# uses a "hot task" models, where invoking the async method returns a handle to background work that has already been "kicked off". This is actually an oversimplification, because the semantics of what is actually the asynchronous thing you're awaiting can differ. But the overall concept follows this pattern.
- algorithmsRcool 10y ago
  I think F# had similar syntax prior to C# with Async Workflows. But C#'s refinement of this syntax seems to have caught a lot more attention. I can't wait to have Async + ValueTask in C# 7 to help reduce the penalty of Async a bit more.
- PeCaN 10y ago
  Alice ML¹ had that in 2000², and the idea of promises/futures dates back to the 70s. async/await to flatten promise hierarchies is decidedly _not_ a new idea. ¹ http://www.ps.uni-saarland.de/alice/manual/futures.html http://www.ps.uni-saarland.de/alice/manual/futures.html ² Well, it used "spawn" instead of "await". The semantics are very similar though.
Analemma_ 10y ago
IMO, C# is the language that best hits the sweet spot of evolution pace: not so slow that it becomes stagnant and outdated, but not so fast that people feel adrift and confused. C# 6 may not have had any show-stopper features like Linq or async/await, but the syntactic sugar all aimed at immutable/functional styles have let me clean up my code tremendously, and it looks like 7 is going to be more of that. Looking forward to it very much. Edit: I stand by my statement even though I guess pattern matching and immutable types will have to wait for C# 8. The Python-esque tuples allowing for multiple return values without out params or Tuple<> is enough to keep me happy :)
- biot 10y ago
  I'd say they added a dash of Erlang to C# with the tuples and pattern matching.
Const-me 10y ago
This is a two-way street. For example, many languages (Python, JavaScript, Scala, C++) already “stole” async-await stuff from C#. As long as they don’t break IP or patent laws, I don’t see any problems with that.
- merb 10y ago
  definitly not. Python was late too the game yes, but I guess all the others had it way before C# (since 2012) https://en.wikipedia.org/wiki/Futures_and_promises https://en.wikipedia.org/wiki/Futures_and_promises The only one that "stole" it was maybe Swift.
  - Const-me 10y ago
    Async-await isn’t just futures or promises. It’s compile-time + runtime mechanism that builds those promises from the code that looks like blocking calls (i.e. easy to read, write and debug), but uses asynchronous IO under the hood (i.e. scalable). BTW, have you read the article you linked? Because among other things, it currently says the following: Several mainstream languages now have language support for futures and promises, most notably popularized by the async and await constructions in .NET 4.5 largely inspired by the asynchronous workflows of F#, which dates to 2007. This has subsequently been adopted by other languages, notably Dart (2014), Python (2015), Hack (HHVM), and drafts of ECMAScript 7 (JavaScript), Scala, and C++.

greenspot 10y ago

Since I haven't see many new Windows apps the recent years, who is actively developing new apps in C# and if yes, what kind of apps, which platforms, etc.? Is it mainly games?

shinymark 10y ago
Lots of games use C# because the popular Unity engine uses Mono as a runtime for user code. Anecdotally I have some friends writing business software at various BigCo companies that use C#. Edit: it's perhaps worth mentioning that there is some more nuance to the Unity situation with their IL2CPP tech. Bottom line: engine users are writing C#.
Gmo 10y ago
Our web stack is in C#
pjmlp 10y ago
.NET has won the war over the desktop in what concerns native applications for Windows on the big corporations. On all enterprise customers that we work with, think DAX, if the application is to run native on the desktop, which is usually means Windows workstations, the software stack tends to be .NET with some C++ here and there. Sun never managed to understand the desktop and Oracle even less. So unless the customer has requirements for portable desktop applications, the solution is .NET.
- greenspot 10y ago
  Totally clear that mainstream desktop is Windows, native and .NET but the question again and since there are rarely new apps on Windows: who is actively developing new desktop apps in C#, .NET on Windows which are not games?
  - coldtea 10y ago
    >who is actively developing new desktop apps in C#, .NET on Windows which are not games? Almost everybody doing in-house enterprise desktop apps (and those are a heck of a lot) and tons of people doing desktop Windows apps that don't need to be C++ (e.g. not Photoshop, Office and co). Again, those are in the tens or hundreds of thousands. Check any Windows app review site or repo for examples.

recursive 10y ago

I'm curious how array slicing is any different from ArraySegment<T>, which is very old.

algorithmsRcool 10y ago
ArraySegment<T> is just a array reference with range delimiters. Slice/Span gives you a low overhead, type safe window into a block of memory that can be reinterpreted without allocating new memory. It's implementation involves some IL level pointer hacks to keep it fast. Joe Duffy's first implmentation of it is here: https://github.com/joeduffy/slice.net https://github.com/joeduffy/slice.net The more recent work for CoreFX is here: https://github.com/dotnet/corefxlab/tree/master/src/System.Slices https://github.com/dotnet/corefxlab/tree/master/src/System.S...
- premium-concern 10y ago
  So instead of improving the implementation of ArraySegment they just add yet another way of doing it? This is of course expected for languages which keep piling up stuff but still disappointing.
  - pjmlp 10y ago
    Because of backwards compatibility.
    - premium-concern 10y ago
      How is that impacted by a faster implementation technique? Are you arguing that some people rely on ArraySegment being slow?
      - pjmlp 10y ago
        No, it isn't compatible with any of the existing APIs that accept array or strings. So making it compatible would probably require breaking its semantics.

vmarsy 10y ago

The feature below amazing, I wonder how Visual studio will display it, I like it when above Properties it adds the ref count across the Solution: 3 references public int Damage { get; } 4 references public int Durability { get; } public class Sword(int Damage, int Durability); This single line will result in a fully functional class: public class Sword : IEquatable<Sword> { public int Damage { get; } public int Durability { get; } public Sword(int Damage, int Durability) { this.Damage = Damage; this.Durability = Durability; } public bool Equals(Sword other) { return Equals(Damage, other.Damage) && Equals(Durability, other.Durability); } public override bool Equals(object other) { return (other as Sword)?.Equals(this) == true; } public override int GetHashCode() { return (Damage.GetHashCode() * 17 + Durability.GetHashCode()) .GetValueOrDefault(); } public static void operator is(Sword self, out int Damage, out int Durability) { Damage = self.Damage; Durability = self.Durability; } public Sword With(int Damage = this.Damage, int Durability = this.Durability) => new Sword(Damage, Durability); }

dodyg 10y ago

This article is out of date. Feature such as With expression has been pushed to version 7+. They have also trim down the ambition of pattern matching for c# 7. The best way to keep track of C# 7 feature is through their public roadmap https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md https://github.com/dotnet/roslyn/blob/master/docs/Language%2...

algorithmsRcool 10y ago

Amoungst other things, this article covers Pattern Matching, Record Types and Non-Nullable Reference types. All of which are great features but all of which will likely not be in C# 7 unfortunately due to shipping timelines [0]. 0: https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md https://github.com/dotnet/roslyn/blob/master/docs/Language%2...

algorithmsRcool 10y ago

In addition to the new language features there are some very exciting new APIs being designed at: https://github.com/dotnet/corefxlab https://github.com/dotnet/corefxlab Including a new higher performance/lower allocation text formatting API: https://github.com/dotnet/corefxlab/wiki/System.Text.Formatting https://github.com/dotnet/corefxlab/wiki/System.Text.Formatt...

srean 10y ago

No biggie, but I do miss rotate, partition, nth_element from STL. Its just that when I came to C# i came with an expectation that it would have all of STL covered and more.

jmartinpetersen 10y ago

Object orientation and pattern matching is not an obvious mix. A lot of OO is about dependency inversion, which is more or less the exact opposite of what pattern matching gives you. It can be a powerful tool in the right hands but could also lead to absolute horror. Sometimes it feels like Mads and co. are too focused on making C# functional-like and in the process encourages a lot of foot-shooting.

ahartman00 10y ago
"Sometimes it feels like Mads and co. are too focused on making C# functional-like and in the process encourages a lot of foot-shooting" I agree. When they added dynamic and functional concepts, I though: great, a dynamic/statically typed imperative/functional oo language. Too many different ways to do things, makes it harder to understand code written in a different style. Basically the opposite of python's "pythonic way" idiomatic style. I do love functional programming, which is why I am trying to move to f#. People at work are open to the idea!!