Hacker News Reader

Hacker News

Comment by cies | Hacker News Reader

Full thread

cies

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.

View on HN

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 :)

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').

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.

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.

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.

> ".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 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

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

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

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)

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.

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

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.

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.

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.

It has nothing of weird.

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.

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.

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.

> 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

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.

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.

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.

> "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'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...

Reply on news.ycombinator.com