C# 7 Work List of Features | Hacker News Reader

C# 7 Work List of Features

github.com

246 pointsrajeemcariazo145 comments

Open articleView on HN

Wow.. This "Strong interest list" is awesome:

* Tuples (Proposal: #347)

* Pattern matching (Proposal: #206)

* Records / algebraic data types (Proposal: #206)

* Nullability tracking (Proposal: #227)

* Async streams and disposal (Proposals: #114, #261)

They seem to be really useful for a "more-functional style" of programming.

When comparing these ambitions and the level of transparency to Java's ambitions & transparency, then it seems that C# is (or has) overtaking Java. Combine that to the fact that dotnet is now an opensource project, and MS seems to be more "open" nowadays then Oracle has ever been: I'm stoked about this news.

Java's strength is not the power of the language, and nobody ever claimed so. They improve it bit by bit, but that's all. You want to use uber-cool features? Try Scala or any of the gazillions other languages/platforms JVM fully supports.

(personal anecdote - as senior java guy with 10+ years of experience, I've got recently assigned a small project of amending legacy MFC C++ (but mostly C) app - I could write a book about the pain. Language itself is a minor obstacle in this effort (albeit MFC/WinAPI has very steep learning curve for me).

Where Java wins, and will win for many years to come is maturity of toolset, quality of open source libraries and also probably the most important thing - the amount of skilled developers any employer can pick from.

.NET platform will probably get (finally) on track, but it's an uphill battle against Oracle's current position. But I like the situation - improvement in MS camp will force competition to improve as well, so we all benefit :)

> ".NET platform will probably get (finally) on track"

Eh? .NET land has been on a higher technical superiority level to Java for almost a decade. Pretty much as soon as .NET got generics at the CLR level the tide was changing. Then that so-called LINQ feature in C# put the final nail in the Java coffin. The fact that .NET has always had value types and function/delegate types from day one has meant the third party .NET toolset has emerged in a different less clumsy way than in Java land.

> "but it's an uphill battle against Oracle's current position"

Eh? Java isn't even open source in any meaningful sense. Just look what happened to Google/Android when they mistakenly thought Java was open source.

I'm not sure what this so called "maturity of toolset" for Java really is either. Most of it is just piles of garbage libraries and frameworks to work around fundamental flaws of the language, and/or to continue pedalling the broken enterprise styles of OOP and SOLID bandwagon onto yet more innocents.

> "the amount of skilled developers any employer can pick from."

Eh? Ever tried picking a good one from a batch of Java Enterprise devs? It can be a costly exercise. There is almost nothing to distinguish them, that is the problem. Because they're all just Gang Of Four Do-Repeat-Yourself-But-Claim-Not-To code monkeys.

Strongly agreed on most points, C# has been kicking Java's butt in language tech for a long time. Java's support for generics and lambdas continues to lag C# by a large distance... Java 8's .stream() is a horrible substitute for LINQ extension methods. Nothing in Java 8 threading is remotely as good as TPL. And of course, there are still no general-purpose continuations or something like C#'s awesome async/await outside of a few very narrow cases.

On the matter of the toolset, let's call it a draw. Visual Studio is IMHO vastly better and more reliable than Eclipse or IntelliJ. Java has a longer and richer history of good third-party tools with Apache, the Maven ecosystem, etc., which are still ahead of NuGet and its siblings. I think Maven still gives the edge to Java for dependency management, building, and packaging, although it takes a long time to get into its mindset. It sure is nice to have the same IDE and same build process across Windows, Linux, and OS X development environments (I use all three during the course of a day and it helps keep the build honest).

Now, the runtime and hosting... I can't say enough good things about being able to throw together executable-JAR docker images with Java. On the other hand, I'll take IIS over other web servers, given the choice. CLR vs. JVM is a tough call... the myriad versions and OpenJDK vs. Oracle JDK licensing fracture are not helpful for Java. On a technical basis CLR and JVM have rarely bitten me often or badly enough to produce a clear bias--provided the code is sound and there's _no_ _JNI_.

Whether JNI's awfulness is really a feature is a discussion for another time...

I always felt Java's strength was the runtime. Java can run on so many platforms. Compare that to how many CLR implementations there are. This is one of .NET's biggest failings, though this is being rectified by MS when the open sourced the runtime.

You're right and being 20 and more years old, it has so many optimizations that are making the JVM damn fast. Scala takes advantage on many of these optimizations and results are impressive. I think Java as language is failing in the implementation of new concepts, being quite late compared to other languages not running on the JVM. If C# will improve the general performance and stability of CLR, already having the best IDE ever made, they can easily compete and even win against the Java-World.

P.S. I worked with Java (now only Scala) and C#, so I have experience with both languages/envs.

MS open sourced only a certain parts of dotNet. Important legacy parts like WinForms are closed source.

As they should be. These aren't the UI abstractions you are looking for...

It's arguable whether Winforms, WPF, and other parts that are very heavily Windows dependant bits of the .NET Framework are that important for open source development.

Even if they did open those, they're of very little use outside Windows platforms without a huge amount of work to remove how tightly they bind to the windows APIs. There's much better alternatives if you want to do UI cross platform (or just 'not windows').

Interesting that you rate Java higher in maturity of toolset given that C# has Visual studio + Resharper which many believe to be the best IDE experience out there for OO development.

Resharper is made by Jetbrains. The flagship product made by Jetbrains is IntelliJ, a Java IDE and probably the best IDE money can buy. It is also and the thing which inspired Resharper (Jetbrains itself was called "Intellij" previously).

Now, if on top of the IDE, which is at least on par with VS + Resharper, you add things like build tools, project management tools, testing and code coverage tools, Java is basically the Godfather. xUnit, including NUnit, comes from Junit (Java), Nant was inspired by Ant (Java), Nuget was inspired by Maven (Java), etc.

Only by people who don't know better. Netbeans is a better IDE than Visual Studio.

Well MFC C++(mostly C) and .Net are as similar as C++ and Java. MFC C++(mostly C) is unmanaged legacy code and .Net is managed code.

Scala compiles too slowly. Otherwise, it would be more popular. In general, I think it's a bad idea to make these sort of excuses. Java as a language needs to better compete. The Perl community, for example, used to diss Python by saying CPAN gave it a huge advantage. Perl lost momentum and all the kids now use Python. C# can be used with Unity, for instance. Gateway drug. :-).

> Scala compiles too slowly. Otherwise, it would be more popular.

For day-to-day Scala development incremental compilation etc. mean that a typical build in my IDE takes about a second. I think it has more to do with Java being the default/official language for the JVM (and the Scala learning curve). Similarly, F# is a great language, but C# has always been seen as the default go-to language for the CLR (VB.NET anyone?).

VB.NET has a certain utility as a terrific indicator of whom to avoid...

Scala 2.10 compiles our ~150 file project (which has some seriously big files with lot of implicits in them) in about 15-20 seconds for me. Incremental compile times are typically 1-5 seconds. And this all on a laptop from early 2011. Indeed, this is slower than Java or C#, but nothing terrible. Running any test suite takes much longer.

I am incredibly psyched for Tuples, Pattern matching, Algebraic data types and Nullability Tracking (four of the most-likely list)!

I mean, to be fair, these are all things that Haskell offers me, but more languages getting these can't hurt! Good steps forward! Now, all I have to hope for is that the nix support for .NET becomes more robust so I can actually code in C# on platforms that I care about supporting ^_^ (Note: this is not meant as a slight towards Windows, I just prefer working with / coding for nix).

Regarding Pattern Matching and Algebraic data types, I am not sure that they are implementing both of these ideas to the fullest extent that you would find when we typically refer to these items in existing functional languages.

For example, Pattern Matching. From my glance it appears a nice way to assign bindings from an expression, but I didn't see anything about guards. Also, any kind of pattern matching without the ability to check for exhaustiveness defeats the safety they provide usually comparable with inheritance.

Which comes to Algebraic data types. All I know is there are several boxes you must tick to really call it "Algebraic data types". I am not sure all those boxes are "ticked" here. This question came up when swift introduced "Algebraic data types", but no-one could get recursive ADT's to compile. it does look like this proposal allows recursion, but there are other things i'm sure are at play such as how it works with generics.

Ahh, that's too bad to hear. I read a little bit of each proposal, but was drawn back to work once a build completed and did not have a chance to exhaustively explore each one.

Well, I hope that they manage to fill out each feature a little more. Fingers crossed!

reading a bit more, they did mention in the "optimizations" section "Closed hierarchies enable the compiler to detect when a set of matches are complete". I really hope they don't leave this to an optimization, and make it a core part of the feature!

It is kinda little irony. C# become more like sun in 90s and java become more like microsoft in 90s

C# the language has been ahead of Java the language for years now.

Yups. That's exactly what I was driving at with my comment.

That's a very useful set of features, glad to see more of the features I'm used to in Scala (although obviously not the first to have those features) showing up in C#.

It's still a bit of a stretch to say that C# has "overtaken" Java in general, or to read too much into Microsoft's moves (they haven't open sourced any of their main profit-generating software (SQLServer, Windows etc.), just enough to earn a bit of street cred. amongst developers).

In terms of features C# is far ahead of Java, but many Java developers simply don't care as C# is far from being widely established and broadly used outside of Windows. Even on the JVM many Java developers will use Java the language as it's the standard, rather than because it is a fantastic language. Those who do care have moved on to Scala, Clojure etc. We've relegated Java (the language) largely to legacy status, but rely heavily on the Java ecosystem (JVM, IntellJ, java libs etc.).

Middleware is the most important strength of Java.

> the level of transparency to Java's ambitions

They are fairly transparent if you ask me. Here are a few examples[1][2], there are more to be found on the openjdk page

Additionally, scala already has some of the features proposed for the inclusion in C# in the future.

[1] http://openjdk.java.net/jeps/0

[2] http://openjdk.java.net/projects/panama/

I don't know, dont' get me wrong these are all nice features but it's nothing that I think will drastically change or improve the way I code (like for instance LINQ or generics did). With the possible exception of null tracking (no pun intended). Making testing and eliminating bugs easier is the one area that really could benefit from a grand new concept or methodology.

I was really hoping for better integration of tests and pre/post conditions

There are only so many LINQ's in the history of programming or any programming language. It is unlikely that anything added to the language, at this point, would have such an impact.

On testing and pre/post, this is an area around which I am quite sympathetic. However, I'm ambivalent about the unintended consequences of fleshing it out too far. It seems that by encouraging testable code, I get much of the relief to my pain. That said, it's a cat and mouse game for things like async-await features... followed by support for testing said language feature.

You sound like an US patent clerk in the 1901's ;) Look at Rx for example, it isn't needed in as many applications but when it is its as revolutionary as LINQ was.

I think reducing friction and increasing productivity is really important, it's not as sexy as some of these other features but it makes real difference in big projects.

I'm getting a little worried about the async-await and task methodology. It's true that they've made a lot of that kind of programming much much easier, but it also means that orchestration is cluttering our code. It seems that now that we've elevated the level of abstraction it should be possible to get rid of it (more or less) by being more declarative in our intent and structures. We're programming on at least one layer below what we should.

Unfortunately I think that might require so large fundamental changes that you need a new language. Many might say, what about F#? While F# is great for certain more algorithm oriented solutions for me it never seemed to quite fit the paradigm of certain applications and enterprise systems.

I think in the end there's a skeleton of a next generation language embedded in what c# has become. If we removed some of the crud and used LINQ style syntax as template perhaps we could take parallelism, asynchronicity and productivity to the next level

Generally agreed.

PL's are a part product of all of history of computing, but a bigger part is a product of the programming Zeitgeist. It's better to be a young language than to have matured 15-20 years already. Certain syntactic or other choices bite you inthe ass in a new zeitgeist. When I saw Java's implementations of lambda stuff, I cringed a bit. Java's friction in generics, due to choices made about typing, also made me say, "Ouch."

I like to think I've matured out of the language and platform warrior mode enough to yield more objective consideration beyond my most-used and favorites (and are they favorites because they are most used or because they are so good?).

F# has given C# a nice boost in the juicer, but certain earlier choices are ossified and make later adaptations more challenging or, potentially, near impossible to do, do well/right.

I like that C# is going across OS's, but were also entering the Age of Containers and there are implications, opportunities, and challenges we have barely started considering.

I don't know what the future holds, but I know there will be curly braces and that tabs will win the day again... ducks

This is pretty amazing...its almost as if the Roslyn devs are all fans of F#. Even though I'll probably still end up using F# the majority of the time, better interop with C# sounds like a really good deal.

Or they're just converging on decent designs over time. Just like fixing their lack of optional parameters (although the implementation is still a broken compile-into-callsite C-style method). Just like adding more support for mutability. Null references were a mistake, and now, after countless thousands of lost hours due to them, they're starting to patch it up. But it's probably heavily inspired by people on the same platform getting radically better feature support by a much smaller team.

Or as Don Syme said (I think it was him or perhaps SPJ), features get done in Haskell, trickle into F#, then into C#. Even generics was in F# before C#.

And the current proposal on records does not appear to be compatible with F#. I'd give a somewhat higher probability to the F# compiler changing to deal with C# than vice versa.

I think people mentioned this already, but the first four bullet points make it look like there's a strong interest in getting C# closer to ML :-). Nice!

Java the language may suck, but the JVM rules. Microsoft's idiotic stance to make C# and the CLR windows only for the last 15 years basically made it largely irrelevant outside of pur MS shops. I program C# for a day job and it doesn't matter how awesome the language is, because the entire eco-system until recently was hampered by being MS-only.

We are slooooooooooooooooooowly seeing the ship turn around with NuGet, and many MS-build libs appearing on Github and the CLR and compiler going cross-platform but it's 15 years too fucking late to matter.

Java and the JVM won.

Haha, no. In fact there is plenty of room for both. On the bright side you can go to just about any city in the country and find a job in either Java or C#/.NET development. Both are very widely used.

Interesting. My experience is that Java jobs outnumber C# by almost 3:1. Not only that, but the type of job is also vastly different.

C# seems to be used in (mostly) slow-paced, slow-moving, conservative environments based fully on an MS stack top-to-bottom.

Java jobs seem to be all of those above, plus a lot of start-ups and places like Amazon/Google. Not many C# jobs at Amazon/Google besides some public facing client API; there's no MS tech in their actual back-ends, that I'm sure of.

And C# could have absolutely destroyed Java. It was already better when it was introduced and the Java eco-system hadn't acquired enough steam. But MS "wisely" decided to keep it Windows-only as if somehow C# was so awesome that it would make companies switch from Linux server farms and back-ends to Windows servers just to be able to experience the joy and glory that is C#.

Nope.

Honestly I don't think the goal of .NET was ever to convince companies to switch platforms or to compete with Java (replace it on the MS platform yes, but not dominate it as you seem so obsessed with). It was to provide a compelling development story on their platform for not just server side development but also client side (where Java completely fails).

It may be very true that Java jobs outnumber C#. It doesn't change the fact that it is pretty easy to get a job in either, and both lead to generally very boring jobs. I currently service .NET clients in the above $100/hr range and have had no trouble finding work from a rather remote city also (it's no Seattle or Silicon Valley, that is for sure).

But I don't understand your obsession with "destruction" and "domination". There is plenty of room in this world for lots of technologies and they don't have to all be focused on destroying/replacing each other.

Well, yes, sure I guess there's room for both but they're also similar enough to where maybe a focused effort on one of them for quality libs/middle-ware would have produced better overall results. But maybe not.

But yeah, both are kind of boring, haha. I'm in the process of transitioning to more startup-friendly technologies and languages as it's more fun for me to work on those kinds of projects.

And awesome work you have there - $100/hr? Lucky!!! Consulting work?

It's "awesome" ... yet still many years on behind. These are the kinds of things that should have been in v1 or v2. Things that F# got right from the get-go.

It's great if you have to work on projects that are stuck with C# (but can freely use the latest compiler).

Given how much MS has invested in Haskell, and how little/late they use that technology to their advantage has made me wonder many times what drives their R&D budget.

Non the less: cool "new" features in C#, and thank you very much MS for investing so generously in Haskell!

Do remember, they also have F# which is very much a functional language (in the style of SML or Ocaml)

Well remember that the F# team had generics before C#, and they are the only reason the CLR shipped with real generics in v2. So that's a pretty big return, seeing as real generics was a flagship feature difference between the CLR and JVM.

Do they invest that much in Haskell? SPJ's salary, and previously Simon Marlowe's salary. That's nothing compared to what they actually put money into.

It's a very large investment from the perspective of Haskell, a miniscule investment from the perspective of Microsoft.

Couldn't have put it better myself! Thank you for understanding my point.

They still have arguably done more for the language than any other major corporation. Saying "they could have done more" seems a little petty.

Arguably? Almost certainly. That, however, was not my point ...

Let me clarify. I wasn't responding to cies's second line (Microsoft has contributed a lot to the Haskell community for which we are very grateful) but the first.

It would be a mistake to think that from Microsoft's perspective they feel they have spent enough money to even begin to think about extracting some sort of reciprocal benefit from that.

Admittedly my comment was ambiguous.

Let's be humble and call it a big investment. :)

Don't forget that F# was mostly "forked" from OCAML, while C# was mostly "forked" from Java. So yes, F# got some OCAML features, but it got the weird ML syntax as well.

Not only syntax, a lot of the restrictions feel weird for a Java/C#/Scala programmer as well. E.g. functions needing to be declared before you can use them feels like you are coding in C again.

F# probably is a better functional-with-OO-aspects language, but C#/Scala are clearly better OO-with-functional-aspects languages and programmers currently want the latter.

I'd argue that restriction of F#'s is actually a feature. Cyclic dependencies are a real beast to reason about, and I like that F#'s lexical scoping means I need to opt-in to mutually recursive functions with `let rec`.

You're probably right that it feels unfamiliar to Java/C#/Scala programmers, but I enjoy the sense of security that F# and other restricting languages provide.

It started with "weird ML syntax" but they developed a new syntax and migrated to it. It hasn't used the original syntax for a while now.

It has nothing of weird.

I've been using Java for almost 6 years mainly with IntelliJ and I've heard many times that C# is better than Java. Recently I've got chance to work with C# (on Visual Studio 2012 with Resharper). Oh boy, I don't know how to express my feeling, but in one sentence "It's just suck to the core".

I completely agree, as a language C# is more rounded, but as far as the ecosystem and tooling concerned its literally nowhere near to Java.

That's funny to me because my experience was the exact opposite. After an undergrad experience of Java, C, C++, Python (at least from the OO/C-likes) on *nix systems, trying C# 5 w/ VS2010 + ReSharper was some kind of transcendent experience.

I LOVE the language and I've found the entire ecosystem fine. There are some corner cases for some more advanced systems level stuff, but I've yet to be unable to do something I needed to.

Java feels like a clunky dinosaur to me now. But hey, different strokes for different folks.

I have a similar background and my experience was the same.

It's interesting that you view things that way, because my opinion is basically flipped. Eclipse is an absolute displeasure to work with (the default IDE for most Java programmers), and don't even get me started on AbstractFactoryFactories and Beans, insane unreadable stack traces, the 1970s look of Swing GUI, JAR hell (classpath issues), Maven not working in offline mode, Applets and their manifest files and signing issues, etc.

Maybe I've just worked with too much enterprise-y Java code which always tends to be a cluster. Anytime the acronyms "SOA" or "ESB" enter the mix I start fearing for my sanity. But even Android programming seems to have more quirks than WinPhone development, although I'm comparing my experience w/ ICS 4.0 to WP 8.1 here.

What annoyed you about C#? I'm curious where you think the ecosystem or tooling is better than C#.

As I mentioned, I was using IntelliJ mostly and I'm aware of those warts with Eclipse as well.

> "It's just suck to the core"

You are not helping anyone out here. Why does C# suck for you?

I find the tooling for C# projects using VS as a very nice feature set. Look at what VS supports today. Grunt, npm and bower are supported by VS out of the box. Also, nuget package manager has saved me many DLL hell problems that could have occurred without it. VS also supports many third-party extensions and tooling, which is what makes me thinks it is one of the best IDEs out there.

I'm disappointed by your comment because you didn't provide any details on how "It just suck to the core". Guess you only wanted to trash-talk C#?

May be its just me. But since you asked:

1. On the same machine, I find VS 2012 was dragging (but memory was always hovering around 400MB)

2. Couldn't stand for .csproj style solution files (may be I'm spoiled by pom.xml, but its way better)

3. We as a team working on the same project and merging those .csproj files are literally pain in the ass.

4. The windows layout in the IDE is quite un-intuitive. You should see how IntelliJ manages all those windows.

5. The disconnected namespace and folder structure is another pain.

6. Related to the point 5, looking the source code and namespace imports, I can't see from which file those Classes are being "imported".

7. Maintaining and adding references is PITA compared to Java projects that uses maven.

Again, as I clearly mentioned, C# as language is better, but the tooling and ecosystem are not.

Its not always about the better language, Software is mostly written once, but read, refactored, maintained thousands of times by dozens of people. So the tooling and ecosystem has its place, so as the backward compatibility.

1. Resharper can sometimes really slow things down. Turning off Solution Analysis will often help with that. Also, I seem to have much better performance with VS 2013.

3. Did you try adding "*.csproj merge=union" to the gitattributes? I have never had a csproj merge conflict since adding that.

4. That really comes down to a preference. For me I feel the IntelliJ style keymap is better, but I would take the window layout of VS over WebStorm (just naming one i use often) any day of the week.

5. If your team decided to not have namespaces match the folder structure, thats their prerogative.

6. "Go to Declaration"?

7. NuGet has solved this problem for me.

But you're right, the C# ecosystem is certainly not perfect. Most people seem to agree that msbuild is frustrating to work with. And I really really wish csproj had wildcard support for including files.

csproj's do have wildcard support, just no way to create them through the IDE: https://msdn.microsoft.com/en-us/library/ms164283.aspx

Thanks for the pointers.

> literally pain in the ass

this is an interesting claim

Yes, it is!

Regarding a couple of your points: Point 1. You might want to take a look and see if Resharper is to blame. I ultimately got rid of Resharper. I found that most of the features I used were already in Visual Studio (e.g. ctrl + , instead of ctrl + t) and keeping Resharper with VsVim was more trouble than it was worth. Point 3. We use TF, which I am not a fan of, but it automatically resolves the conflicts when we check in our .csproj files. The bigger issue we had (and still have) is getting people to check in the .csproj files and doing it correctly.

I understand what you wrote about csproj (no 2 and 3). Maybe this is why asp mvc next gen use new project file format

Just like all other comments ... total opposite for me. I love visual studio. I did some android development few months ago, I tried eclipse and Intellij and I missed VS2012 badly.

I've been doing Java development for over a decade and have dabbled in the C#/.NET ecosystem a handful of times. My knee-jerk reaction is always sort of similar (and I write posts about stuff I miss [1] about what I miss), but I don't actually think it sucks at all - it is mostly just about getting used to a new environment.

I'd fully expect someone coming from a .NET ecosystem to have a similar reaction, and the truth lies somewhere in the middle: both of them have their things they excel at and things they are less good at, but a lot of it comes down to what you are used to.

Even though my gut reaction is sometimes similar to yours, I'd jump at the chance to do C# full-time, because I think there is some really nice stuff in the language and the platform seems really interesting once you get past the parts that feel unfamiliar.

[1] http://www.spenceruresk.com/2011/01/visual-studio-2010-a-bun...

The fact that this is so out in the open on Github is pretty amazing - shows how much Microsoft is changing.

Can you imagine the feature list of C# 1.0 being discussed like this?

Yups. They day I read their massive open source release announcements I knew that MS is from now on not the same company it was.

Mahatma Gandhi supposedly said: "First they ignore you, then they laugh at you, then they fight you, then you win." Which I think is very applicable to MS attitude to open source.

Now they have a new attitude: If you can't beat'm, join'm.

First they ignore you, then they laugh at you, then they fight you, then they embrace you, then they extend you, then they extinguish you.

That'll be quite a trick with an MIT license, community promise on patents, and published language specs.

But this is not as new as some may think. The Entity Framework team uses a transparent design process [1] since 2008 and the C# team also opened the design process to the public some time ago. But it is of course getting more wide spread and even more open.

[1] http://blogs.msdn.com/b/efdesign/archive/2008/06/23/transpar...

Improved tuple support would be awesome, it's something I often miss when working with C# and coming from a Python background (that along with a nicer dictionary syntax). The nullability tracking proposal also looks interesting.

Overall looks like C# 7 is going to be awesome even if only a few of these get implemented.

Agreed! I really like the idea of symmetry when calling a method. I have never gotten why we can send multiple values in, but only one value out. And polluting the source code with structs for every method which needs to return two or more values is ugly.

There have been Generic Tuples for a while in .NET... https://msdn.microsoft.com/en-us/library/system.tuple%28v=vs...

Those things suck. Every time I think about using them I always end up just using a dict or declaring a new struct.

Yeah I agree, having to keep in mind what you put into Item1, Item2, Item3 etc really isn't programmer friendly

F# uses them just fine and they don't suck. So perhaps it's just the compiler/language not dealing with them very well?

Edit: OK so it does suck that it's a reference type for even small tuples. But it's not C#/F#'s fault the CLR doesn't do a better job on those kinda things.

F# allows you to break up the tuple immediately, this tremendously aids readability as it avoids introducing confusing names.

    let (a, b) = Foo()

Compared to

    var tuple = Foo();
    var a = tuple.Item1;
    var b = tuple.Item2;

You could consider them equivalent, but conceptually it is faster to understand that a is the first result IMO.

I'm just pointing out that System.Tuple doesn't suck as the commenter was saying. It's just C#'s handling of them.

Given that the proposal specifically mentions using struct instead of class it isn't just C#'s handling that makes it difficult to leverage System.Tuple.

Funny, the BCL folks went with a class and we were assured it was a good decision. Maybe they just need to get their JIT up to date and do escape analysis so this kinda thing doesn't cost so much. (Easy for me to say they should do it...) After using Rust+LLVM I'm accustomed to the idea of not having to pay so much for features.

Which means they suck in C# doesn't it?

Well, that's what out and ref parameters are for

That's what C APIs look like. Sure it works, but it's not pretty. Conceptually, it makes sense to pass in an argument that gets modified (C# ref), but it's confusing and weird to have a parameter that's purely for output.

Except out and ref parameters are exactly zero fun to use. Wheras returning two values is a lot of fun, esp. with pattern matching.

This is somewhat subjective...

I'm not sure I find either more fun than the other.

You are absolutely correct. Perhaps fun is the wrong word. It is however, a royal pain to use the first, and way less so to use the second...That's something I feel I could probably defend in an objective sense.

The problem, and as far as I can tell the reason that they're considering a better tuple return value is that these don't work with async.

The existing tuple type doesn't work well because its members are generically named; and very few people want to make lots of little classes that are only used to pass results from one method to its callers.

Yes, at the cost of forcing the developer to start thinking in pointer semantics. When the language is trying to steer away from that, and suddenly introduces explicit attributes to return to that age, I think there's kind of a conflict polluting the language a little where it wouldn't have to be.

I do believe at least 'ref' should be in the language to simplify C/C++ interop, but I think it they should firmly nudge devs into thinking of that more as a convenience feature for .NET marshalling.

The beauty of tuples is that you get both a useful data type and nicer data passing in one bang with the tuple deconstructors, without requiring pointer semantics. Really a lot to win with just one concept.

Nice.

At what point would it make more sense to just leave c# as it is and move on to a new "language"?

I like all the changes and more importantly I guess I actually understand the intention and the need for them, at same time I'd like to question how all those actually fit into one language...

I understand MS has a very strong record for support of legacy software, systems etc. So for sure on point would be to still "support" legacy C# code and allow for more modern paradimes in the same language, but given all the other .net languages and the interoperability provided: what is the drive behind pulling it all in into C#?

C# is dove-tailing lot of F# improvements/accomplishments. So if you want to use these features today and not wait till C# 7.0, its already time to code in F#.

Branding and recognition. Microsoft wants to be able to say C# is the top 5 most used programming language. Not that they have 10 different languages in the top 100 used ones. C# is the flag ship and there shouldn't be any question whatsoever which language you should use if you run the MS stack (unless you have very strong desires for something special, like F#). Splitting the language into a new one would just segregate the community and you risk ending up with the python 2vs3 mess.

Also consider working in enterprise and asking your manager if it's ok to "change language" from C# to MSNEW#, vs doing a "minor update" from c# 6.0 to 7.0. Even if MSNEW# was backwards compatible and C# 7.0 wasn't, i imagine the answer on the second question to much more likely get an ok.

This has no been the case historically, I'm not sure why it would be now. Why would ms invest in languages like vb.net and f# if so? Choice of languages that target the CLR has always been a selling point even though c# is dominant.

These are pretty small changes on the whole, no? Adding tuples? A new datatype here and there? That's pretty standard for what's put into new language versions. And the work to port to a completely new language is quite hard; the work to update a codebase to these changes seems tiny in comparison to even rewriting in F# or Java, let alone something radically different (say, a lisp).

They're far too heavily invested in C#, and good alternatives, like F#, are viewed as too difficult for the majority of their customer base to deal with.

They can add these features, let less ... able ... customers argue over "var" and what they'll use, while pleasing other users. C#'s seriously annoying to code in due to it's statement-oriented nature and lack of basic features.

Additionally, because libraries take dependencies on C# compiler implementation details, other languages do not interop as seamlessly as the .NET/CLR concept would have us believe. Looking at things like the precise output of lambda expressions, or all these APIs that take object, then read the properties as an argument list (which should just take a list of tuples instead).

Also, just imagine the fallout of "Microsoft abandons main .NET language!"

I think your statements are a little too general, even though you might have a point here:

What does it tell about the the real life "interoperability" on the .net platform, when every language needs all the features? My guess would be: the technical "possibility" is there yet the eco-system as a whole of day to day developers, technical managers, project life-cycles and real life products with some legacy heavily bends towards single application development language even though developers mostly already use several other languages like for scripting or sql, html, css, javascript etc.

Seriously annoying? If you don't like it, don't use it and comment on other things. There's plenty of people that think it's one of the best languages available today.

Yes, it is very annoying. It's overly verbose for no good reason. Well, if you count internal compiler complexity a good reason (that's why fields don't have type inference according to Eric Lippert, though they still haven't fixed up that inconsistency in Rosyln it seems).

Plenty of people think C++ is a good idea for common apps. Plenty of people think node and JS are awesome. Plenty of people loved Flash. What's your point?

Because C# is so popular (like JS), its questionable decisions ripple all over and affect people even if they aren't directly using C#.

Man these guys don't stop. They haven't even released C# 6 and now we're discussing 7.

With the "strong interest" features and type providers, is there any reason left to use F#?

Also, I don't see why array slicing would require CLR support. That would be a welcome addition.

I think there are several reasons to prefer F#. First of all, you can use all of these features in F# today, but when's C# 7 going to be available, and will the "strong interest" features (not to mention type providers) all make it?

But more fundamentally, adding features like these to C# is awesome, but there's no way to remove now-obsolete patterns without breaking legacy code, so it's still possible to shoot yourself in the foot in many ways that you can't in F#.

Some other authors have also addressed this question recently: [1], [2].

[1] http://fsharpforfunandprofit.com/posts/is-your-language-unre... [2] http://blog.ploeh.dk/2015/04/15/c-will-eventually-get-all-f-...

I would only use F# if I already knew it. Otherwise it just doesn't give any killer features anymore to justify the effort needed to learn it. I don't consider things like no nulls and default immutability a killer feature. Also there is just a handful of F# jobs and they don't offer an outstanding salary for knowing F#.

F# async and parallel programming (Async.parallel, Agents/Mailboxes, Array.parallel.map, etc) are vastly superior to C# right now. Every latest C# iteration has repeatedly borrowed everything great from F#, that should be a sign alone that F# has tons of killer features (and continues to be ahead of the curve).

I picked up F# in about 3 months by reading a few books, then refactoring a C# library into F# (this taught me a lot of the interop quirks), and then doing a full project in as much of the F# idiomatic way as possible.

As far as jobs, I don't know anyone who uses the .NET stack that considers themselves strictly an "X" programmer. I've never used VB on a project, but I'd be pretty confident I could consult on a large VB project based on how much C# I've written. Mixed projects are really the best of both worlds anyway, learning F# will improve your C# simply because it teaches you new ways of reasoning about your domain.

If C# 7 ends up implementing Tuples, pattern matching, ADTs, etc... those are all bread-and-butter of F#, might as well learn how to use them ahead of time.

Parallel.x is already implemented in C#, I don't care who had it first. Akka.NET covers the actor model (note that Mailboxes do not support distributed scenarios). Those are not killer features (at least anymore).

I already improved my C# by reading about F#, there is nothing magical about deconstructible tuples, pattern matching and ADTs that needs too much time to learn. It's the rest of the "succinct" ML syntax that puts me off. That and lack of ReSharper.

Dot net framework team are very fast.

When i want move to RoR, they provide asp mvc 3 include EF migration.

When i want move to js, they provide async keyword.

Now when i want move to f#, they provide it all in c# language

F# is still less verbose and does far better type inference. I wrote teh same program in C# and F# (a few hundred lines of C#) and it F# had only 1/20th of the number of type annotations required.

Also C#'s statement-oriented nature just makes things ugly. Stuff like:

  Bar x;
  if (...) {
    var a = frob();
    x = Foo + a
  } else {
    x = Baz
  }

That's much nicer as a sub-block expression. It also allows you to scope things better. F# allows you to shadow variables, which comes in handy a: to avoid using an "old" variable, b: with nested lambdas.

F#'s Active Patterns are pretty damn nifty. F#'s also has deeper support for immutability. Even simple stuff like optional parameters C# gets wrong.

Overall, it's like using vim. There's some big things (like macros) that really help, but a ton of small things really do add up. I find it enjoyable to write in F#, I can be concise and write what I'm thinking. In C# I've got all this extra boilerplate that doesn't benefit me.

There's no doubt that C# can try to close the gap and certainly provide huge improvements from where they are today. But their overall approach seems to get the biggest "bang for buck" while confusing as few of their users as possible. And elegance/consistency be damned[1]. It's not a bad choice for certain projects (I dunno, maybe writing an ERP where you're adding all sorts of boring rules and need to be able to throw interns and get a known-quantity of quality) but it's hardly terrific if you've got control over your developers.

1: Look at C#'s duck typing, or type inference, or lambda expression support - they were forced in for the LINQ use case and nothing more.

> Also C#'s statement-oriented nature just makes things ugly. Stuff like: [code]

I am not following what is bad about the example. Could you reproduce that same code in F# or whatever you're saying is better. It might help explain what you're getting at.

I think OP has something like this in mind:

  let x =
    if ... then
      let a = frob()
      Foo + a
    else Baz

`x` is never in an invalid/uninitialized state, and it's immediately clear exactly what code contributes toward computing its value.

Somewhat related, you can also define nested functions in F#, which is very convenient and tidy. No need for a pile of one-off private helpers at the same syntactic level as your public APIs - just tuck them inside the members which need them.

You can define nested functions in C# in for form of lambdas or anonymous delegates. Admittedly, it's still not quite as pretty as it could be because we don't get to use automatic type propogation (e.g. the `var` keyword).

Of course you could do many things to make C# closer to F# (I've devoted a whole library to coercing it [1]). My preferred approach would be:

    var x = ... 
        ? Foo + frob()
        : Baz;

Or to be truer to the original (using my lib):

    var x = ...
        ? map(frob(), a => Foo + a)
        : Baz;

But the idioms of the language mean that in the real world you see the ugly version with the associated risks of uninitialised variables. I applaud the C# team for the direction they're taking. I suspect C# will end up closer to Scala than it will to F#, which isn't a bad niche for it to be.

[1] https://github.com/louthy/language-ext

Agreed that C# will probably end up closer to Scala. For instance, it's already more straight-forward and elegant to simulate and use type classes/traits in C# than it is in F#.

C# 6 isn't even out yet, and it's not like F# is mandated to stand still and add nothing.

No but C# gets a lot more budget and marketing. For a long time F# was pitched as an oddity for science and finance people. Instead of being pitched as "essentially better in every aspect except tooling".

And maintaining your tens of thousands of lines of existing C# code...

If I wanted to learn C#, not knowing any other compiled languages (but knowing PHP), where would I start? Another gotcha: I'm on OSX, and would prefer to learn C# from the standpoint of CLI first, then GUI components.

I think one of the best places to start with C#, if you have prior programming experience, is Jeffrey Richter's book "CLR via C#". I think it's a great book because it teaches you the specifics of the CLR as you are learning the language. You'll come away from it with a much deeper understanding of the C#/CLR system than you'd get from starting with a regular tutorial; C# is a lot like Java in that learning the language is only half the battle, you also need to understand the virtual machine.

Use mono [1]! Then write your first console application [2]. Or read [3] to learn about the language. And then maybe check out some trending github projects [4]!

[1] http://www.mono-project.com/

[2] https://msdn.microsoft.com/en-us/library/k1sx6ed2.aspx

[3] http://learnxinyminutes.com/docs/csharp/

[4] https://github.com/trending?l=csharp

I do all my development on my Macbook, inside a Parallels Desktop virtual machine running one of several builds of Windows (XP, 7, 8, 10).

You have two problems to tackle, as I see it: 1) building and environment 2) learning the language

1. Download Sun VirtualBox (free). Set up a virtual machine with your favorite build of windows (windows 10 preview is free) @http://windows.microsoft.com/en-us/windows/preview-iso

Install Visual Studio Community edition. You could learn C# from the command line, but this gives you a great IDE and debugger: https://www.visualstudio.com/products/visual-studio-communit... In the early days of learning c#, you'll value that debugger.

2. Language. Learning the language in isolation isn't very useful -- it's the dotnet libraries which give the real power of course. Everyone will have their own favourites for texts, but the one I used for myself and my teams over the years is "Learning c#" by Jesse Liberty. The first version, c#1.0. (IMO, the later books which were co-authored were not up to the standards of the first one; they tend to muddle and wander. Most of what you learn will apply, and once you feel like you've got your sea legs, you can grab a tutorial for an up-to-date version (c#6) and learn about the changes.) http://www.amazon.com/Programming-Building-Applications-Jess...

Best of luck to you!

I would highly recommend this book: http://www.amazon.com/5-0-Nutshell-The-Definitive-Reference/... . The authors really know their C#. I have the pocket edition of this book and have looked at the full version, and it looks like a much more in-depth version that would be useful for someone just starting out.

I have no experience with C# on a mac, but I know it is possible. See: http://www.mono-project.com/docs/about-mono/supported-platfo.... You'd probably have pretty good support for anything on the CLI, but might run in to issues if/when you make the jum pto GUIs. Good luck!

I wrote a similar answer on stack overflow a while ago. I would recommend Parallels to run windows and Visual Studio if you can. The community edition is free and is basically the pro version of it.

The main reason why you want to use VS is because if you just want to learn the language most of the resources out there assume you're coming from Visual Studio/Windows. There's enough crap to worry about without trying to figure out issues with your IDE/compiler/etc.

You have a couple options:

1) Code up some simple C# code in a text editor (sublime) and then compile it using the mono c# compiler.

2) Run Windows on Parallels and download visual studio community edition.

Folks are working on a CLR that will run on Darwin and the core framework as well as an alternative to Mono. This won't be released until later this year though, and tooling is still TBD.

Sublime? Parralells?

Why not just Monodevelop[1] instead? It's an open-source .NET IDE. Although not on par with Visual Studio, I doubt anyone would expect that anytime soon.

For a beginner it will probably be very relieving having Intellisense and code-completion, not to mention it will encourage exploration of the APIs in a much more playful manner than trying to read MSDN docs.

If you're going to start getting into C#, don't start with your hands tied behind your back. Get the full package!

[1] http://www.monodevelop.com/

I recommend this book: http://www.amazon.com/-/dp/0321877586

It focuses on the language, not any specific implementation. The examples all use the command-line compiler, not Visual Studio. So you would be able to use the Mono Development Kit.

Start with Mono. The .NET platform is a beast to "just sit down and learn". I've been doing .NET since 2002.

The one thing that worries me about the tuples proposal is it would be confused with System.Tuple. The proposal seems similar to Python's namedtuple, so if possible, perhaps they could add some new .NET type (System.NamedTuple?) and use that?

Not sure to get the Tuple (#347) ... Why not use an anonymous type or the already existing Tuple class ?

Anonymous types can't be returned from a method. Well, they can, but not with any kind of safety (casting to object, or dynamic). Using tuples is all about representing a type by its 'shape', not its name. With anonymous types there's no shape declaration; but I could imagine that it would be useful for C# to allow implicit casting of anonymouse types to tuples (where the shapes are equal).

The great thing about .NET is that it has a ton of great features but never feels overwhelming or slow.

More features == better language. A tried and proven strategy.

It's worked really well for C# so far, so perhaps it's only one of meany factors which determine the success of a language.

Are you willing to say the same for C++?

Yes.

Most of the C++ warts are caused by the need to be copy-paste compatible with C, expectations of C developers being lured into this new language and be a drop-in compatible replacement for C tooling.

"The Design and Evolution of C++", http://www.amazon.com/The-Design-Evolution-Bjarne-Stroustrup...

If the entire C++ codebase I worked with was mostly C, my job would be so much easier. I think the 2000+ page C++ manual proves my point.

Reply on news.ycombinator.com