Live data from Hacker News

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

github.com

221–230 of 557 posts

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

#221
post #138

Earlier quoted context omitted.

I am not convinced that Java is adequate. I do not know if the problems are related to the Java language or to the typical Java programmers, but Java is the only programming language where I have seen a strong correlation between the programming language used to implement some application and a low quality of that application. During decades of experience with various programs, whenever I was surprised that a program…

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.

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

#222
post #213

Earlier quoted context omitted.

No Erlang can't share memory between cores atomically. Erlang can only scale 1-to-1 things like phone calls. Java is the ONLY language that scales many-to-many with stable non-blocking IO and concurrent parallelism that shares memory atomically AND doesn't crash.

And for the fraction of the software projects out there that that actually need this feature as a hard requirement, I'm sure it's wonderful.

Well many-to-many IS the point of the internet.

Think MMO here, which is the "metaverse" thing they keep talking about.

Simulating 3D reality over the network IS the ONLY thing humans can do now that doesn't HAVE to burn all the energy we got left while giving use a tool to experiment without risk.

So I'm building the final 3D action MMO game engine.

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

#223
post #138

Earlier quoted context omitted.

I am not convinced that Java is adequate. I do not know if the problems are related to the Java language or to the typical Java programmers, but Java is the only programming language where I have seen a strong correlation between the programming language used to implement some application and a low quality of that application. During decades of experience with various programs, whenever I was surprised that a program…

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.

You are right that all the Java programs with which I had problems were programs with a Java GUI.

With Java programs without a Java GUI, I never had problems.

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

#224
post #146

Earlier quoted context omitted.

Hit too close with the analogy: Been a Java dev for ten years and I drive a Toyota Corolla.... ...but also in my spare time I play around with Clojure and dream of buying a '69 SS Camaro

Admit it, you never will.

Well, maybe, like me, by the time you can afford it, your knees and back don't align with getting in and out of one.

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

#225

I've used Java my entire career and i'm fortunate for it. I appreciate how readable the code is (unlike my experience with Erlang, Haskell, etc), typically i don't have foundational issues in the web framework (once again had some with Haskell). Everything works, if I need to do low latency, there's great libraries and resources, if i need to build a simple internal tool, it can be done effortlessly. I think python i…

Agree with all of that except readability. Java has some language deficiencies (no first-class functions, "streams" missing for almost twenty years and added too late to be done elegantly) and some cultural norms (mutable everything, overuse of inheritance) that make it a chore to read most of the Java code you encounter in the wild, including the source code of the libraries you depend on. Figuring out the behavior of one method routinely means taking a tour through implementation details in three or four superclasses, factories, factory factories, and all the other Java clichés that are legendary but also absolutely real.

You can do better in your own code, but you still have exposure to the code in the library ecosystem.

Worth it, though. It really does seem like there's a Java library for everything.

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

#226
post #173

Earlier quoted context omitted.

Erlang is not as peformant as Java, but there are plenty of reasons to prefer the former to the latter: - a much better concurrency model, that gets you parallelism for free just by adding cores - no global gc pauses, low-latency - fantastic operational tools (trace debugging, remote shell, etc.) - Erlang/OTP gives you great middleware out of the box, including including queues, pub-sub, service monitoring, database,…

All that said, Erlang is a very sharp knife, built for one specific purpose. This is just not true: "a much better concurrency model" If your program is CPU-bound, where real threads are king, then Erlang is a pretty poor solution. Because you cannot have real threads in Erlang, even if you wanted to. Number crunching or string processing are not its forte. Also, most enterprise software does not really benefit from…

There are responses to each of those points, but ultimately you are right that there are tradeoffs. My point was really that Java isn't the only sane server-side language, and that Erlang is an entirely sane option.

The one thing I will say is that, when I say Erlang has a better concurrency model, I mean that it is much easier to write correct concurrent code in Erlang than in Java.

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

#227
post #159
post #116

Earlier quoted context omitted.

Have you ever had to maintain an old enterprisey Java thing? It's pure hell. Basic dependencies (like JUnit) break API compatibility every few years, and then they stop distributing the old version for new JVMs, so you're forced to port your code. The GC falls over in production at the least convenient times. People somehow decide everything should be stringly-typed, and that the best choice between .properties, xml…

> Have you ever had to maintain an old enterprisey thing? It's pure hell. FTFY. And yes, I have worked on old Java apps, they are not worse than any other app that lived for a similarly long timeframe (and the fact that there seem to be more old monstrosity in Java may just mean that it actually manages to do its work written in java, and not fail in some other language). Why don’t you have a bin repo for old junit v…

> Optionals are a mistake but the only fault lies in those who put a null inside.

You can't. 'null' represents an empty optional.

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

#229
post #209

and it still enforces terribly strict OOP patterns onto the developer which is almost never the right way to develop software if you care about performance even a little.

I'm not sure you fully appreciate how tailored the JVM, and hotspot in particular, are to executing OOP oriented code. One great example I can think of is polymorphic methods. In C++ for example, you have to explicitly declare a class method as "virtual" in order for it to be polymorphic - i.e. the version called at runtime is tied to the runtime object instance, not the compile time type. This is because in order to…

it doesn't matter how much the HotSpot JVM is tailored to OOP code. CPUs and RAM are not tailored to OOP in any way.

Procedural code will always be more efficient with CPU and RAM, arrays will always be faster than Lists, being able to control datatype sizing to the byte will always outperform classes, and so on.

java is very fast, please do not misunderstand me. java is much better than it used to be, as well.

Java is not a language chosen when performance is a concern. Java is chosen when you have a giant pile of developers of various levels of skill and you want to pile a ton of rules and linters on them all so they write software in the same way.

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

#230
post #97

Earlier quoted context omitted.

With Loom incoming, Go's only unfair advantage (shared with Erlang) may be gone soon. I guess we'll have the answer in a few years. Will the next WhatsApp be written in Java?

It will take more than green threads to be equivalent to Erlang. Erlang's concurrency model depends upon a completely non-shared memory model, which Java will never have. Edit: and programming it in Java will always be more laborious than in Erlang. Sure, you could put Erlang on the JVM (as the Loom folks want to do) but then is Java really the winner here, or did Oracle just make an alternative BEAM?

While interesting, I'm not sure how that will translate into practice. How easy is it to hire up an organization of Erlang developers, versus, Java developers? I suspect Java's features as compared to Erlang will be good enough, that the specific use-cases enabled by knowledgeable Erlang developers will be non-competitive in the general developer labor market, but I am open to being wrong/educated.
Post reply on HN