Hacker News Reader

Comment by palindrone | Hacker News Reader

"Java is no one's first choice for writing desktop UIs, whereas .NET is standard for business applications"

From my PoV neither Java nor .NET is the first choice for UI. HTML and JS is. Especially for large multi-million dollar software. I know what I'm talking about here. Yes, HTML&JS are bad and crap, but may times better than applets or desktop apps. Nobody likes vendor lock-in.

When it comes to server side .NET is much worse than JVM.

So now, you got the picture why Mincro$oft made this desperate move. Developers, developers, developers...

View on HN

Could you elaborate on why server-side .NET is much worse than JVM?

I'll add something here. The CLR is a PITA when it goes wrong. Its a total bastard to debug. JVM on the other hand has wonderful instrumentation capabilities at runtime.

At best you get a minidump out of a CLR process that is misbehaving and take it to bits inside VS. You may or may not catch it doing bad things. Most likely you'll find yourself with half the threads inside win32 and an 20 mins wait for symbol server to snag the symbols.

100000x this. While trying to track down a memory leak I discovered that while pretty much any guide out there on the internet points to using WinDg and referencing a Microsoft site for the symbol files, the .pdb doesn't actually exist.

As far as I can tell the symbol files got removed with one of the 4.5.x releases, and as early as June people were asking about them: https://social.msdn.microsoft.com/Forums/expression/en-US/7b...

Still no word... I'm no debugging expert, but it seems like you're SOL if you want to find a leak within managed code.

Perfmon? Performance Counters? Tons of instrumentation for .net

That's of absolutely no use when the box is under heavy load. Perf counters just stop working.

We had a system wide thrashing problem with ReaderWriterLockSlim which doesn't work properly under load. Took 15 mins to log into the box to blast the process. Couldn't even get any performance info out of it. Happens on a JVM on Unix; no problem.

For ref the concurrent collections should not be trusted under heavy load in processes with more threads than CPUs. Its to be honest piss poor quality.

JVM runs on wider range of hardware. JVM compiler is faster than .NET equivalent. JVM has more programming languages tagetting it. these languages have much more mature libraries. Some of them run on .NET, but almost none of the languages from .NET runs on JVM. JVM has many many more man years spent on libraries, so Java libraries are much more trustworthy. And so on...

JVM and Java are much more reliable. Java backwards compatibility beats .NET every time. How many .NET frameworks do you need to install if you need software written in different versions of .NET? Answer: all of them. And Java?: only one. I've got 3 or 4 versions of .NET on my system because of this.

That's interesting, because my experience has mostly been the opposite.

On the server side, you can install whichever .NET versions you need and they will live together quite nicely. But you can only install one Java version, and updates randomly break things (that's probably not true in general, but that's how it seemed to me). And I can only remember a handful of issues that were caused by the .NET framework, we had constant reliability issues with Java.

Having lots of languages available is nice, but it's not a core requirement for a platform in my opinion. .NET has C# and F#, and they complement each other very well.

I haven't had any library issues with Java or .NET, so I can't comment on that.

My guess is that my problems with Java stem from lack of experience with it, and my success with .NET is because of my deep experience with it. So it seems likely that your perspective is for similar reasons.

> Having lots of languages available is nice ...

.NET's C# and F# are actually the only choice. C# is old and at most slightly better than Java 8. F# is somewhat better (much more concise) but still behind Clojure, Scala, Frege, etc... I'll also want to mention here that IMO Clojure is now on the forefront of innovations actually implemented and widely used in enterprise class software. STM, async, channels, static types, transducers, etc... and all these things are so easy to use for a newcomer. Every other language have already copied something from it or is in the progress of doing it. When I'm programming in Clojure I can feel I can work miracles - things that are hard or almost impossible in other languages I can write in a few lines of CLojure. Brilliant language. I'd discovered it couple of years ago and I'm still shocked by its power.

You can install as many java versions as you need (I have everything from 1.4 to 1.8 and multiple versions of each major version all on same machine). And they all live side by side. You use which ever one you need.

> From my PoV neither Java nor .NET is the first choice for UI. HTML and JS is.

That's a real vindication of the "worse is better" theory.

I agree, but what can I do. If you want larger client platforms coverage this "worse" becomes actually better. I don't like WEB stack also, but HTML is the best x-platform GUI technology right now. Evey system has a web browser, but not everyone runs JVM, .NET or similar (or runs none of these - Android, BB, iPhone...).

"From my PoV neither Java nor .NET is the first choice for UI. HTML and JS is. Especially for large multi-million dollar software."

Yes, it's multi-million dollar because that's the budget it takes to make anything complex.

No. Because making anything complex that works on many platforms is very hard work. Take a look at WhatsApp (recently bought by Apple for $19 billion).

But the quote specifically calls out desktop UIs. HTML&JS might be standard for UIs, but what about specifically desktop UIs? Not everyone has the option of putting their UI on the web.

Cordova, node-webkit, atom-shell, windows8 ui, gnome ui, etc... All offer options to target html+js to a platform user interface.

I recently did a project with node-webkit and edge.js. There were some hurdles but it ended up working pretty well.

I get to use the both the same HTML-based UI on the web part and the desktop app, as well as the compiled .NET libraries.

Reply on news.ycombinator.com