Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've seen Java described as made for companies to be able to rotate out mediocre programmers as efficiently as possible without letting them mess things up easily, and it makes a lot of sense from that perspective. Barebones semantics to the point of being Spartan (can't even define your own operator overloads), easy to take another class and copy it with small modifications but not mess it up for anyone else (inheritance)..

Then there's C# which most anyone who's enthusiastic about software dev will find far nicer to work with, but it's probably harder for bargain basement offshore sweatshops to bang their head against.



I really don't think this stance aged well, even if it was closer to true way back when. IMO the spartan language is now Go, and Java has ended up the boring open source workhorse. The jvm is very performant compared to many stacks these days (python Ruby node) while still having a very compelling concurrent programming story, and has a lot of nice language feature things ever since 8 and onwards. Lambdas and streams are the big 8's, but I think virtual threads growing up and even new things like scoped variables are really compelling reasons to build a new thing in java right now.


You need just the right amount of expressivity in a language, so that it is hard to abuse, but still allows writing easy to use libraries.

Java has went over this evolution, implemented generics, lambdas, etc and I believe it strikes a very good balance in not being overly complex (just look at the spec - it's still a very small language, compared to its age, unlike C++ or C#).

Go tried to re-invent this evolution, without having learnt Java's lessons. They will add more and more features until their "simple" will stop applying (though I personally believe that their simple was always just simplistic), simply because you need some expressivity for better libraries, which will later on actually simplify user code.

Also relevant: https://www.tedinski.com/2018/01/30/the-one-ring-problem-abs...


The problem with the JVM, compared to Go, is the GC; it requires a lot of reserved memory. Go programs use far less. And the SDK is bulky, which can be a problem for container images - although arguably it should be considered irrelevant, as you only download base images once, if done correctly.


You're not supposed to use the runtime directly these days. jlink allows you to strip unnecessary things (like documentation for the runtime itself), extract only those parts of the runtime you need (though your project must use modules to support that), and then aggressively compress it all getting a pretty small package that runs on an empty OS with no dependencies other than libc. It's still a bunch of files, so for good user experience you would have to ship it as a container (or something like .exe or appimage), but it's really close to Go in terms of size.

https://www.baeldung.com/jlink


It's a configurable property, and Java has a bunch of GCs to begin with.

Also, not using as much memory in these types of GCs is a direct hit to performance. And this actually shows splendidly on GC-heavy applications/benchmarks.


We were paying a million a month for a custom high performance GC for a little bit but we were able to get off that with a lot of development effort and get our five 9's latency under control.


I tried and gave up on getting Keycloak to use less memory. 500-1500 MB for a server with less than 10 concurrent users is ridiculous. And that's even using an external database.


What did you try? As a last attempt you can just check visualvm to see the actual memory use, add a few percent headroom and set that as heap size.


Much less of a problem in .NET (its GC tuning sits somewhere in between the two, especially when SRV GC + DATAS is in use, like in container scenarios, where Go is funnily unaware of limits set by cgroups and needs an external package to fix it). It does pre-allocate more memory than Go per se but in return yields much, much higher allocation throughput out of box. Java allows for even higher allocation throughput, having multiple more sophisticated GC implementations but as you said is not very good at reducing sustained RSS used by an application.


> Java has ended up the boring open source workhorse.

This statement surprised me. I can't even remember last time I ran any opensource Java.


Off the top of my head? Bazel is the Java program I use the most. Hadoop/hive and similar stuff also heavily Java but I'm not sure how much that's in use anymore


I'm not saying there's no Java in open source. And I'm aware of the projects you mention. I don't run them though. And they definitely don't qualify as "the boring open source workhorse".

There are a couple of Java projects, and even one or two kind of successful ones. But Java in open source is very rare, not the boring workhorse.

If I worked on a project that used Bazel, then sure, I'd use Bazel every day.

But which is "the boring workhorse" of open source, if I gave you the option of Java, Make, Linux, gcc, llvm, .deb, would Java really be "the" one?

Sure, maybe you could exclude most of those as not being "boring", like llvm. But "make" wins by any measure. And of course, it's almost by definition hard to think about the boring workhorse, because the nature of it is that you don't think about it.

Checking now, the only reason I can find java even being installed on my dev machines is for Arduino IDE and my Android development environment. Pretty niche stuff, in the open source space.


Most Java applications nowadays are based 100% on open source stack with hundreds of libraries and frameworks and Java dominates enterprise space, so it is a huge open source workhorse, just more obscure than Linux, gcc etc.


Ok, we clearly have an extremely different definition of the word "the" workhorse of open source.

It doesn't mean "more than zero projects are Java based". Nor does it mean "most (opensource?) Java applications are based on open source". That latter is borderline circular, only Oracle legal shenanigans makes it not circular.

> and Java dominates enterprise space

I said nothing about enterprise. Clearly Java is HUGE in enterprise.

> so it is a huge open source workhorse

That sentence took a strange turn. Enterprise, and then back to open source?

> just more obscure than Linux, gcc etc.

Obscure? I'd expect Java to be about as strong a brand as Linux. Among developers in general I'd expect gcc to be orders of magnitude more obscure. There's no programmer out there who has not heard of Java, but many have never heard of gcc.


> Ok, we clearly have an extremely different definition of the word "the" workhorse of open source.

You said what it is not, but forgot to share your own definition.

>That sentence took a strange turn. Enterprise, and then back to open source?

What makes you so surprised? One does not exclude another, enterprise users are users too. Most of things in Java world aren’t client-side, so many users won’t observe them directly, but open source Java technology is doing a lot of work for them, constituting significant share of the code base.


Ghidra also


Half of the internet is literally running that.. like unless you deliberately avoid Java stacks, you will come across it. It's one of the top 3 ecosystems in size, with JS and python being the other 2 contenders.


Internet? Yes. But that was not the topic at hand.


The lack of operator overloading is a bit annoying but in practice seldom a real problem. An operator is just a funny looking method. So what.

There are worse fundamental problems in Java. For example the lack of a proper numeric tower. Or the need to rely on annotations to indicate something as basic as nullabilty.


It’s a massive annoyance when working with any sort of numeric code. Or custom collections. Or whatever else the standard library enjoys that nobody else gets to use.


> easy to take another class and copy it with small modifications but not mess it up for anyone else (inheritance)

That sounds like a recipe for disaster though, as it generally makes code much harder to read.


Agree, inheritance tends to be overused when programmers try to get too clever. The flatter the class hierarchy the better


I remember the times on one of professional forums, where there was lots of questions about architecture in C# sections and almost none in Java section. Abundance of tools creates abundance of possibilities to get confused about what’s right. In Java many design decisions converged to some dominant design long time ago, so you no longer think about it and focus on business. It’s sometimes as bad as getter verbosity (thankfully record style is getting traction), but in most cases it’s just fine.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: