Not attacking you opinion at all but I'm a little shocked that someone would have this opinion, I work at a Java shop (using java 8 but I'm mostly now on the node.js side). Java 8 really doesn't have any features that are better than C#'s. Java 8 is missing some pretty major ones, like type inference, automatic getters/setters, LINQ, function passing support that's not brain dead, and a number of of things that make dev life SO much better.

While I prefer C#'s delegates/lambdas, there has been an occasional time I've wished for the ability to construct a full instanced object in that case - Java's anonymous inner classes are brilliant at this.

Likewise Java's OOP enums (basically singletons) are something I miss too.

That's a few small features I notice missing when I switch to C#.

Plus, in general I find there's a difference in style. C# libraries tend to be more pragmatic, following on Microsoft's heavy use of reflection and stringly-typed stuff. Not much OOP navel-gazing.

Java, on the other hand, celebrates OOP to a ludicrous extreme.

Also on the community, C# has been working very hard to develop the kind of bazaar that Java has, but they're coming from far behind on that front - far more C# developers restrict them to the first-party tools compared to the Java ones.

Maven, Ant, and Gradle are also in a class of their own. They help making building Java apps universally extremely easy. C# has an annoying amount of complexity in this area, with a lot of things being built into Visual Studio, and therefore Windows only. “Visual Studio” isn’t a fun build system if you’re not on Windows. And compiling people’s libraries from random repositories over github, bitbucket, etc., only to find that it won’t compile because it relies on some old version of a library that you can’t find online and the newer versions aren’t compatible.

Nuget solves the dependency issue. MSBuild has switching from part of the framework to VS to framework to open source. On other platforms there was always csc to compile programs (which is dramatically faster), something missing from the new dotnetcore.

There was also nant and a number of build tools, plus good old make.

Ms is working on this, but it's been slowed by politics. There was an alternative msbuild file called json.project that was happening, but it's since been deprecated in favour of strippinh down the old . csproj format to its bare minimum and cleaning it up for sanity.

They also open sourced MSBuild

> Likewise Java's OOP enums (basically singletons) are something I miss too.

C# guys are working on adding full-fledged pattern matching to the language:

https://github.com/dotnet/roslyn/blob/features/patterns/docs...

and there's a concurrent proposal for ADTs:

https://github.com/dotnet/roslyn/issues/6739

Given the velocity of adding new features in C# these days, these will come sooner rather than later (indeed, some basic pattern matching is already in C# 7).

You might like F#'s object expressions for the cases where a lambda won't do.

I agree which is why I've moved my Android development to Kotlin. It provides a lot of that and works right now on Android

We are doing the exact same thing for our Android development. Kotlin for Android and Swift for iOS.

TBH c# is not enough of an advantage to do a huge migration to the language from java. Something like kotlin (still jvm) or swift (no gc) makes a lot more sense.

Which is why you would use Scala or Groovy.

Or Kotlin but that's not his argument. He's arguing for Java 8. I don't agree that Java 8 is really an acceptable modern language for development. IMO it's painful and god awful slow develop in compared to a host of better languages (Swift, Scala, Groovy, and C# all included but not limited to).

> develop in compared to a host of better languages (Swift, Scala, Groovy, and C# all included

Swift, Scala, and C# are statically-typed languages, like Java, whereas Apache Groovy is dynamically-typed originally -- though static typing was added in Groovy 2, virtually no-one uses it. Dynamically typed languages like Groovy are good for glue code, build scripts, and testing, not for developing actual systems.

The ecosystem is an important factor too. I'm excited to use C# in new projects, but I can't move away from Java without replacements for all of the libraries of external code that I use.

I also think Java is fine. Compared to C#, I find Java code easier to read as there is less magic. I also use Groovy for some corner cases like for example JDBC stuff or metaprogramming. I'm also a big fan of Maven and the development tools for Java, and most importantly the eco-system with rich libraries and frameworks. Is there an alternative for JRebel or Spring-loaded for C# yet?

What magic are you talking about? Various .Net frameworks have silly amounts of magic, but C# itself?

When I started going into C# from Java a bit, there were two things slightly annoying me:

- Class extensions: I saw code examples online that just wouldn't work for me because the compiler told me a certain method of a built-in class wouldn't exist. After I while I found out that the author of that snippet had used class extensions and not bothered to mention.

- The var keyword: While this is sometimes nice for quick scripting or hacking in the debugger console, it opens the door for hard-to-read code.

Those are not necessarily "magic", but potential obscurities that can't happen in Java, simply because Java lacks these features.

> The var keyword: While this is sometimes nice for quick scripting or hacking in the debugger console, it opens the door for hard-to-read code.

I find type inference to be the opposite, generally, because it encourages good naming, and it reduces noise/boilerplate. It also makes writing and refactoring faster (don't have to think about the return types, just the code flow).

The only situation I can even think of where it is a problem is when you are passing something to an overloaded method. For example:

    void DoSomething(MySpecialType value);
    void DoSomething(string value);

    ////

    var result = GetData();
    DoSomething(result);
  

You can't tell which one is going to be called by just looking at that code. However:

* GetData() is probably badly named in this situation

* If DoSomething() does something very different depending on the type passed, it should have different names, not be overloaded

On top of that, this code can also have the same problem without type inference:

    DoSomething(GetData())

> It also makes writing and refactoring faster (don't have to think about the return types, just the code flow).

I see what you mean, but isn't this one of the advantages of explicitly declaring types? If you refactor a method to return a different (incompatible) type, you'll have to touch all affected code parts, possibly revealing uninteded consequences of the change.

Also, I think remembering that autocompletion in VS had some trouble with correct type inference in some cases. But it's been a couple of years, maybe things are different now.

If you change the return type of a method without using var you would still have the exact same problems. That's not an actual problem.

I've used var since it came out years ago and never had this autocompletion problem you talk about.

You sometimes had to explicitly declare a type in foreach loops, but that had more to do with shitty legacy APIs that used abstract classes as return types. Wasn't really var's fault though.

Consider the following scenario:

You have a Toilet object with a method flush.

  var toilet = house.getToilet();
  toilet.flush();

Now you find out that updating Toilet objects is somehow expensive and decide to wrap it into a Cache<Toilet>. Unfortunately, Cache also has a flush method, so there will be no compile time error, but functionality is broken now.

I agree this problem would also occur when using chained calls (house.getToiled().flush()), but explicit types could cover at least some of the cases.

> Now you find out that updating Toilet objects is somehow expensive and decide to wrap it into a Cache<Toilet>. Unfortunately, Cache also has a flush method, so there will be no compile time error, but functionality is broken now.

This has happened to me exactly 0 times since type inference was introduced in 2007/2008.

> If you refactor a method to return a different (incompatible) type, you'll have to touch all affected code parts, possibly revealing uninteded consequences of the change.

If you can refactor your code such that you change the return type of a method such that it returns an object of a different type, which nonetheless implements all of the methods used by clients of your type that accept and return types which in turn accept and return types that line up with the expectations of their clients, etc, etc, without having to look at or touch any of those clients, and end up with something that happily compiles but gives an unexpected result, you need to have a long and hard look at how you're using the language's type system, and why it isn't encoding your assumptions in a sane way.

Your code shouldn't be compatible with a different type unless it makes sense for your code to be compatible with that type. That's what the type system is for.

One single common method is enough if that's the only one used in said context.

Sure, different types shouldn't use the same method name for different functionality, but it happens. And when such a scenario happens, I imagine it will be quite nasty to debug.

The var syntax definitely doesn't lead to hard to read code. It's one of those assumptions people who haven't actually used it make.

99% of the time it's completely obvious what the variable is because you can just look at the right side of the equal sign.

Also, you can just hover over it.

As for the extension methods, they pretty much fixed that in VS 2015, it will now tell you which using statement you need to include.

Extension methods are a good solution to a specific problem.

Do you really think something like this:

Dictionary<string, Tuple<int, List<string>>> foo = new Dictionary<string, Tuple<int, List<string>>>();

Is prefferable to:

var foo = new Dictionary<string, Tuple<int, List<string>>>();

What do you get from the former that makes the eye-pain worth it?

Also, the var keyword is necessary for anonymous types if you want to hold a reference to one. And this is a language feature I sorely miss in Java-land.

Since Java 7 you can use the "diamond operator" in such cases:

Dictionary<string, Tuple<int, List<string>>> foo = new Dictionary<>();

Lombok includes the "val" keyword, which infers the type from the initializer expression: https://projectlombok.org/features/val.html

If you have visual studio it tells you what the var is.

I noticed my post was down voted. I am just sharing information. I don't understand why that merits a down vote.

So, where do I get a version fo Visual Studio that’s open source, and works on Linux? And not just the little text editor VS Code, a real IDE?

For most devs, Visual Studio isn’t a realistic option.

It's called Monodevelop, and it would have taken you 5 seconds to find using Google.

I have a lot of respect for the Monodevelop team, because writing IDEs is really hard, but it is really not an awesome tool for writing C#. (The XS modifications were never great, either. I'd rather write code in Sublime Text because Sublime won't randomly lose lines in its text widget.)

Well they just released a preview for VS on macOS.

Project Rider by Jetbrains is a cross platform C# IDE.

VS Code has some tooling.

etc...

VS on macOS is Xamarin Studio rebranded, which Xamarin has never wanted to port for Linux (despite being a fork of MonoDevelop). I don't see MS changing that.

Project Rider is still extremely green and is not FOSS, nor free as in free beer.

VS Code is extremely limited and the little support it has is for .NET Core only.

I'm right now working on an MVC 5 project on Linux and I have to jump around MonoDevelop and Rider to have a workable dev environment; with the occasional jump to a Windows VM and Visual Studio to make sure everything works over there (it often doesn't).

.NET IS NOT a viable stack for developing on Linux and it's an inferior one in macOS. If you want to do real work with it you have to eat, breathe and live Windows and VS.

If I didn't absolutely have to work with .NET in this particular situation I would've laughed all my way back to a real cross-platform stack.

> .NET IS NOT a viable stack for developing on Linux and it's an inferior one in macOS.

.NET isn't, and wasn't officially meant to be. That's your problem.

I've been working on a .net core web app on my mac exclusively now for the last 8 weeks and have had no problems with it. I do check to make sure it works in full VS/Windows occasionally and every single time its worked without fail, and without a single change. Just pull the code and go. I haven't needed to touch windows but its nice to know it still works over there anyway.

Using VS Code as my main editor. Tried Rider a little yesterday and I'll probably switch to that once its more stable as it has a few more tools for refactoring etc.

So .NET core is clearly what's intended to be used cross platform, and it works great.

Most developers use Windows, where VS Professional (under the badge of VS Community) is free. The set of developers who use Linux and OS X (and I mean, I am one) is not representative of developers of a whole.

You mean most .NET developers use Windows?

I mean most developers, period, use Windows, on a worldwide basis. Most web developers use Windows. Most C/C++ developers use Windows. Most Android developers use Windows. Almost all .NET developers use Windows--but most developers, period, use Windows.

Windows is the de facto standard in most places that aren't chasing the leading edge.

> I mean most developers, period, use Windows, on a worldwide basis.

I’m not sure anyone would agree with that.

Unless you also count designers, and kids who just learnt how to click together a website in Frontpage 2000 as developers.

Especially if you count compsci graduates, it becomes very obvious just how much *nix dominates.

Sure! Unless you have ever, even once, stopped to glance at the overwhelming majority of line-of-business programmers that outnumber your notion of "developers" five to one or more.

But good job with the warrantless and wrong contempt.

> Class extensions: I saw code examples online that just wouldn't work for me because the compiler told me a certain method of a built-in class wouldn't exist.

One thing that VS can now do (as of VS 2015) is tell you where exactly the "missing" extension method is, and offer to add a corresponding `using` declaration for you.

Not sure if VSCode or VS/Mac support that, though. But they are all built on the same code analysis engine, so there's no reason why they couldn't.

Interesting. I wonder what would be your opinion on languages with even more magic, like Swift.

I'm not saying it's a bad thing, I actually like both. It just takes more time to get up to speed and there is more surface of attack for devs to screw things up. That's also what I don't like e.g. about JS: It's so unrestrictive you can do a lot of wild things with it - which is sometimes good but often bad.

Idk about Swift, never used it yet.

I guess you are out of touch with Java.

Extensions methods can be approached via default methods.

Java 9, latest by 10, will get var. It is already on the approved roadmap.

both of these are great tools, but as with many you have tradeoffs. Extension methods give you a way to produce very clean reusable code to extend behaviour of classes. Downside is you do need to bring in the extension method class (not a big deal).

Java is a shitty language exactly because they don't put in things like these out of fear that people don't know how to use them.

Java has default methods on interfaces instead. It's their take on the same issue, in a way. They considered the fact that with C#'s extension methods types not owned by the developer can be extended (as well as platform types) a problem and opted instead for a solution where someone who owns a type also controls its extensions. Default methods in Java are purely a way of adding stuff to interfaces in your API without breaking existing implementations (but also allowing future implementations to override those methods). C# on the other hand is merely a bit of syntactic sugar which can be confusing at times. (I have to admit not to be a fan of various libraries that add extension methods to integers and similar. It's not a good way of exposing an API in my eyes.)

TL;DR: Java has something similar, it just came from a different view of how the problem should be solved. Both approaches have advantages and drawbacks.

Silly amounts of magic? Ever looked at a Java Spring project?!

THIS!

In my experience, C# can be coded almost exactly like Java 8; just ignore the extra features C# has. (I don't know why you would, but it's certainly possible.) Do you have more specific complaints?

Plumtree Portal / BEA Aqualogic Interaction / Oracle WebCenter documentation is/was a perfect example of this. When I was working on it, all of their code samples had a footnote that said something like "all code examples work in Java or C# unless otherwise noted". I don't recall ever coming across a language specific example.

Why would someone down vote an opinion that they are okay with Java? It added to the conversation. Personally I prefer C# and Swift to Java but others idea are just as valid.

Imho people are just expressing their disagreement. I know downvote is not meant for that, but I think HN is to blame here. If you have two arrows, one up and one down, why is up for agreement while down is not for disagreement, but for "this doesn't add to conversation"? The actions should be opposite, or they should use different icons.

Really good point!

The implication is "I have no interest in this because I'm happy with what I have". Okay, that's fine, please enjoy your Java and build wonderful things. Oh, BTW, why are you typing into a reply box on a thread you have no interest in? And the implication there is because your tool is a poopy head and I wanted to subtly point that out by expressing my lack of interest.

So, yeah, go away because that's not contributing to the conversation.

> So, yeah, go away because that's not contributing to the conversation.

Well, maybe there’s another implication.

Google switching to C# would lead to them neglecting and deprecating the Java ecosystem on Android. That’s gonna be real ugly for app devs, ending up having to rewrite everything.

So, maybe, there is a real contribution in the comment, which you just haven’t seen yet?

I don't think anyone is suggesting Google should drop Java, just that C# should be made a first class citizen, side-by-side with Java.

Yet, that’s what’d happen. Google hasn’t even managed to support C++ alongside of Java as first class citizen, adding yet another one would make the situation even worse.

> Why would someone down vote an opinion that they are okay with Java?

Paul Graham once said [1]:

  I think it's ok to use the up and down
  arrows to express agreement. Obviously
  the uparrows aren't only for applauding
  politeness, so it seems reasonable that
  the downarrows aren't only for booing
  rudeness.

  It only becomes abuse when people resort
  to karma bombing: downvoting a lot of
  comments by one user without reading
  them in order to subtract maximum karma.
  Fortunately we now have several levels
  of software to protect against that.

[1] https://news.ycombinator.com/item?id=117171

Many have taken this to mean that down voting a comment when they disagree with the opinion therein, no matter how well it argues that opinion and no matter how much it contributes to the conversation, is fine.

This is the number one reason why I looked for a different place and was hoping lobst.er would have taken off.

The down vote causes the comment to be dimmed and seen as a rejection to the comment. It is very frustrating when the top right side is your name and your "Hacker News Points" so I don't get why the down vote if you disagree. A down vote kills the conversation.

It was probably more the 'no thanks'. Got mine sort of mentality, two can co-exist.

An opinion without justification adds nothing.

Care to justify that opinion?

A useful opinion is the result of some thought process and set of inputs. By not explaining that thought process or its set of inputs, it is impossible for others to validate whether an opinion is reasonable and/or useful.

I like Java too and it's a shame we are limited to some weird bastardization of different source levels on Android.

A credible threat of Google moving Android away from Java is the best hope we have of this situation ever improving.

Well, it could be worse. At least the standard library is there, as opposed to GWT (where you pretty much cannot use any Java library at all).

C# and java are very similar except C# has a bunch of extra features. Instead of creating anonymous classes and overriding methods you use event handlers. Plus you have linq,lambdas, operator overloading etc.

There’s also the Stream API and lambdas in Java.

Operator overloading is probably the worst feature ever invented, same with Class Extensions, reducing readability of code.

And with a switch to C# Google would neglect the Java ecosystem on Android, requiring us app devs to rewrite everything again.

I’m not sure there’s an upside to switching to C#.

> Operator overloading is probably the worst feature ever invented, same with Class Extensions, reducing readability of code

or greatly enhancing it. Depending on how you use it.

That's why Java is a language for idiots. I'm not saying everyone who uses it or likes it is an idiot, it's a reasonable language to like. I'm saying it's designed to be usable by idiots. Can't have operator overloading, it might be abused. Can't have unsigned types, no one ever should use those. etc...

Every language is usable by idiots and some are even copied by idiots (C#). The constant security problems we face today were all created by idiots that didn't fully understand the language and the implications of what they were doing.

IMO operator overloading is less bad than goto. (C# has them both)

C# also has yield, async, structs, reflection on generics, and a number of other features.

I think using goto when breaking multiple loops is useful.At least you know where the next line will be.

There are reasonable applications for goto. But I think there are more reasonable applications for operator overloading. (like Complex, BigInteger, or dimensional types)

Lambda's are horrid on Java compared to C# IMO.

Class extensions can be fantastic and really enable design elements in elegant ways, any advanced feature could be argued that it reduces readability if used poorly.

> Operator overloading is probably the worst feature ever invented

A seemingly common sentiment, but one rarely backed by any meaningful data.

Or have both. What's in Java 8 that isn't in C#?

And last I checked you couldn't use Java 8 fully on Android (please correct me if I'm wrong).

Anonymous classes are the big thing I miss. (Yes C# has a feature called "anonymous classes" as well, but it's completely different).

What do you still use those for? I can't remember the last time I saw an anonymous class used in a way that isn't superseded by lambdas.

Yeah, I was thinking about that when I wrote the comment. They were most useful for `Observable` objects for event handling in swing; you don't really need that with C# events.

There are still uses though. Lambdas are the future, but there are lots of OO-first libraries that are still quite popular. It'd be nice to create e.g. `new Newtonsoft.JsonConverter() { ReadJson() {...} WriteJson() {...}}` etc on the fly sometimes without needing separate classes.

It's possible in F# though, so nothing dotnet specific is preventing it.

I use them all the time for defining singleton implementations.

    public static final MyInterface SINGLETON = new MyInterface() {
        ...
    }

Java enums are the one thing that I miss in other languages.

If only we could run IL on the JVM

You are painfully correct...

Value types. Reified generics.