Hacker News Reader

Comment by 63 | Hacker News Reader

Correct me if I'm wrong here, but now that everything is run in a docker container anyway, doesn't most of Java's appeal of "write once, run anywhere" from the turn of the millennium go away? At this point all it has is garbage collection and a network effect.

View on HN

I don't think WORA was ever a really big deal for server-side work. In practice, you know what platform you're developing for, and even if you were developing on Windows and deploying on Solaris, you would have plenty of opportunities to test on Solaris before deploying.

I think the reason that Java beat C++ for boring line of business apps is that it was much, much quicker to write code which ran fast enough and didn't crash much. Having nice easy to use URL/HttpURLConnection classes built in was probably also a surprisingly big part of it!

Java has a number of other advantages... you can effectively develop for Linux on a windows box. The vm architecture makes debugging easier. It has a large and useful body of code, including lots of libraries and features that ease interfacing with legacy systems (like corba and soap)

The time and effort needed to train Java developers versus C++ developers is also huge.

This means more Java developers are available for hire and they typically cost less than C++ developers. This reduced on-boarding time and reduced cost is extremely attractive for enterprises.

> At this point all it has is garbage collection

You say that like it's a minor thing, but GC is probably the largest language-related productivity improvement I've ever experienced as a developer, second maybe only to static types.

Unless you need bare metal speed, or use some specific piece of code, never use C++. It is horrible, convoluted mess that will consume developer hours into pointless trivia that are not issues in anu other languages. So C++ has that as point against unless you want to waste developer hours on purpose. I’m saying this while writing C++ daily because in our domain (cad, geometric computing) for our use case it’s the best option only because mostly it’s the only option.

Most of enterprise Java jobs in mid/ junior engineering level are similar to old times production assembly line, everything has a Factory or Impl from dependencies. All you have to do is add bunch of methods and connect API's and service bus (of course I'm extremely simplifying it, but) it's not hard to find people who can do that, also it's not hard to get them up to speed for what needs to be done so the churn rate doesn't impact a lot to enterprises which is a big win. In my personal experience I don't think that's possible with C++ so Java may have started with "write once, run anywhere" now its more of glue between longer running actors and constantly changing workforce

Yes and the best part is that companies instead of migrating from Java to something lighter are simply trying new things like GraalVM which makes native executables.

So your developers can keep on writing crappy and heavy spring boot applications (which need 10-15 seconds in best case scenarios to to start) and eventually be "graalvm-ed" to produce a native executable that starts in < 1 sec.

I mean, that's a brilliant evolution (no jokes). This is how you keep in the game without getting devoured by Go and similar.

> all it has is garbage collection and a network effect.

It didn't have much of an advantage at the time either. It's advantage was that Sun was willing to shower SPARC boxes on your university for almost nothing if you were willing to move your core curriculum to Java.

Reply on news.ycombinator.com