Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

351–360 of 557 posts

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

#351

Post by tannhaeuser »

falcolas wrote: post #34
throwawaymaths wrote: post #23

Earlier quoted context omitted.

Corollas don't come with all sorts of weird (now aging) buzzword-driven preferences like nudging you towards xml, factories, etc.

Personal rant: I've never understood the hate towards XML. It's a practical and flexible markup language that does not depend on whitespace or quoting every bloody thing. Plus, every markup language invented since has had to re-invent XML things that, surprise surprise were actually needed. Paths, schemas, comments, etc. I get frustrated with JSON because of things I could do in XML that I can't do in JSON without br…

I think Spring, Maven (and ant before), JSP, and J2EE descriptors gave XML a bad name, as fields of application where a markup language wasn't adequate. XML was meant as a simplification of SGML to formalize and extend HTML on the web, but was overhyped as serialization format for everything and anything for all the wrong reasons, among them that XML sold well to management.

It can be argued that, despite not a primary use case for markup, XML has found a useful niche in b2b service payloads and government, banking, and health services in particular. The use case for those might have been "web services" in the original sense where simple CSS-like transforms and styles are applied to payloads for display in browsers, but the JSON community hasn't brought forward a serious replacement for XML Schema, so XML payloads kindof keep sticking around in long-term projects.

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

#352

Post by vasilakisfil »

xxs wrote: post #288
cozzyd wrote: post #255

Earlier quoted context omitted.

The developers of apache httpd, nginx, postgresql, redis, among many others?

you really dont need redis if you have java. I see zero reasons to offload my datastructures via TCP, instead of have them locally. If need be, replicated them.

Usually you need redis to scale up horizontally, meaning with multiple servers/processes, and still keep consistency in your data. In general redis is a very useful tool that provides various features, even pub sub.

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

#353

Post by MaxBarraclough »

ransom1538 wrote: post #300
kentonv wrote: post #274

Earlier quoted context omitted.

Oh, please. I once worked on a Java-based server at Google that had to answer requests with millisecond latency. In order to achieve this, the server had to block garbage collection most of the time. Periodically, each instance of the server would ask the load balancers to stop sending requests to it, so that it could then safely run the garbage collector, and then ask for traffic to return. We likely would not have…

Google should have picked a real language: php. When script is completed all resources are freed, let the OS figure it out. No manual GC drama.

That's a strategy called arena allocation or region-based memory-management, and it doesn't have to be tied to the lifetime of a process or interpreter.

There's nothing special about PHP, which if I understand correctly uses reference-counting with conventional garbage collection to handle reference cycles. As I understand it this strategy is non-competitive in all performance metrics, compared against modern garbage collectors.

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

#354

Post by MaxBarraclough »

exabrial wrote: post #319
lliamander wrote: post #133

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,…

> no global gc pauses, low-latency Java also has this for at least a few years now. G1GC and ZGC in JDK17 offer no global stops unless absolutely necessary, and ZGC even has latency targets.

Also Shenandoah. Those Java garbage-collection folks have been busy recently.

Or is it that people interested in doing ground-breaking garbage collection research tend to target Java?

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

#355

Post by lliamander »

kelnos wrote: post #334
bjourne wrote: post #245

Earlier quoted context omitted.

Imo Erlang's scalability benefits are oversold. Unless you're a national carrier the performance of Java far outweighs Erlang's scalability. Instead, Erlang's undersold killer feature is its robust support for hot code reloading. It enables almost any part of the system to be upgraded without affecting running processes. Other languages and VMs can't do that because they optimize call frames differently and rely on m…

I feel like Erlang somewhat missed its timing window on this, though. With platforms like AWS, GCP, and Azure, you don't really worry about upgrade downtimes, because you just roll out a new fleet of servers (or new fleet of pods, if you're using something like Kubernetes), and then drain the traffic from and decommission the old fleet. Certainly there are a lot of companies managing real physical servers, where this…

I work in an AWS/K8s-heavy shop, and it is pretty great, but we have a fairly sizeable engineering team.

Managing K8s microservices is easily an order of magnitude more work than managing them in Erlang as applications.

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

#356

Post by ralmidani »

nick__m wrote: post #341
pwinnski wrote: post #291

Earlier quoted context omitted.

I don't think this is an issue with Java, it's an issue with Spring. I'm baffled by the popularity of Spring.

Old school xml based Spring is horrible and if that was your only exposure, I understand your aversion. But spring-boot has an almost zen like quality once you get that it favor convention over configuration. When I was a Java developer, I'd usually use spring-boot with the following dependencies to make the experience better: - lombok: to generate the boilerplate: constructors, getters, setters, equals, hashcode...…

Sorry, but the popularity of tools which generate boilerplate for you is, in my opinion, one of the biggest indictments of the whole ecosystem.

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

#357

Post by dymk »

vbezhenar wrote: post #267
dymk wrote: post #15

Earlier quoted context omitted.

That may be true, but JavaScript forces you to bisect your libraries (and functions) into Those that Understand Async and Those That Don't [0]. There appears to be no path forward if you want to avoid that. It's very difficult to write generic, reusable higher-order code that shouldn't care if it's doing a sync or async operation. Java at least is building a foundation in the right direction. [0] - https://journal.st…

If you mean that you can't write `map` which would work for sync and async functions with the same code, that's extremely rare problem IMO. If you really need that and don't want to write two versions of code, you can wrap blocking code with promises and use promise API from now on.

It's not at all a rare problem if you work in codebases involving async code. Many `Promise` APIs exist solely to work around that wart. Higher-order functions are the bread and butter of JS, and increasingly Java (especially modern Java).

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

#358

Post by 62951413 »

abadger9 wrote: post #22

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…

I believe it's unfortunate people judge the JVM ecosystem by Java. Scala and Kotlin are so much more attractive options if you write code for a living. Between this and the devolution from maven to gradle it's not a surprise junior developers are JVM-shy.

I see companies downshifting to unmaintainable toys such as Python even in data engineering circles. It's really odd that mobile developers with Kotlin (and front-end ones with Typescript) are getting ahead of backend ones in adoption of modern languages.

Once Loom and Valhalla get merged to an LTS the remaining vestiges of bad old Java will have been gone. I really hope Graal goes mainstream too. That will hopefully blow out of the water the golangs of the world. But those are platform-level improvements any JVM language will benefit from.

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

#359

Post by bberrry »

topspin wrote: post #62
e67f70028a46fba wrote: post #26

The biggest thing Java is missing is full hot swap. Its been implemented via the dcevm but, inexplicably, has been ignored by both sun and oracle. This one, existing technology would make Java DX on par with the dynamic languages

> The biggest thing Java is missing is full hot swap The biggest thing missing in Java is an answer for the billion-dollar mistake. Real world Java is plagued by NPEs because a lot of Java is written by low caliber programmers. Java + functional error handling would be a monumental improvement.

Kotlin solved that in a good way IMO. That alone makes it worth switching

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

#360

Post by akra »

lenkite wrote: post #167
jeroenhd wrote: post #29

Earlier quoted context omitted.

My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Before, .NET only ran on Windows which disqualified it from many serious applications server deployments. Today, this is no longer the case for everything but cross platform GUI libraries, and even those are an option if you're okay with not having Linux support. It's more akin to the old car you had just before…

> My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Might want to give some evidence of this. Also, C# has no plans of green threads. It went the async/await way which is a pain.

I don't feel its the biggest pain to be honest, at least not in the .NET world where the Async API is so persuasive. I don't think the paradigm would suit Java - the API changes to make it ubiquitous would make it take too long to add value. People seem to code with it (the Async workflow) just fine, and it's a decent model to write some async algorithms. For example firing a few in parallel, starting a task but leaving it running and awaiting it later, etc. The advantage for me is that there is some overhead with Async dispatch - the abstraction of coroutines, green threads, etc is cheap but isn't free and maybe seeing where it could prop up isn't always a bad thing. There is value in knowing that an operation could be async, at least in my time programming and it has a cost that you may not want to pay, defer, delegate to someone else, etc especially in hot loops (e.g. IO).

As a single anecdote working in both languages in my current job in a cross platform environment when having to write Java it feels just that bit more painful, and just that bit harder to get the same performance for the class of apps I write. YMMV.

Post reply on HN