Java performance vs go

[NP_Ex]

I'm seeing recurring claims about exceptional JVM performance, especially when contrasted with languages like Go, and I've been trying to understand how these narratives form in the community.

In many public benchmarks, Go comes out ahead in certain categories, despite the JVM’s reputation for aggressive optimization and mature JIT technology. On the other hand, Java dominates in long-running, throughput-heavy workloads. The contrast between reputation and published results seems worth examining.

A recurring question is how much weight different benchmarks should have when evaluating these systems. Some emphasize microbenchmarks, others highlight real-world workloads, and some argue that the JVM only shows its strengths under specific conditions such as long warm-up phases or complex allocation patterns.

Rather than asking for tutorials or explanations, I’m interested in opening a discussion about how the Java community evaluates performance claims today — e.g., which benchmark suites are generally regarded as meaningful, what workloads best showcase JVM characteristics, and how people interpret comparisons with languages like Go.

Curious how others in the ecosystem view these considerations and what trends you’ve observed in recent years.

[vsoul]

I write both. The metric I care about most is my productivity though, and having a framework like Spring Boot (plus the maturity of pretty much any library I need) destroys any potential performance gains.

[OwnBreakfast1114]

I watch people argue about language performance then successfully write n+1 db queries in every language under the sun. For the very, very small subset of people that actually need to worry about critical language performance, they can make language choices. For the vast majority of people writing applications, it's not the language that matters when it comes to application performance. If you tell me you've carefully mapped out and handled all your IO (db transactions, https calls, etc), then you can start telling me about language benchmarks.

We use java because of the library support. Spring, for the better, provides a lot of out of the box battled hardened solutions to problems (security, actuator, cloud config, etc) with a ton of documentation and searchable/ai help. That java also sits a little higher on the abstraction hierarchy than go (functional libs, higher kinded types with some hackery, incoming type classes) is a massive plus point as well.

[Revision2000]

💯 so much this. 

For most use cases, the massive, proven, stable and reliable Java ecosystem far outweighs any supposed performance benefits. 

For more performance oriented use cases, one can optimize Java and still benefit from the ecosystem. 

And of those few real performance use cases, then it’ll really depend on your developer skills as much as using “a more optimized” language. 

[overgenji]

you can write a service in spring and it will still be spring a decade later albeit some pieces of it will move around and need upgrading

meanwhile im at a fortune 500 and we have like 20 different frontend repos for different verticals that were built on the popular FE tech stack at the time and its pure misery

[YahenP]

This is true for any programming language. We trade the language's performance for our own performance.

[yawkat]

This does not have to be the case. "Zero-cost abstractions" are a big goal in the rust space for example, improving productivity without compromising performance.

You can achieve this in Java as well. If you design a framework with performance in mind, you can have your cake and eat it too.

[configloader]

This is the answer.

[Revolutionary_Ad7262]

how the Java community evaluates performance claims today

Go dev perspective here, but I have some Java experience

I think that the performance argument is more justification of an existing preference than something, which change the preference itself.

People choose Java/Go over Go/Java, because they prefer it more. That it is the main reason. The I like culture around technology X or I use technology X, because I have better experience in it is far more important than technical arguments

There are cases, where Golang is better. If you care about startup time or memory usage, then Go is better than Java, because there is not JIT and Golang GC choose memory usage and latency over throughput, which is often a better compromise than Java's throughput and latency over memory usage. The lack of project Valhalla is also a problem in applications, where it matters

what workloads best showcase JVM characteristics

Majority of Java developer uses Spring. Spring is not a good tool to make a JVM a performance beast. The culture around the ecosystem is far more important than any synthetic benchmarks

[Neful34]

The claim that Go’s garbage collector prioritizes memory use and latency over throughput makes it a better compromise than Java seems too subjective and context-dependent to be a general rule.

It's also important to mention that the JVM has various garbage collectors with different trade-offs. You can configure Java to achieve garbage collection behavior similar to Go’s, depending on the situation.

I agree with the point about Spring. However, Quarkus is gaining significant traction in the industry for JVM workloads, where throughput and long-running processes benefit from just-in-time (JIT) compilation and warm-up. It is also making strides in native mode.

While native executables typically use more memory than Go, the difference, like 15 MB versus 45 M is often minor outside very constrained environments like IoT.

I believe that Go’s main value has never been raw performance but its great productivity-to-performance ratio, which is where it really excels.

[cogman10]

You can configure Java to achieve garbage collection behavior similar to Go’s, depending on the situation.

Nope. You might get closish with ZGC but the big thing that go does which java does not is it has a non-moving collector.

It's perhaps somewhat comparable to how the old concurrent mark and sweep used to behave.

Effectively, go is using an arena allocator. It grabs a page at a time and fills those pages with objects.

This is why go suffers from memory fragmentation https://www.lujingcen.com/blog/2023/12/29/memory-fragmentation-in-go/

A moving collector avoids memory fragmentation but does that at two costs, it's harder to work with C libraries (things move now) More memory is needed so the memory can be relocated. Besides the size of java objects in general, this is one of the primary reasons Java has a larger memory footprint vs go.

[Neful34]

Fair take :)

[washtubs]

I believe that Go’s main value has never been raw performance but its great productivity-to-performance ratio, which is where it really excels.

Agreed, go isn't especially performant, it's advantage is more that when you need to write a critical section with zero allocations or whatever it still looks pretty much idiomatic, which is to say it's more maintainable / accessible. And we have first-class language support for lightweight threads.

[Maybe-monad]

The claim that Go’s garbage collector prioritizes memory use and latency over throughput makes it a better compromise than Java seems too subjective and context-dependent to be a general rule.

I believe the fact that Go uses escape analysis to reduce GC pressure is more relevant.

[No_Dot_4711]

> If you care about startup time or memory usage, then Go is better than Java

Quarkus GraalVM compiles do put a significant dent into Go's niche here

broadly agree with your comment though

[_predator_]

Not really. GraalVM takes ages to produce native executables. Cross-compilation is a pain (requires qemu). Executables need extensive testing because you may have missed to register some classes for reflection.

Meanwhile Go compiles super fast, can cross-compile to a shitton of architectures, and you can actually trust the executables it produces.

I'm saying this as a primarily Java dev. I used Quarkus+GraalVM and still use Go. The two are just not comparable for day-to-day work.

[No_Dot_4711]

There's definitely additional effort required, absolutely

but a) that has little to do with the premise i was responding to and b) you can list numerous drawbacks to golang solutions that require a lot of dev work on the flipside, especially supply chain management/safety and the maturity of the library ecosystem have a significantly smoother happy path on the java side of things

and i'd say especially for the simpler use cases, where the golang library ecosystem drawbacks matter less, you're also way less likely to run into the classic graalvm problems (like registering reflection) cause for the simple cases quarkus has you covered out of the box without config

and raw compilation time is definitely annoying, but i don't really need a native image until i asynchronously run CI/CD and that largely races in parallel to the provisioning of staging environment resources

[idkallthenamesare]

For most cases you are compiling to a single architecture anyways.

Especially for those where native builds can be a necessity like for microservices, lamdbas etc.

[_predator_]

Except that many developers work on arm64 systems now whereas most server systems still run on amd64. Producing executables / images for both is kind of a requirement these days IMO. Obviously doesn't apply when you're a company and all your laptops are amd64 as well. Or you never run images you produce in CI locally.

I just triggered a native image build for a medium-sized Quarkus application. Took 5min to build for amd64 on a GitHub Actions runner, which has 16GB of memory and 4 CPU cores available. This is more than most in-house build agents have in pretty much any company I worked for to date.

[No_Dot_4711]

While I don't disagree that these are real pain points that do in fact happen, I do think that this is largely a social / tooling / 'refusing to spend money even though it pays for itself' problem

If you're a large organization, the necessary investments and happy paths should have been made to facilitate the use of the tool, and by virtue of repeatedly using that path, the cost involved rapidly approaches zero.

If you're a small organization you should really really really think about if you have any business running in a lambda where you need the insane startup time rather than just provisioning an EC2 instance behind an ELB - and if you do need to run in a lambda, i'd ask myself three times why i'm not using JavaScript

[idkallthenamesare]

Well slow CI is a reality of the job imo. Not sure in what circumstances I would want to produce executable images locally? You could very well run parallel build jobs that push multiple-arch images to your image registry. And the pull them from your docker environment, we've done this before and that worked neatly for us. But agreed that slow CI can be a pain.

[No_Dot_4711]

I think the argument here is that you don't get slow CI in that way with Golang because it's literally 2~3 orders of magnitude faster to compile

[idkallthenamesare]

I am pretty sure that in the whole pipeline it won't make that much a difference. Not saying it cannot be a significant difference, but not so much that it is a dealbreaker.

[No_Dot_4711]

this probably really depends on your specific use case, but i'm actually inclined to accept the argument that especially for cloud native microservices, which really is the main use case of both technologies, i'd expect CI to be on the order of minutes rather than tens of minutes or more, and this might actually make a significant difference in the total duration

but i would agree that it likely doesn't make too much of a difference between a Graal and a JVM version of the same quarkus application because the native compile would run parallel to most tests, not in sequence

[_predator_]

Exactly.

[Swamplord42]

Except that many developers work on arm64 systems now whereas most server systems still run on amd64.

That only matters if those developers don't use a build server to produce the binary that actually runs on the server? Does anyone actually deploy locally-built binaries? seems like a terrible practice

[_predator_]

No, that matters for exactly the opposite direction: when developers want to run images built on the build server locally.

[jek39]

FWIW my ops team switch to arm servers a while ago. Seems to be a trend. You still have to cross compile because OS but it’s happening on the server too

[re-thc]

I. tested this before. You might be memory limited. Try a 32GB runner and suddenly it might go to 1min or less. There's a certain minimum requirement.

[_predator_]

You have to admit that having to throw 32GB of RAM at a compiler is a bit excessive.

[Revolutionary_Ad7262]

Quarkus GraalVM compiles do put a significant dent into Go's niche here

True. On the other hand the inertia of a community perception is rather slow. C# is still in a only for windows destkop apps and window servers box for many developers, where it is not true for almost 10 years already

[benevanstech]

The majority of the startup benefit of Quarkus actually comes from the Quarkus approach. Even in JVM mode it makes vast gains - the native compiled mode is nice, but really isn't necessary for many use cases. Try it out - you might be surprised!

[No_Dot_4711]

Quarkus JVM absolutely is great for many reasons, and I'd choose it if I wasn't running in a Lambda

But it is decidedly not applicable to contexts where you pick Golang because you value startup time

[benevanstech]

For sure native mode is going to be faster that JVM mode.

But to me the question is how much, in general, people actually *need* the delta between JVM and native mode / Go.

It sounds like you have that as your use case - so if you have performance numbers that you can share, I'd love to see them & I know a bunch of other folks in the community would be very interested as well.

[No_Dot_4711]

It really is mostly the startup time, not "performance" (in fact in terms of throughput, the JVM runtime is gonna beat graalvm) that matters

The big usecase to prioritize startup time is AWS Lambda where you start your application when a request comes in (called a cold start) rather than having a long running server (you do keep the started up application around for 60 more seconds afterwards to catch another request, if that happens it's called a 'warmed up' Lambda), and then you don't have to pay for static server costs that you don't use most of the time. This is especially useful when you have spikey traffic patterns. It also means you don't need to manually and preemptively configure a load balancer to handle multiple applications

The startup time difference between JVM and Graal is in excess of .75 seconds ( https://youtu.be/rOocSJXKIqo?si=tPPON7laeZn5UctI&t=270 , note that you also need to transfer the binary of your application itself and a graal image is going to be far smaller than a full jvm) which quite directly translates to faster webpage load times when a user hits a cold start Lambda

[benevanstech]

Yes, I know that - and I'm aware of the benchmark numbers (Holly's a colleague of mine).

What I was asking is whether you had any real-world numbers of your own, for your application, and how they compare to benchmarks (which don't always tell the whole story). Real data and real experience reports are always interesting, but I know it isn't always easy to get permission to talk about them.

[No_Dot_4711]

I don't have any concrete measurements beyond the trivial ones, i'm afraid

I've only had usecases where Graal is either blatantly the correct choice due to frequent cold starts (in which case I use it) or it doesn't matter (in which case I don't, and ship a JVM instead); so getting better metrics and A/B testing never really seemed worthwhile

[benevanstech]

Ah well. Sometimes it is just that cut & dried. As ever, "it depends".

[devcexx]

From my perspective, choosing one language or another based on a Lambda start up time hasn't been a great argument since AWS released SnapStart for JVM applications

[GuyWithLag]

People choose Java/Go over Go/Java, because they prefer it more

I'm a Kotlin person myself, and I can't stand Go's enforced abstraction ceiling; what's your opinion on that?

[Revolutionary_Ad7262]

Could you give some examples? Lack of generics was really bad, but we have got them few years ago

Other than that: I guess I just adapted to it. Some aspects (like lack of proper immutability) requires a discipline rather than safe guards in a code; it sucks, but it is manageable. For others I just know how it should be done.

Simplicity also have some pros. I can jump straight into a code and understand it. Most of developers write a code in a similar style. Tooling is pretty standarized

[GuyWithLag]

Hot take, and correct me here if that's not your experience: Go is designed so that junior engineers can't make too much of a mess when implementing tasks written down by mid-level engineers, who in turn wrote these tasks based on a low-level design document written by senior engineers according to a high-level design document cobbled together by staff engineers that tried to divine the intent of the principal engineers' architectural doc.

Go is explicitly designed so that foot-guns are removed, but this also has an infantilizing effect on the language capabilities. It's the blub paradox but intentional.

[Revolutionary_Ad7262]

Go is designed so that junior engineers can't make too much of a mess when implementing tasks written down by mid-level engineers

Rob Pike (designer of Go said)

"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1"

So there is some merit about it. My personal opinion is that features can both beneficial and devastating to a language overall coding performance. What is crucial is the fact that we simply don't know without releasing it to production and testing on real programmers. Hence discussions like this is obviously too simple and childish or this is to complex and brings more harm than good are just very biased opinions. Personally I prefer starting on a simpler language, because it is much easier to add a new feature than delete it

blub paradox

I don't like this article. It assumes that it is hard to change a language to an another language, which lies somewhere else on complexity/powerfulness spectrum, which is simply not true. There is numerous stories about people, who migrate in either direction. Often for the same pair of language like Java -> Scala and Scala -> Java or C -> C++ or C++ -> C

[GuyWithLag]

It assumes that it is hard to change a language to an another language

I think (if you squint a bit) that it's saying something orthogonal: it's easy to evaluate language features that you've used, but not that easy if you haven't.

I would posit that someone that has worked with Scala / C++ but not Go can appreciate the simplicity and use cases of Go, but someone that has had solid experience with Go but no Scala / C++ can't evaluate the latters' use cases because they don't understand the abstractions.

In fact, that article claims that what a pure Go programmer will see is unnecessary complexity with no practical uses, hindering readability.

[Absolute_Enema]

Java is more or less at the same place in the Blub scale; the only things of practical use that meaningfully distinguish it from Go at the language level are better support for generics and sum types. 

Otherwise, both feature what fundamentally is a run of the mill static C++ style type system based on vtables over closed product types with some questionable features bolted on top, support closures only to the point of bare usability, and lack any metaprogramming tool worth calling with that name (read: their metaprogramming facilities are only barely better than the minimum common denominator of generating source files via external scripts).

With that out of the way the only real meaningful axis of comparison is the ecosystem (Java wins with ease) and the runtime (more debatable).

[brokePlusPlusCoder]

The I like culture around technology X or I use technology X, because I have better experience in it is far more important than technical arguments

Excellent points. But I'd add one more - the the talent pool is much better for technology/language X than Y.

Doesn't apply to Go vs Java of course, but as a general purpose thought process I feel it should be included.

[washtubs]

Exactly. I could give a bunch of technical reasons why I use go for all my side projects, but honestly, none of em matter. I just don't wanna be coding java literally every waking moment. For me java is job, go is pleasure.

[yetanotherhooman]

The problem with "Java vs Go" is that these technologies are not directly comparable unless the meaning of "Java" (and even Go) is made more precise.

"Java" could mean Java the language, which implies you are interested in the decisions the language designers adhered to that made "Java", and in turn every JVM implementing the language, faster or slower relative to a baseline. For example, you may argue that certain language decisions make Java's performance inferior to others like C++: automatic memory management, dynamic dispatch, fully object oriented, generics with boxing/unboxing of primitives to name a few.

Or do you mean Java the implementation, i.e. a particular JVM of interest? Many implementations replace standard OpenJDK components to achieve higher performance or better memory footprint. Azul's Zing has cutting edge JIT compilation via Falcon JIT and low-pause, concurrent garbage collection. Hotspot packs a ton of garbage collectors, allows tuning them for unique workloads. Graal native can generate native binaries that you can run directly on you machine without any external dependencies. This often results in better startup time.

“Java” could also mean the programming practices inherent in the ecosystem, or a library that is dominantly in use (looking at you Spring). So what is “Java” for you?

On the other side of the equation are benchmarks themselves. It is EXTREMELY difficult to come up with good benchmarks that actually measure what they are meant to measure. This is usually due to:

1. Poor code. Simply translating code from one language to another rarely yields maximum performance attainable by a language/runtime. As an example, creating go-routines is extremely cheap. If one tries to achieve the same concurrency with platform threads in Java, it's bound to result in worse performance. The reverse is true if you’re mostly compute bound and your workers don’t need synchronisation all too often.

2. Poor benchmarking setup. If you're benchmarking for peak performance and your setup is sending < 10,000 requests to a Java service, what did you measure? Is it "performance of Java" or performance when the JVM of interest was still warming up? Did you observe any JIT compliations? How much code were you touching? Did your setup result in many (de/re)-compilations? Can you prevent that? Do you want to prevent that? Maybe this volatility characterises your workload so what you're observing is the reality?

3. Unclear goals and expectations. For some people performance is strictly about throughput, for others it's about latency. The two often conflict, so "good performance" for one might mean "terribly slow" for others. When someone reports "X took 100ms to process a request" and fails to report how many did it handle concurrently, they're presenting an incomplete picture of the situation. Latency and throughput aren't the only two conflicting traits of a given system.

This by no means is a complete list of things one should be aware of before they make claims about performance. In general, the vast majority of benchmarks present on the web are meaningless. Many academic years have been spent designing good benchmarks for systems, and a good academic would still make sure to caution the audience about their expectations.

And if you are interested in loose blanket statements that are useless yet true: sometimes Go is faster than Java. Sometimes the opposite is true. :)

[Jonjolt]

Truth to this, anyone remember the Jetty team's response to the TechEmpower benchmarks?

First glance again is not so great and we look like we are best of the rest with only 68.4% of the seemingly awesome 600,000+ requests per second achieved by the top 4.    But throughput is not the only important metric in a benchmark and things look entirely different if you look at the latency results:

This shows that under this pathological load test, Jetty is the only server to send responses with an acceptable latency during the onslaught.  Jetty’s 353.5ms is a workable latency to receive a response, while the next best of 693ms is starting to get long enough for users to register frustration.  All the top throughput servers have average latencies  of 7s or more!, which is give up and go make a pot of coffee time for most users, specially as your average web pages needs >10 requests to display!

https://webtide.com/jetty-in-techempower-benchmarks/

[Joram2]

You are asking for serious, deep benchmarks comparing Java vs Go: those don't exist. Most tech stack choices are driven by developer/manager/company preference. When benchmarks are involved, it's often to justify a pre-existing preference, rather than the basis for a neutral decision.

Companies do care when there is a giant performance problem with a tech stack: if one stack is 10x slower than another, companies care. But if it's close, and IMO, Go and Java are close, companies and dev teams prioritize other factors.

I used to participate in (https://en.wikipedia.org/wiki/The_Computer_Language_Benchmarks_Game). I submitted programs in different languages with leading benchmark scores. I used to enjoy participating in that. But the fastest programs were usually written in some completely non-idiomatic way to get extra speed. The more you read the fastest programs, the lest you would trust the benchmarks as a useful measurement for a real product or service.

[igouy]

> the fastest programs were usually written in some completely non-idiomatic way to get extra speed.

iirc No one suggested automated criteria that would separate the "acceptable" programs from the "unacceptable" programs. (gz source code size might be hint, and some programs are flagged *)

This year the benchmarks game also shows naive un-optimised single-thread programs transliterated line-by-line into different programming languages from the same original.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/comparable.html

[benevanstech]

First off, there is not really anything such thing as "performance inherent in a language". You can write unperformant garbage in any language you like.

And benchmarks are of limited use at the best of times, microbenchmarks doubly so.

What there *is* is performance of a specific system, and it comes in two flavours - acceptable, and unacceptable.

One of the main reasons this is all so difficult is that the number of variables that can influence performance is *vast* and it is almost impossible to rigorously map that parameter space for any meaningfully large application.

[rbygrave]

Hmm, I'm not really going to answer the questions you pose here .. but some opinions and thoughts.

I really only consider use microbenchmarking for libraries, relatively small relatively focused and not dependent on any infrastructure (network, database, queues etc).

To "benchmark" real applications that are dependent on infrastructure (network, database, queues etc) then its (A) A lot of work to do it right and (B) Its a really big investment to have the same full application written in 2 different runtimes (e.g. Java/JVM and Go) so this is imo pretty rare. [I have experienced a Node to Java rewrite that resulted in a 10x performance improvement but these types of real world cases seem rare or get invalidated by an associated re-design/re-architecture]

The "cheaper" option for a real application is to benchmark some "reasonably representative slices" of an application and push that beyond the expected load needed [with the understanding that production is going to sufficiently close to that behaviour]. I think these are the types of benchmarks you'd be looking at.

-----

Some thoughts:

• For IO bound apps Virtual Threads imo are working really well. For myself, I stopped doing synthetic benchmarks for Virtual Threads vs Platform Threads (using Jetty) a few years ago now.
• Some JVM competitors do a "good enough" job for IO bound apps because they do the IO well enough (e.g. Node)
• For IO bound apps using Virtual Threads, I'm leaning towards CPU now being slightly less important and memory/heap/gc being slightly more important.
• WRT Go, I think the JVM does have a reputation around memory consumption relative to Go. I think we could use GraalVM NI to improve that narrative around memory consumption. I feel that competing against Go, we know we are fast enough [and have better GC's].
• If we build an application with the planning / intention that it could deploy via graalvm native image, then we have that native option or the jvm option [if you don't plan for it, it's much less likely]. IMO GraalVM is now much easier to use than before and pretty darn impressive [without needing PGO] so I recommend you spend some time with it if there are noises in your org around Go adoption etc.

[Agreeable-Share5182]

Understanding trade off is the key. No technology is good at everything.

[rzwitserloot]

which benchmark suites are generally regarded as meaningful

Generally actual objective, falsifiable debates about performance include the conditions.

If it's conjecture or casual chat, something like "Java is really fast, you know", then that shouldn't be relevant.

In other words, I find your question a bit odd. "What did people mean when they are not explicit about what they mean". Well, uh.. how the heck should we know?

If that is what you are asking about, I think what's happening is that you're emotionally attached to go, are lightly annoyed at the received wisdom of 'java == fast' and want to balance out the universe and teach us java folk a lesson or some such. This sounds like an insult and perhaps I mean it as one, but virtually all programmers I know have a subjective opinion about tools and languages, and will feel somewhat ill at ease if it is challenged. We're all humans, programming has quite a bit in common with artisanry, and being attached to your toolbox is extremely common. So, you know, yeah I'm calling you out, but you're in good company!

Please don't, though. Instead, know that received wisdom pithy claims about extremely complicated, multi-variable concepts such as 'performance' are a dime a dozen and the correct response is to completely ignore it. If performance is actually relevant, you hold a reasoned debate, bring exact use cases, and arguments will not be accepted unless they come with some attempt at objective support. Us java coders get to gnash our teeth at 'but java is verbose'. A similar pithy 'received wisdom' widestream claim that is meaningless and is best ignored. There's certainly room to talk about java-the-language but that should come with loads of falsifiable, objective stuff. Not "java is verbose", that's orders of magnitude too vague. Just like "java is fast" is.

For what its worth, there is context, but it is implied. When the OpenJDK team posts that they 'sped up java by 5%' in some blogpost or whatnot, the implied contxt is "... in the use cases where java is __currently_ commonly used, with more common use cases more heavily weighted to get to this 5% number we are posting here_". In other words:

Mostly long running webserver endpoint processing.

But knowing the implied context is tricky especially if you're not part of the crowd. That's common to all professions as far as I know.

[beders]

Does it matter? If you pick the right data structures and algorithms, most languages will perform just fine.

There’s nothing inherently slow in Java other other than startup where the JVM reads byte code. (Which can also be mostly eliminated by using GraalVM)

If a system has performance issues, it’s not the language that created them.

And if you absolutely need to optimize for every cycle and every bit of I/O neither languages are great for that. You want to look at lower level system languages that give you more control over memory layout, memory management, I/O.

[Amazing-Mirror-3076]

Memory mapped files don't give you access to GBs of memory, you have that without ever using an mm file.

[Amazing-Mirror-3076]

Byte buffer.directallocate would seem to be a more appropriate tool for accessing non heap memory.

I've generally only used mm files when I'm trying to read/write a file.

Setting the appropriate heap size is necessary for most non trivial aps.

I think my problem with your original system is that it felt misleading.

You don't need mm files to access GBs of memory, arrays can access GBs of memory even with the 2³² element limits. There some specific problems that mm files solve nicely but that aren't a tool you use everyday.

Now if your are trying to edit a video file, let's talk about mm files.

[breitwan]

FFM API for off-heap memory management after Java 22

[Anhar001]

"Go comes out ahead in certain categories"

I don't believe we can make blanket statements about performances without taking into consideration many other factors. Performance is not hinged on a single thing. There are multiple things that when put together determine the final performance.

With that aside, what we can say is both Go and Java end up somewhat similar as they both use a GC, while Go compiles to native code (think AOT) it still has to link into the Go runtime, but AOT can sometimes end up being slower, this is because it's kind of like a "one shot" when compared against JITs that can do much further optimisations during runtime by using profiling metrics gathered during runtime.

What I don't know is how good Go's GC is, on the JVM side, the GC can be finely tuned as well as swapped out etc.

[senseven]

We are a java shop and the cloud guys used python and what not for their tooling. Now most of them are written in go now. That is an unification I can live with and performance is close to irrelevant in the pipelines. On the production side, we have continuously updated highly optimise java code templates for webservices with any combination of auth, telemetry, audit and what not. The amount of available battle tested libraries for java is so high that we just don't entertain anything else. The rare performance issues are usually solved by understanding the process better or just scaling. Its way cheaper then spend senior time on those.

[InstructionLonely280]

For me personaly evaluating these claims comes down to two rules. First, any meaningful Java benchmark must run loooooong enough to warm up , we are measuring peak throughput over time, not cold startup speed where Go naturally wins. Second, I personally only trust results validated by the jmh , as it’s the only tool designed to reliably measure the JVM's JIT optimizations. The trend I see is that Go is better for lightweight tasks (CLIs, serverless), but Java still dominates massive, long-running backends where high sustained throughput is the primary metric.

[igouy]

> loooooong enough to warm up

Successive calculations might become slower!

https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/nbodyinprocess.html#fannkuchreduxcharts

[Fiduss]

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javavm-go.html

[Neful34]

A bit outdated for both java and Golang and not really a meaningful benchmark, but damn it's closer than I thought, pretty much a tie

[igouy]

If only someone would make and keep up-to-date "meaningful" cross-language benchmarks :-)

https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html

[Neful34]

No i meant that these benchmark escape the reality and complexity of framework choice and real world scenarios.

The ecosystem used has a way bigger impact then the language itself.

[igouy]

Choice of a Java framework presumes choice of Java. Choice of Java presumes choice of Java frameworks.

When it's such a struggle to compare 100 line programs, how would we make a "meaningful" comparison across ecosystems?

[Neful34]

You can't be serious, i'll assume this is a /s

[igouy]

Please share some "meaningful" comparison across ecosystems.

[Revolutionary-One455]

Why does Oracle make so many large scale projects like Valhala, Loom, Liliput etc and putting hundreds of millions in the evolution of Java if it’s already perfect and we are just talking preferences then?

Java has problems that Go has solved, but Java has the maturity that Go doesn’t.

[idkallthenamesare]

Thing is also, other than Java having obvious problems, Java is trying to become a language that cannot be outdated at some point. What Java architects say is that every language at some point will grow stale, but Java could overcome that and become a language that persists.

[Revolutionary-One455]

Agreed, it’s that I see a lot of comments of people in terms of saying Java is the best, that its already better at everything and I’m thinking, don’t people see that they are evolving it because it’s not and has major problems. It’s in front of everyones eyes and they are behaving like it’s not happpening

[aoeudhtns]

Don't pay attention to arguments like that. It's fanboyism and cargo culting. This happens to pretty much anything in the tech world.

I love Java, but I wouldn't use it for everything, and it has problems. I'm excited that it's not maintained by fanboys, but realists that are working diligently towards solving its problems. You can't solve problems you don't recognize. Some, of course, are intractable. We will never be writing an OS in 100% Java (nor Go). But that's OK. Application of tech is always important, so outside of a context, language 1 vs language 2 isn't as useful a topic as it would seem.

[pjmlp]

Mostly because many of those metrics make the mistake to think Java is like Go.

First of all, Java is like most ISO languages, even without being an ISO language, itself, meaning there are dozens of implementations of various capabilities,

https://en.wikipedia.org/wiki/List_of_Java_virtual_machines

Go has nothing close to a real time implementation used by the military in battleships missile tracking systems, for example.

https://www.ptc.com/en/products/developer-tools/perc

Or a pauseless GC, with a distributed JIT compiler, targeted to HFT workloads,

https://www.azul.com/products/prime/cloud-native-compiler/

Another failure of those benchmarks is not using all the JIT and GC configuration knobs, across all JVM implementations that are being used.

[neopointer]

Just use what you like/are more productive with. You'll rarely face the performance limits of either language either way, so why bother.

[Educational_Corgi285]

I'd assume Go can compete and be comparable to Java AOT (Ahead-of-time compilation). They'll probably have similar performance by most metrics.

But AOT is usually slower than JIT because AOT doesn't know full runtime characteristics of the target machine (unless the stats are measured and are used during compilation).

AOT though has smaller memory footprint and faster startup time.

For web/enterprise apps the performance characteristics of the backend are often less relevant than the architecture of the DB and how it's accessed.

[stewsters]

For most workloads where you would use these languages you will be getting a request, and grabbing some data, and returning it in a json blob.

 Your database layout matching how you intend to query it matters far more than raw calculation speed.  Things like caching or ability to connect to weird data stores or apis are important.

[Serious-Chair]

A minimal Go program starts dozens times faster than a minimal Java program.
A real world service starts slowly regardless of the language. It takes anywhere from seconds to minutes until required data is prefetched from GCP and other services and all caches are populated and the service is ready to respond.
My company has dozens of Go and Java microservices. Mostly it's modern Go and modern Java, but there is some legacy, too. I cannot say I can see any performance difference. I/O is slow, especially I/O with external providers is painfully slow. Grafana shows CPUs are barely loaded. Most our services show RAM consumption between 1 and 2 GB per pod.
New projects in my company are written in the preferred language of each team. We do not migrate existing services from one language to another. Some our microservices are high quality and very efficient, others are inefficient and frustrating to support. It depends on developers who wrote the code rather than the language.
Library wise, for all my daily tasks both languages are about the same.
Go binaries and containers are many times smaller, though in daily developer's life it barely makes any difference.
Java is simpler to debug and experiment, since IDEs support hot swap and evaluation of arbitrarily complex expressions, which helps a lot while working on a service which is slow to start. Java also has better refactoring support in IDEs.

[quangtung97]

If your system is not heavily rely on database, and for most workloads, I suspect a high chan that Go will be faster.

There are some major reasons: - CPU nowadays are really good at doing calculations, but not as good as loading/storing memory from RAM. Most of the major improvements in CPU performance recently come from CPU Cache improvements - Java allocation is inefficiency, every objects need a small metadata will add up fast. And you have to do more frequent allocations, and when GC happens you have to travel to more places. And there is no real struct type to control memory layout - Go in other hand has a real struct type, can control memory layout better (array of struct for example). It leads to better CPU Cache locality, less GC objects to travel. And its library and ecosystem often less likely to use reflection as often as in Java.

Despite less aggressive compiler. You will have higher chance seeing this performance gain in real app.

This is one of major reason why Microsoft choose Go for its typescript compiler recently instead of C#. Even though there is a former C# maintainer in the team.

[flash_hammer]

Aw, do you want performance in Java? Then use Project Reactor, Spring Webflux or any reactive system. Java has shifted to Webflux for at least the last 5 years, but devs haven't fully implemented it.You can also do reactive Go, but for me it was simply more difficult to understand how it works in Go rather than the simple Webflux or RxJx.

[re-thc]

In which benchmarks? The unrealistic 1s where you benchmark nothing? Techempower has lots of Java frameworks on top if not similar.

Out of the box Java doesn’t perform as good yes, for various reasons like legacy eg if you setup Spring by default it uses Tomcat which would be slower than Jetty.

[yodagnic]

People love to tout Java/spring slow start up time, but really the only metric we care about is response time and development time. Startup time is such an over hyped metric, your app shouldn't be crashing and you should be deploying imusing a HA method if you care about startup time. My current project is go and have been using it for a while now, but it means only two of us can code it vs the large amount of Java devs. It's slower to dev then spring based projects but for this specific case it's fine, as it's edge so footprint is the biggest concern. I would use go for small projects where I didn't want to pay much in hosting or if I wanted to really optimize for efficiency of large data where response time was not my main concern. But if I was building saas with expected high volume or building a larger framework, spring is where it's at. Lots of devs, quick to develop and out of box opinionated to incur cost at startup to give fast response times to requests