Live data from Hacker News

Don’t call it a comeback: Java is still champ

github.com

421–430 of 557 posts

Re: Don’t call it a comeback: Java is still champ

#421

Earlier quoted context omitted.

C# is not a better Java by any means, Java has a more diverse and greater ecosystem, you have plenty of choice for tooling, IDEs, libraries, platforms, etc... With C# you are pretty much stuck with Microsoft which everyone knows what that means (.net core runs everywhere, but still attached to msft in many ways), if you are serious about the C# ecosystem, you need to use Windows, C# IDEs outside of visual studio are…

I agree with most of your points, but also really dislike Visual Studio. Rider has very good compatibility (unless you care about the constant hangs and crashes and buggy, nonsensically laid out eye sore UI and dumb defaults and ...) and VSCode (the one with all the proprietary Microsoft stuff) is quite usable. What kind of blew me away was finding out that they support Jupyter notebooks now. The Visual Studio team s…

Microsoft's multi-platform play is only skin-deep. Witness the lag in features for Visual Studio for Mac which will not be getting .Net MAUI compatibility until a long time after the Windows version.

Re: Don’t call it a comeback: Java is still champ

#422

Earlier quoted context omitted.

My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Before, .NET only ran on Windows which disqualified it from many serious applications server deployments. Today, this is no longer the case for everything but cross platform GUI libraries, and even those are an option if you're okay with not having Linux support. It's more akin to the old car you had just before…

What stuff does C# objectively do better than Java?

Better lambdas and more recently null safety.

Re: Don’t call it a comeback: Java is still champ

#423
post #251

Earlier quoted context omitted.

> it doesn't matter how much the HotSpot JVM is tailored to OOP code This is obviously false. The JVM, or any other compiler for that matter, is what translates the OOP code into CPU instructions. If it does that optimally, it won't matter what design pattern the top-level compiled language used. If it does it poorly, then it will. > CPUs and RAM are not tailored to OOP in any way. This is not entirely true. Intel in…

> If it does that optimally ah, the "sufficiently smart compiler" argument. There is no such compiler, FYI, and there may not ever be. Not for every situation that developers are creating in Java today. it's a matter of hitting your CPU cache as often as possible. Neither javac nor the runtime has any freaking clue how to do that, but you, as a developer, do. When you write Java, you can't do a lot to control how tha…

There is an interesting presentation titled death of optimizing compilers, where it is claimed that programs increasingly are either in their hot path where performance is absolutely crucial and not even C/C++ is sufficiently low-level (you can achieve 2-3 orders of magnitude faster code by hand-optimized assembly), or on cold paths where even Bash would suffice.

Nonetheless, I found that it is easy to find these hot spots and they are trivial to “fix” in java for optimal performance, by simply using a primitive array. At every other place, Java is more than fast enough even with the occasional “jumping around”.

Also, haven’t seen a study on that but would be interested in Java’s defragmentation skills (due to moving GC). Malloc implementations can fragments a lot, and cold path code jumps around a lot. Wouldn’t be surprised if Java would fair quite well here.

Re: Don’t call it a comeback: Java is still champ

#424
post #403
post #400

Earlier quoted context omitted.

Your first point is kind of making a big deal out of something that isn’t that big of a deal. The trivial solution is to just.. use the language’s static typing and don’t pass typed objects as Object. With a generic function nigh everything can be done type-safely (remember, if you don’t use class casts, your generic code will be completely type safe). Sure, there are some edge cases, but they are so edge-cases of an…

I mean, I agree. The static warnings will generally steer you away from the bad cases. From a source-language standpoint, if you don't consider the second-order effects of this design choice, it accomplished a fair fraction of the original goals. But more complex patterns I've seen people try to pass around java.lang.Class objects as a reification. That doesn't really work, because it's skin deep. With significant ex…

I would be interested in your paper.

What I find strange in these erasure-reification “wars” is that so many other languages get a pass. And I sort of understand that, languages without a runtime seldom have reflection, or only in some primitive form, and most language on top of a runtime are dynamically typed. So outside of guest languages, Java and C# are unique in this aspect, and Java does use reflection very heavily, where I can imagine that restricted access to the whole type may be a hindrance.

Re: Don’t call it a comeback: Java is still champ

#425

Earlier quoted context omitted.

My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Before, .NET only ran on Windows which disqualified it from many serious applications server deployments. Today, this is no longer the case for everything but cross platform GUI libraries, and even those are an option if you're okay with not having Linux support. It's more akin to the old car you had just before…

It's hard to see how C# will ever find wide usage outside of the MS ecosystem. It's so intrinsically tried to MS.

.Net 6 runs on Linux with, for example, PostgreSQL so how is that tied to M$?

Re: Don’t call it a comeback: Java is still champ

#426
post #138

Earlier quoted context omitted.

Java UI and applets have been abandoned long ago (>10 years). This was partly due to webapps becoming the standard, but also the realization that for desktop apps non-native UIs just suck. The vast majority of Java (=running on the JVM) software these days is server-side, without any user interface.

Precisely, and exactly why the programming world is an absolute, cargo-culting mess of Javascript frameworks and libraries these days. Sure, React is winning the mindshare war now, but it's just the least ugly baby winning the beauty pageant at the county fair.

If Javascript produces much better UX than Swing/JavaFX then surely that's the right tool for the job? SPA with Angular or React isn't the only choice anymore as Hotwire/Stimulus and similar libraries (Unpoly, Inertia, htmx) testify, allowing you to handle your routing and state management on the server while preserving partial updates on the client.

Re: Don’t call it a comeback: Java is still champ

#427
post #416

Earlier quoted context omitted.

Old school xml based Spring is horrible and if that was your only exposure, I understand your aversion. But spring-boot has an almost zen like quality once you get that it favor convention over configuration. When I was a Java developer, I'd usually use spring-boot with the following dependencies to make the experience better: - lombok: to generate the boilerplate: constructors, getters, setters, equals, hashcode...…

Spring Boot is still Spring with its annotation madness. Take parameter validation, for example. Crazy, full-screen-width multiple annotations stuffed inside the method parameter list. What on earth is wrong with doing validation as other frameworks do, ie. in the method body?

Exactly. I feel calling SpringBoot as polished turd would be wrong. It's not even polished, just turd. Where ever I have been forced to use it is 4-5 times the amount of code that would normally be needed for such functionality. Large number of bloated Spring libraries and converts normal compile time errors to runtime exceptions. But tools at VMWare are relentless in pushing it through enterprises.

Re: Don’t call it a comeback: Java is still champ

#428
post #417

Earlier quoted context omitted.

C# interfaces with methods, properties, and events is just so nice from a readability standpoint. I know we like to pretend that Java now has first-class functions since Java 8, but without easier to use functional signatures they're just too much of a chore. Who the heck wants to write a new interface in a separate file to do this. I'm grateful for the JVM and think it's probably better than the CLR for targeting a…

You have Function , Supplier , and many other predefined functional interface in the standard library.

That's my point, we don't have much more than that. Even a 2-arg function is missing. You can supplement with something like Vavr or just write your own, but even then it's not pleasant to read "Function3".

Typescript, Kotlin, and Scala all do this way better. Here's an example from Kotlin (it's an extension function, but focus on the combiner lambda):

  fun  Collection.fold(
    initial: R,
    combine: (acc: R, nextElement: T) -> R
  ): R {
    ....
  }

Re: Don’t call it a comeback: Java is still champ

#429

Earlier quoted context omitted.

Whoever invented the car analogy should pay for what they did.

I remember an intermediate OO class in Java 20 years ago... the existence of the El Camino was proof of the terribleness of both multiple inheritance and car analogies.

.... with gave birth to ShapePoint analogy.

Re: Don’t call it a comeback: Java is still champ

#430
post #404
post #332

Earlier quoted context omitted.

> I once worked on a Java-based server at Google that had to answer requests with millisecond latency. That's... not really normal, though, and sounds like the exception that proves the rule. For the vast majority of applications, Java will perform better, be easier to develop, and be safer to run, than an equivalent server written in C or C++. At my previous job we used to run realtime audio through a Java server (R…

Finalizers are deprecated (though are still used of course in existing programs), so just a heads up: Cleaner API is the replacement

Sure, I mean, finalizers have been deprecated as long as I can remember. But -- as you say -- they still work, and I expect will continue to work for quite a while. And, as you suggest, probably forever for existing bytecode that targets older JVM versions.
Post reply on HN