[rvz]

All of that configuration and it will always be less efficient than Rust, or even Golang.

This is why lots of engineers waste time fiddling with options to tune the JVM and still require hundreds of replicated micro-services to "scale" their backends and losing money on AWS and when they will never admit the issue is the technology they have chosen (Java) and why AWS loves their customers using inefficient and expensive technologies.

Even after that, both Go and Rust continue to run rings around the JVM no matter the combination of options.

[cleverfoo]

Sure, for a very narrow definition of _efficiency_. There's plenty to complain in terms of the JVM and Java but performance, as in units of work per dollar spent, is not one of them - JITs just have too many opportunities for optimizing generated code.

[deepsun]

All of that tooling and Rust will always be less efficient than Assembler.

[metaltyphoon]

I… didn’t think this makes sense :)

[msla]

It makes perfect sense: Rust compilers will never beat a human at scheduling every single opcode perfectly based on the deepest microarchitectural analysis short of decapping the chip and breaking out the ol' electron microscope. Whether it's worthwhile to be that efficient over a whole program, as opposed to a preternaturally tight compute kernel, is definitely questionable.

[metaltyphoon]

> scheduling every single opcode perfectly based on the deepest microarchitectural

Is that even possible knowing OOE+ branch execution and many other CPU tricks?

[pjmlp]

Yes it does, that is why most serious games used to be written in Assembly, until BASIC, Pascal, C and C++ compilers got enough language extensions and compiler knobs to not having to do that all the time, and yet some Assembly is still required.

[well_ackshually]

That's a nice source, from where up your ass did you find it ?

Go's GC is absolutely awful and leads to nondeterministic pauses and catastrophic latency spikes, especially when the memory pressure and capacity is high. Throw the go GC against a 256GB heap, see how well it survives.

Technologies have strong and weak points. Go's strong points are small, targeted pieces of software and having 66% of a binary basically be if err != nil return err. Rust's strong points are that you get to have the symbol<():soup<_, |_| of { c++ }>> while not saying you're writing c++ and feeling really smug when you say that you only needed to use 5 Arc<Mutex<T>> and rewrote your entire software three times but at least it runs almost as fast as some shitty C that does fgets() in the middle of a hot loop. Java lets you spawn spring boot and instantiate a string through reflection because why not.

I promise you, I can write allocation heavy FizzBuzzEnterpriseFactoryFactories in Rust too.

[jim33442]

I still don't get why Java is the only language that needs the heap to be carefully tuned. Like it hogs some memory at start, crashes if you go above a certain amount, and doesn't return memory to the OS when GC'd. Even Python and JS don't have those problems.

[cogman10]

> I still don't get why Java is the only language that needs the heap to be carefully tuned.

Only tuning you should be doing is setting the heap size and algorithm (Though, size is likely enough).

> Like it hogs some memory at start, crashes if you go above a certain amount, and doesn't return memory to the OS when GC'd. Even Python and JS don't have those problems.

Unlike Python and I believe most javascript engines, the JVM uses moving garbage collectors. That's the primary reason why it hogs memory.

In these ready to return to OS languages, when something is freed or allocated they are literally calling "malloc" and "free" directly. That's why stuff tends to return back to the OS faster.

The JVM doesn't do that. When a GC runs in the JVM, the JVM picks up and moves live data to a new location. That means the JVM needs a minimum amount of free space to operate. The benefit of this is the JVM can allocate really fast, it's just a single pointer bump and a check to ensure there's enough space. It's pretty close to the same performance as the stack is in C++.

And if there's a lot of data that lives for a short period of time, the JVM frees that data very fast as well. There is little accounting that the JVM has to do to free stuff up because it's simply moving the live data.

For even the fastest allocators that python/javascript engines use, this isn't true. They have to keep track of the various allocation locations and the gaps in allocation when something is freed. And a request for allocation needs to ultimately find a location in the heap with enough room.

Java does have a memory issue, though, all objects in java are pretty bulky. This will hopefully be fixed in future versions when "value" types are added.

[jim33442]

Thanks, that's a really good explanation. And makes sense, especially since Java objects are all constantly getting allocated/freed on the (virtual) heap rather than stack.

[cogman10]

No problem.

The GC strategy for Java works best when the JVM has a lot of memory to play with. That's a big reason why a lot of companies use it for the backends.

However, Java suffers when you start talking about small heaps. This has become a much bigger issue as containered applications have risen as a primary deployment method. There are active efforts ongoing to solve this problem and make Java more friendly to smaller memory footprints and containers in general.

The Go/python/javascript strategies end up working better in those situations. They have very fast startups and pretty low memory requirements. However, when you start talking about apps that need a lot of memory, they both end up suffering as their allocation strategies degrade as the memory being tracked grows. Especially if there's a large amount of memory churn. The JVM has about the best strategy for very high memory churn.

[jim33442]

Yeah the Java way makes sense if it's the only thing running on that machine, or at least you know ahead of time how much RAM to budget to each thing. Which was often the case on servers. I'm not surprised if that performs better than Go in a way, but seems like Go does ok. If they really wanted a custom heap on top of preallocated memory in a Go program, couldn't they just do that?

The weirder part is that Java also used to be a bigger thing client-side, back when websites commonly included Java applets.

[gf000]

You don't have to do anything, it just works.

But eventually someone gonna write the goddamn whole of AWS or Alibaba in the language where you have machines with TBs of heaps (yeah, you read that right), where most other managed languages would just give up instantly - and then you may have to add 2-3 parameters to make it actually run properly in these extreme conditions.

[pjmlp]

They do, but then people either work around them, or rewrite in Rust.

Java has all these knobs, because the ultimate goal is not needed to rewrite, rather fine tuning, just like when you look at the endless command line options for GCC, clang, MSVC,...

It is also a matter of implementation, Android is Java (kind of), and you also don't get push knobs unless you are a developer talking directly to a single device over ADB.

[arein3]

Yeah doubt that

Recently I had a python friend use the most balls to the wall python backend, he couldnt beleive java was faster, but the numbers werent lying. We did 1 billion iterations of adding a float, took a few seconds in java.

[fHr]

I was a diehard java fanboy but using Rust in the last 5 years more and more I have to agree, but sadly huge Java corporate codebases keep my bills paid still, so I have to deal with it. It is what it is. Also agree the pipeline etc. they love all the waste of the compute in their pocket.

[deepsun]

I code on both and they are just for different purposes. E.g. I think it's madness to develop desktop apps in Rust.

Development velocity is way greater in Java.

[pjmlp]

You mean like the waste of the compute in Rust compiler when compiling from source all the time, with the lenghty compilation times it has, multipled by every Rust user when starting a new project?

[contraposit]

I hope AI will make automated translation of such legacy codebases into any favourite langauge possible in future. Fingers crossed.

[newsoftheday]

It sounds like you're not into Java. Perhaps consider switching languages to make room for people who are.