Why Java is still relevant | Hacker News Reader

Why Java is still relevant

medium.com

47 pointseranation78 comments

Also a lot of the de-facto Big Data/NoSQL/Distributed Computing stack is Java(/Scala). Hadoop, HBase, Cassandra, Neo4j, Storm, its actually pretty interesting to note that most of the popular nosql solutions are in Java. On top of that its the number 3 language on Github.

I'm not a huge fan of Java but I'd be pretty surprised if someone was saying Java wasn't relevant. Don't quote me on this, but its also the fastest language you are going to get without pulling out C/C++. When the author made the claim that Java was as fast as Go, I was a bit surprised. I wasn't aware Go had caught up to Java.

JVM crypto (i.e. using encryption libraries) can be faster than native because of function inlining (whereas in C/C++ you don't inline across libraries at link time because an update to the crypto library would require a recompile).

Java and Mono have been shown to be roughly comparable overall in speed, each a bit worse or better than the other in some ways, I've read.

Shown where? Mono's JIT is nowhere near as good as OpenJDK/Hotspot.

http://stackoverflow.com/a/9138207 I think this is the answer I was thinking about.

It's also because of automatic garbage collection and the fact that programmers today can't handle memory management.

Programmers in the past couldn't handle memory management either.

Programmers today do not have to handle memory management because of JVM. Programmers yesterday could not handle memory management that's why jvm came into existence.

It's because of automatic compilation and the fact that programmers today can't handle register management.

It's because of integrated circuits and the fact that programmers today can't handle voltage management.

> When the author made the claim that Java was as fast as Go, I was a bit surprised. I wasn't aware Go had caught up to Java.

As a Go "fan": it hasn't. It's close in some things, faster in a few, but the JVM has years (and years) of performance tuning in it, and Go won't unequivocally beat Java for some time (if ever).

(This WiFi connection is failing me right now, but there's a good number of Go vs. Java benchmarks out there, for whatever benchmarks are worth)

I was only referring to the Web framework benchmark, where Go (1.1 I think) is taking the lead over Servlets on many of the benchmarks. Still impressive.

That was my reaction as well. We are using Go in production here and I'm very much a Go fan, but I'd be surprised if Go caught up to Java in so little time.

I was referring to this benchmark: http://www.techempower.com/benchmarks/

That benchmark makes it clear Go has not caught up to Java in performance.

Out of the 10 tests that have both Java and Go results, Java is faster than Go in 9 tests while Go is faster than Java in 1 test (by 0.2%, so not significant).

I counted go lead on 3 of the tests, but I agree with your point, will fix the article accordingly, thanks!

Only 1 of those 3 tests (the very 1st one) also contains Java results. The other 2 are Windows tests that don't contain any Java results.

Hence I said that out of the 10 tests that contain both Go and Java results Go only beats Java (by a statistically insignificant 0.2%) in 1 test while Java beats Go in the other 9 tests.

You are so right, bad attention to details day for me. corrected the article in any case. thanks!

There is no reason why Go can't quickly catch up with Java. It's memory model is better suited to optimization vs. JVM.

This is one of my first posts, and English is not my native language, so comments not just on the content but also on the language are more than welcome.

Speaking for myself in the U.S., the need to learn a new language other than English has become such an edge case that I always marvel when non-native English speakers put their work out for us to judge. Your writing is clear...more importantly, you have a great grasp of how to visually partition your essay, a skill that many writers, native English or not, could improve on. Great submission, even if I'd like Java to be less prominent :)

Thanks! :-)

In that case, "Why it saves you time?" should be "How does it save you time?" That was the only line in the piece that screamed "non-native English speaker" to me.

Much appreciated, thanks!

I was impressed by your clear writing. Some minor suggestions since you asked for feedback: <:)

* "mandatory requirement" is redundant. If something's not mandatory, then it's not a requirement! :)

* "Many admit that as much as Java is not much fun to write code with, the JVM is a different story.": This sentence is awkward. Perhaps something like: "Many admit Java code is not much fun to write, but the JVM doesn't limit your choice of language."

* "Scala shares the Java Technology Stack, and knowing Java is a big plus when learning Scala, especially due to the common library ecosystem, and the insights into the JVM workings.": This sentence is awkward. It could be simplified into something like: "Knowing Java is a big plus when learning Scala because the languages share a common library ecosystem."

If you are interested in more resources about English writing, I recommend Joseph M. Williams' Style: Toward Clarity and Grace. Strunk & White's Elements of Style is a classic (and short), but some people dislike it.

Great feedback, I will certainly look up these books, thanks!

btw, Elements of Style is a very short book (~26 pages) and early editions are available online:

https://courses.washington.edu/b572/public/StrunkWhite.pdf

It's also not very good:

http://chronicle.com/article/50-Years-of-Stupid-Grammar/2549...

I like java as a language. It's consistent, has less warts than many languages and the jvm is pretty darn awesome.

What I don't like is the java ecosystem. Guice? I've nothing but bad experiences with it. Just about every framework out there that I've used in java has gotten in my way more frequently than it's been helpful. Java Api's (excluding much of the stdlib) almost all seem to be made to annoy me.

Java's great. If only it's ecosystem matched.

I work on a large application that uses Guice, and it doesn't seem so bad, so YMMV.

Mind you, this may just be because there are other things in the application that are so much worse.

I like Java, really. Learning it might be a good idea as the article suggests, you might find you like it too. It's solid, fast, tons of libraries, it's efficient for programming IMO.

Java and the JVM seem like fantastic foundations to have for a language like Clojure. You can develop in a fun language and still use the immense amount of libraries that have been created over the years by the community. You can interop with pretty much anything, and you didn't have to make it yourself or wait for your language to catch up to it, because it's been there all along thanks to Java.

Don't look at Java like the starting point, look at it as the big furnace for what's leveraging it.

I have always found it rather unfortunate that the JVM is the best platform for Clojure, and unfortunate that interop with Java is so important. All of the blemishes on the language seem to be a consequence of those two things.

I think the idea is to have Clojure support as many runtimes as possible, or whichever runtime is best for the task. The JVM was the start and at this point has the biggest momentum, but there's not much stopping people from porting the language to a different runtime.

I really truly love Clojure the language. To me the vector, map, etc syntax is a perfect amount of syntactic sugar--it institutionalizes idiomatic use of these structures.

But... sometimes the JVM feels awfully heavy-weight and far from the metal. I have to wonder what a Clojure on SBCL or Racket would look like. Ignoring for a moment the benefits of the epic number of JVM libraries, I can't help but think that the foundations of those languages would be a pretty low impedance mismatch for Clojure The Language. Hey, Clojure-on-CL or Clojure-on-Racket could even support real tail recursion.

Could that mean that Clojure might one day support TCO/mutual recursion as F# does, if being used on the CLR?

I know it is cliche to complain about that, but it really does annoy me.

A Clojure targeting LLVM could be pretty interesting too...

I've given up any hope of Java ever being considered a sexy language. Its philosophy has been the polar opposite of 'move fast and break things' at least in terms of how the language has evolved. That's been mostly a good thing, though frustrating. The language features are catching up now with the 'sexy' languages and it's pretty exciting.

Still one of the biggest problems with Java I think is the plethora of options you have when building a web stack. And integrating everything is a huge pain. There are options like dropwizard or play, but those bake in too much of their own assumptions for my taste. If anyone is interested in seeing what a modern Java web stack looks like, check out my attempt at it here: https://github.com/depsypher/flapjack

Java will wane in relevance as Oracle turns it into a way to squeeze support contracts out of users (see the recent timezone-update kerfuffle).

Actually, Oracle have proved a LOT more committed than Sun to improving the language. They put one of the smartest guys in charge of Java 8, charged him with turning the ship around and have given him a lot of resources to work on it. Even Java 7, while including few language features, did include a lot of JVM improvements.

The timezone-update tool, on the other hand, really is a minor issue. So some people will have to use IBM's tool instead. Yeah, it's lame, but I don't think it's going to change anyone's mind.

Did you not notice that Oracle is still providing free TZ updates through regular JRE updates?

TZ updates aren't going to have much of an impact on Java relevance. If they start charging for JRE updates themselves, let's talk.

Every time articles about a language "still being relevant" pop up, my first thought is "oh, it's down to that stage already". Not sure what this article is trying to accomplish.

Java runs the world and runs on several devices from Raspberry Pi, embedded robots (java me) to Mobile Devices (Android) to Enterprise Software (Java EE) to Data Servers crunching Big Data (Hadoop).

Amen.

I'm a bit tired of people just dismissing Java based on its hipness factor.

I dismissed Java a lot more back when it was hip. Now that it is not hip, it is no longer necessary to dismiss Java, since I can simply ignore it.

Why learn Java? Sure, there's lots of jobs out there for it, but there's also lots of Rails jobs too. Rails is more fun than Java, so if you're looking to expand your career opportunities, you're probably better off learning a tech stack that won't bore you to death.

Things are boring when you already know them. Things are interesting when you're learning something new. Most of the excitement over other languages comes down to the fact that you are starting from scratch and everything is fresh.

As someone who coded both Java and Javascript today, I attest that boring is also when every little darn thing takes 10x the amount of time and code as it rightfully ought to.

Boring is also spending a few hours tracking down a typo in a large Javascript app. Or trying to refactor something and grepping through a bunch of files trying to find the ways in which it's being used. There are downsides and upsides to both kinds of development.

Really? I guess you spend too much time coding than solving a problem.

Java / Python / C# / Go... All the same.. I spend more time solving a problem than actually coding.

Once I have a solution rewriting in an another language is a piece of cake.

Right.

I think Java does suffer from a little too much boilerplate, but that is solved by becoming proficient in an IDE which doesn't actually take too long. Even for this old hacker who only picked up an IDE 2 years ago after nearly 20 years of emacs.

Java is very verbose, but also very strict and explicit. Besides all the obvious benefits to that, it means you can utilize auto-complete/intellisense/refactoring tools that let you pound out code at a rate on par with dynamic languages, even if you are producing 10x the amount of code. Fully learning these tools, e.g. in Eclipse, is a meta-skill that can take some time to get good at, but if you're working with Java for anything over a few weeks, it's definitely worth it.

This is very true. It's why I seem to keep looking at Clojure articles and tutorials lately. I keep saying I should master language "X" then I jump to something new...Thankfully I'm just a hobbyist.

My point was that if you know ruby, and think about adding something to your arsenal, don't write off java automatically. I meant it's still relevant for hackers to learn it, even though many of us agree writing in ruby is more enjoyable.

>Why learn Java? Sure, there's lots of jobs out there for it, but there's also lots of Rails jobs too.

Far far less than Java jobs.

>Rails is more fun than Java, so if you're looking to expand your career opportunities, you're probably better off learning a tech stack that won't bore you to death.

Rails and CRUD web apps bore most hackers to tears.

At least with Java you can work from web apps, to Android, to web services, create powerful servers like Cassandra or powerful stuff like Solr and Lucene, use embedded Java, and a lot more.

> Far far less than Java jobs.

Especially in middle America, or corporate America.

> Far far less than Java jobs.

And far far far far less than .NET jobs. Which is still more fun than Java.

> Rails and CRUD web apps bore most hackers to tears.

They don't bore me to tears. Between the brand new Javascript frameworks like Angular and CSS frameworks like Bootstrap, it's possible to develop great looking, simple apps that have a great deal of functionality in extremely short amounts of time.

Rails is not a language. Rails is not ruby. I wish people would stop conflating the two.

That would be why I referred to it as a tech stack, not a language.

Touché. I should read more clearly, and be less angsty. Sorry about that :)

> But there's also lots of Rails jobs too.

Depends where you are. Outside Silicon Valley and a handful of tech hubs in the world, Rails pretty much doesn't exist. Java, on the other hand, is used everywhere.

I would be curious what PG thinks about this. Relating in opinions described in his book. And is it just me or "banking startup" sounds like oxymoron.

Anyway, thanks for sharing your opinion. Still think learning GO could be a better idea, at least for me.

A great irony about the use of Java as a language for interactive systems is that it only took off when deeply enmeshing a Java-ish runtime with Android freed Java from the constraints of "write once run anywhere."

It turns out that OSs have diverse interactive frameworks with different capabilities, and OSs compete on the basis of those differences. In Android, this divergence from other OSs includes the ability to install aftermarket middleware in Android's userland.

Java is the new COBOL. Everyone is going to be wondering when Java will die for the next thirty years. Java will still be running the enterprise decades after RoR is gone.

The more interesting question is which will die first: Java or COBOL?

Java is still relevant because of how much code is written in Java.

Just like Cobol?

As expected, the article was that, a "Java is fast" that can only be said if you don't compare it with anything made to be fast, and "Android uses Java". All the other reasons are excuses for drawbacks of the language.

The one thing that made Java relevant - that one can create a ruleset that constrain bad coders and avoid them destroying all your codebase - didn't go away. And the context where companies just don't know how to hire developers didn't change either, thus still only projects that protect themselves against bad developers are ever successful within them. But it seems that the more productive languages are so much more advanced than Java nowadays that it become better to protect a project by hiring less developers than by making them less powerfull... Or, at least, I can think of no other reason for people to care to anounce that Java is not dead yet.

Lucene (and projects built on Lucene like Elasticsearch and Solr) make Java relevant, even ignoring everything else built in Java.

Of course, who says it is not? Java sucks allright, but is still a big player in the industry.

>> Stream.of(1, 2, 3, 4, 5, 6, 7) .map(x -> x * x).filter(x -> x % 2 == 0) .reduce(0, (sum, x) -> sum + x);

If I catch anyone writing Java code that I will have to work on writing Lambda expression crap like the above I will hit the ceiling. How can you debug junk like that?

I write code like that with LINQ and such in .NET all the time and have no problem debugging it.

Is there actually a way to properly debug LINQ expressions? I haven't figured out how to get Visual Studio to step through lambdas or break halfway through the chain (eg break after the filter call has completed and before reduce runs in the above example).

But I'm not sure if I'm missing some blindingly obvious.

I don't know, but it just hasn't been a problem. If something's that wrong with the expression chain I can just break it up temporarily.

Thing is though, now you've changed the recipe from what you intend to run in PROD. You linearized it to gain a debugging advantage that you lose when you re-lambdaize it.

this probably isn't the place to start a chain on how to do this, but if you wrap the statement in the lambda in a {} block and explicitly return the expected value, you can insert line breaks and set breakpoints.

i'm not familiar enough with the vocabulary to explain it perfectly, but i do it all the time.

example: list.Find(o=> { if (o.prop == "foo") { return true;} // visual studio will allow a breakpoint here else { return false;} });

I find that perfectly readable. I would be more likely to catch an error in that line than in the equivalent in imperative style. It's a matter of habit. It all depends on what you are used to write, whether you are used to functional style or not.

This exact response right here is why a perfectly good language like java is ranked just under php in the hated languages list.

The language is fine but the insistence by the vast majority of the developers using it to do things in a way that can only be described as "Enterprisey" gives it a bad name. And it really is a shame.

How can you not debug "junk" like that?

I can see my view is already unpopular but you asked a fair question. It's several key pieces of logic jammed together on one line. That's not the part that bugs me though, it's wondering how this is going to play out. I can imagine multiple threads servicing the Lambda stuff and it reminds me of trying to debug Camel code hopping around debug screens trying to stay up with all the async stuff going on just to find a simple bug. Maybe ... maybe I'm wrong ... I could be, I don't think I am but it's going to have to be more deterministic than what I'm afraid it will turn out to be.

I guess I can understand if java doesn't allow for debugging code similar to this. Being fond of lisp/scheme languages such as racket though, I find this very clear and is of course easy to debug in those languages.

That code is exactly equivalent to:

int sum = 0; for (Integer x: Arrays.asList(1, 2, 3, 4, 5, 6, 7)) { int x2 = x * x; if (x2 % 2 == 0) sum += x2; }

No threads, no weirdness. It's just a different syntax for a loop, really.

Reply on news.ycombinator.com