Hacker News Reader

> There's many valid critisicms of Java...

Yes there are.

...but the parent assertion that Java will one day be like cobol; no longer taught in intro to CS course (where now we see python), considered bloated and legacy, and not picked for new projects (where we see the rise of languages like kotlin eating into what was once the primary growth for the language with mobile apps) and encumbered by problematic licensing issues...

Seems quite valid.

You have to live in a bubble right now not to get the feeling Java is stumbling, and there’s no indication to me that the overall direction of the language is positive right now.

...I’m sure there are still years ahead for earning a good living as a java developer, don’t get me wrong, but that’s a different issue.

I agree that the future looks bright for Kotlin and C# .Net Core especially. I'm also a big fan of Typescript but JS derivatives are missing many nice things like threading.

But I disagree that Java is like Cobol. The syntax and general situation is extremely similar to C++. There's still tons of work being done on it, but it's a mature language that will be around for decades. IMO it's still the best language to run on the server for a multitude of reasons.

Like COBOL in the sense of its purported future niche in the industry, not in the sense of syntax and language power.

Yes perhaps that's true. I ask you to consider some c++ to java conversions though. Usually the syntax is almost identical, whereas COBOL is clearly terrible

May be I am living in a bubble... it's always hard to tell from inside the bubble. But this is not my impression at all. All of the major tech companies have major Java footprint which is not going anywhere. This is not only the older tech companies (FB, Goog, Amazon etc.). Even newer companies like AirBnb, Uber rely heavily on Java. Startups often start with fancy esoteric languages but eventually do come around to java/c++/python once they need to really scale. I am not sure what exactly gives you the impression that Java is like Cobol.

Agree, and yeah Java is peaking "uncool". But I don't care. Call me old fashioned but the damn thing works so good I can forgive a multitude of sins

I see the same in major enterprise companies I and my peers have worked in. Java is being used for a lot of large greenfield projects I am aware of.

Yes, the enterprise bubble where Java, .NET, C++ and JavaScript rule.

I mostly agree, except:

> But Spring is dated and not often used for new projects.

Spring Initialzr (https://start.spring.io) is used millions of times per year.

Fair enough. The Java ecosystem is huge and I try to keep up but many things slip through the cracks, you'll find many in my furious comment history on the thread.

Thanks, looking it ip

No worries. I feel where you're coming from.

Spring Boot is all but dated. I could name you countless huge companies using Spring Boot to write new applications that will be used by millions of people per day in Austria alone.

> But it's extremely fast compared to anything but Go, C#, and "low level" languages nobody wants to touch for web stuff.

Fast is a poor word to talk about benchmarks between languages. Memory, throughput, latency are the things we should be talking about. There’s also trade offs where predictable scaling of latency under massive load is important (Erlang, Elxir), or spending less memory and starting up quickly in order to scale horizontally is important (Golang), or speed of development is important (PHP, Python), or correctness is important (Haskell, Rust). Java is rarely the winner in any area in favor of being well rounded, but as we should be using tools that meet at least the broad requirements it is always possible to make a better choice than Java.

> I’ve seen apps run for years straight.

This is why Java is dated. I am an Erlang developer, which is known for being hot reloadable and running forever. It turns out this model is actually juxitposed to Kubernetes and severless, which both presuppose letting processed crash at the host level and starting and stopping quickly. This also gets into the tooling argument because profiling in Java would rather the VM be long lived.

> The tooling.

I too have an operating system with great tooling, it’s called Linux. My knowledge of tooling is more broadly applicable, I can introspect any binary and attach probes to the kernel with bpf. Profiling for a VM is table stakes because you’re on your own. Not only do you have to figure out what’s going on in the JVM you also need to duplicate your effort to figure out how the JVM is running on the host.

> Java OO is fine.

OO in general is not fine.

> OO in general is not fine.

I smell a zealot or a troll.

Please elaborate on how OO is fine. OO hides state, which makes reasoning about cache, and therefore performance very difficult, which is why most game programers take a data oriented approach. It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing. Inheritance isn’t an abstraction because you inherit both code and state, which requires explicit knowledge of the intervals of the parent. It’s a code pasting tool. As OO tries to model arbitrary patterns in nature it’s also difficult to reason about the graph of objects apposed to the linear flow of data in FP. Pretty much all of the OO languages are walking back OO features at this point and trying to add type classes (contracts) or functional pieces, mapping and filtering a la linear data transformations.

These are actually all fairly common problems so I'm not sure why this is drowned out in gray...

The over-zealous tone may annoy some people. Also, he/she could have gotten the same point across more effectively without implying that Erlang and FP magically solve all problems.

I actually agree with you here that OO is overused. Java has added quite a bit of FP in recent years though.

Lombok makes immutable data classes trivial. Improved interface support for default methods make it possible to largely ignore OO if you don't want it.

FP is mostly a community effort at this point, but solid. Java Streams are decent for basic stuff like map/filter but RXJava is extremely powerful if you want the complexity it comes with. Vavr is nice for adding more FP types too

True, class inheritance is so hard to get right that is just better to avoid it. Lots of coupling and spaghetti code because of this, but to be fair, you also see this on other languages, like python, php and even JS.

> It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing.

Smalltalk is exactly like that - other objects' state is only mutable through explicit message passing. It's also widely considered the penultimate pure OO language.

> Pretty much all of the OO languages are walking back OO features

About the only feature I can think of for which this is somewhat true is inheritance, and that's because we realized that aggregation is often a better model, and can be easily supported by the language to be no more verbose. But it doesn't fundamentally change OO - it was never about inheritance first and foremost; I mean, prototype-based OO doesn't even have that conceptually.

> and trying to add type classes (contracts)

In most OO languages, these typically naturally evolve out of interfaces.

> functional pieces, mapping and filtering a la linear data transformations.

This is not contradictory to OO in any way. Again, Smalltalk has had "select" (filter) and "collect" (map) from the get go.

Minor question: what does the word "penultimate" mean in your comment?

Not only do you have to figure out what’s going on in the JVM you also need to duplicate your effort to figure out how the JVM is running on the host.

Isn't that true for all other languages you mentioned? python, erlang, php, golang bundles a runtime, etc..

It’s a spectrum. Java is at the very end with Erlang. I have a lot of domain specific knowledge of The Beam. Go on the other hand has a very lightweight runtime.

Very true. Newer languages seem to be moving back towards native binaries. The promised advantages of JIT compilation have faded with improvements to compilers and profile driven optimization.

Go and Rust are interesting to follow. A highish and low level language both using lightweight runtimes

Java would take the cake in almost anything speed measure you mentioned. Golang is the only one comparable in memory throughput and latency. Java with async IO like Vert.X can do higher concurrency than Erlang. As can Go.

IMO Java is the most well rounded language, but I'm not trying to convince you of that.

Also there's nothing with java that stops threads from being restarted. In a modern web framework it's virtually impossible to crash the JVM. You just crash a thread, at most (usually the framework catches the exception and it doesn't even do that). Java is also hot reloadable if you use the right framework.

Your tooling argument doesn't make much sense IMO. You can attach to a Go binary but that's about it. Attaching to a VM or interpreter will tell you almost nothing. I would wager you haven't used a Java profile if you're making these arguments. It's vastly superior to anything but maybe C#

Can do higher concurrency is a nonsensical phrase. Please show me your benchmarks versus Erlang at 10M web socket connections.

You’re not understanding what I’m talking about when I say restarting. I’m talking about the JVM process. I also just said hot reloading is counter to modern practices.

You’re not understanding what I told you.

Newer versions of Java cache compiled classes. The startup time is maybe 10 seconds for something big running Java 11.

You can also compile AOT for some performance loss at runtime but zero startup time. Android has been doing this forever but you can also do it on a PC using Graal.

And yes Java will destroy Erlang at concurrent connections if you use an async framework like Vert.X or fibers using Quasar/Comsat. It has lower per thread overhead than Erlang and runs code faster in general.

Both Java and Erlang will max out Linux TCP connections before running out of steam so this is kinda academic though

If you want to build systems at scale you want to use a lot of commodity boxes, not a few huge or 'special' machines.

I don't drool over the raw horsepower of each of my individual boxes.[1] All I care about is that I can cost effectively create a cluster of them to serve the application's needs.

Because of this, even if Java could not handle as many concurrent connections, you might still chose it over this fabled 10M socket erlang server you keep talking about.

You might chose Java because:

* It is well understood and has a lot of mature libraries surrounding it.

* You can easily hire people to work on it.

* It is a stable language.

And so on...

I would summarize your original post like this: "I don't like Java, I prefer other things," which is fine as far as it goes, but then you basically say: "Therefore, everyone should also prefer the same things I do," which does not follow.

[1] I never particularly cared how many fps I can get on my machine, and I'm not that chuffed about my machine's geekbench score. IMHO this obsession with hardware metrics beyond diminishing returns is mostly a gamer thing.