Hacker News Reader

Comment by blibble | Hacker News Reader

there's nothing in that post that gives C# a measurable advantage over say, Java.

Visual Studio Express? still way behind JetBrains IntelliJ (the community edition is FOSS). Visual Studio is unusable without JetBrains Resharper, which isn't cheap.

Azure? AWS

Bizspark? not required for Java dev as everything's free and OSS anyway.

Popularity? most popular .net libraries/tools (NUnit, NAnt, NHibernate) are all clones of popular Java projects

Scalability? those Windows licenses will cost you a fortune once you're out of bizspark

Vendor lock-in? well it's still there with MS, just you're not paying them for three years (Bizspark)

View on HN

In my experience C# is just a better language than Java (which isn't suprising, as C# was made just to be a better Java clone). Things like

  * value types (instead of boxing)
  * no type erasure
  * runtime exceptions
  * dynamic/duck typing
  * operator overloading (try working with arbitrary length decimals in Java)

just solve a lot of the small headaches of everyday programming.

That said, I still prefer Java because of the ecosystem and newer JVM languages like Clojure and Scala might just make Java irrelevant.

I've worked with C# and .NET for years. I agree that C# is a great language. I prefer working with the JVM and Linux ecosystems, though. On my latest project I decided to use Scala for the backend. I have access to a wealth of great libraries and services, and I actually prefer working with Scala than with C#.

Scala has replaced Java most of our new projects.

C#'s a somewhat better language, but I'm not sure there's enough in it to justify the ecosystem deficit, and, yep, Scala is there if you want it.

Scala has all of those things, plus typeclasses, for comprehensions and scoped duck typing.

"Visual Studio is unusable without JetBrains Resharper" ... I used to think the same. But my coworker doesn't use resharper and in he still codes better then me. I've actually noticed that VS becomes unsuable with Resharper, it is always feeezing now.

Ya, where did this myth come from? I don't use resharper and feel more productive than I did in eclipse.

a measurable advantage of c# over java is LINQ.

Java now has lambda's and a stream API, with which you can do the same thing as LINQ: http://blog.jooq.org/2013/11/02/does-java-8-still-need-linq-....

LINQ has expression trees (or maybe I should say .NET has them). Libraries like autofac or moq would not be possible without them.

This is a very unpopular opinion among .NET advocates, but personally I think LINQ is the worst thing to ever happen to c#.

It leads to (in my opinion) grotesque, unreadable code that more often than not hides enormous performance problems. It offers so much expressiveness, seemingly so innocent of its cost, that it gets massively overused and abused.

As with all things in languages, one can argue "use it right", "don't work with bad programmers", etc, but I have found this to be a universal issue across a number of shops that I've been brought into: If the project uses LINQ to any degree, enormous performance problems almost always come along for the ride.

Often this simply doesn't matter, hardware or low utility masking the problem. But when it becomes a problem, and it is endemic across the solution, it requires major reworking.

Absolutely agree. I can't count the number of times I've seen some horrendous LINQ thing when a simple for loop would have sufficed, would have been easier to understand, and would have been far quicker.

Linq is an opportunity to write slow code very quickly. Of course when you have to spell out a 1-line Linq expression as a 50 line method, you'll notice that you wrote a triple nested loop and avoid it. But the point is this: the longer code is MUCH harder to comprehend than a concise Linq query, and the developer that didn't see that their Linq query was going to be slow wouldn't have reacted on that the expanded version also looked slow. The single line query can be more easily refactored as it can be comprehended.

So I say write slow code so you can find what's slow early on. The problem is likely to be in the architecture and data structures rather than in the processing code. If Linq gives an opportunity to deliver a working example quickly, and that example shows that for large N the perf is horrible, then Linq was extremely useful! Change some collection type, demoralize something, add some caching etc. and then slightly adjust the Linq query to suite. Large query methods are inertia to such changes so when they DO become necessary it's a larger effort.

Note that I mean Linq to objs now not Linq to Sql or some other provider.

Reply on news.ycombinator.com