* 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.
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.
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?).
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!
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.).
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
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.
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#.
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!
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.
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.
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.
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.
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#.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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#.
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].
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.
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.
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.
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#.
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".
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]!
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...
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.
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.
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!
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.
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?
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).
And are you a 20 something maladjusted male? I'm just trying to figure out you work? You're kind of wasting people's time because you have have too much energy and nothing better to do. Personally, I would try to refocus and shoot for a more worthwhile goal.
The most important principle on HN, though, is to make thoughtful comments. Thoughtful in both senses: civil and substantial.
The test for substance is a lot like it is for links. Does your comment teach us anything? There are two ways to do that: by pointing out some consideration that hadn't previously been mentioned, and by giving more information about the topic, perhaps from personal experience. Whereas comments like "LOL!" or worse still, "That's retarded!" teach us nothing.
Empty comments can be ok if they're positive. There's nothing wrong with submitting a comment saying just "Thanks." What we especially discourage are comments that are empty and negative—comments that are mere name-calling.
Which brings us to the most important principle on HN: civility. Since long before the web, the anonymity of online conversation has lured people into being much ruder than they'd be in person. So the principle here is: don't say anything you wouldn't say face to face. This doesn't mean you can't disagree. But disagree without calling names. If you're right, your argument will be more convincing without them.
You used the n word in a racist manner to play games on HN. I simply pointed out that this sort of behavior on HN fits a pattern. I'll leave it to others to figure out a "civil name" for it. I certainly didn't say anything that I wouldn't say in person, or wouldn't mind being reprinted a decades from now.
Well he didn't really use it in a racist manner, as that's all his post contains; unless you're implying that any use of word is inherently racist. I guess if he put it in quotes it wouldn't be? (Use vs cite)
Instead of reporting your bad behavior, I tried to explain it. You can't fix a problem without understanding it. You are the way you are for a reason, and you're probably not that different from other people who fit your profile. Shouldn't we try to understand hate, for instance? Making people social outcasts or deleting accounts for online bullying is not a great solution.
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.
* 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.