Comment by winrid

The new generational ZGC? I'm sceptical.

Have a reproducer?

> Lately, they seems to work with CRIU, various heuristics, multi-stage in-process bytecode compilation ..

Not sure what you mean by this, as this has nothing to do with GC, and Java has had a multi-tier optimising compiler for 15 years now.

> that nobody else have, so fixes are available

Go has much worse problems with GC than Java does these days, and nobody else is able to achieve similar performance in large programs with heavy workloads. So everyone else lives with less sophisticated compilers and memory management simply by accepting worse performance.

>As far as I know, java has 7 GC implementations, none of which are perfect, all of which have drawbacks

Compared to Python's, all of them are beyond perfect. And 99.9% of the time you don't even need to use anything but the default.

https://openjdk.org/jeps/8377305

A do nothing C program (int main() { return; }):

    $ time ./a.out

    real    0m0.002s
    user    0m0.000s
    sys     0m0.002s

A do-nothing Go program:

    $ time ./tmp

    real    0m0.002s
    user    0m0.000s
    sys     0m0.003s

I don't believe Go has any optimizations to not start its runtime if it isn't necessary, but when I added spawning a goroutine that immediately blocks on a channel read that will never come the numbers didn't change. That doesn't really time the runtime. Probably the program terminated before the goroutine was scheduled to run anything. It just makes it so there definitely wasn't an early exit because the compiler or the runtime "realized" it didn't need to start the runtime.

I'm sure the Go program is somewhat slower to start and end than C, and that we're running into the limits of how quickly processes can be spawned and other timing overhead which is obscuring the difference. However for practical purposes, "it starts up in less than the overhead for starting a process in the shell" is the same speed for most purposes.

Not even a "do nothing" Python program, no Python program at all:

    $ time python3 -c 1

    real    0m0.012s
    user    0m0.008s
    sys     0m0.004s

If you had a Go program that was slow to start up, it was your program, not Go. By contrast, Python, and the dynamic scripting languages in general, can be quite slow to start up, just in the reading and compiling of the code. (Even .pyc files, IIRC, take processing, just less processing than Python source code... it's still nowhere near "memory map it in and go" as it is for statically-compiled languages.)

What? Compared to Python they're like lightning. Typically milliseconds to the start of main() - admittedly they can be slowed down by init() nonsense and terrible generated protobuf code nonsense in deep dependency trees - but with a non-trivial Python program you can look forward to an order of magnitude more. There are techniques to help address that but (1) they're not idiomatic and (2) it still only mitigates it.

I suppose Go programs are slower than the equivalent thing in C or C++, but I'm not sure that's a very relevant comparison in most cases today (how many new things being written would choose those languages).

So are Python and Java programs.

That doesn't matter for anything other then CLIs.

If it makes you feel any better (it probably doesn't), the development of OpenJDK and the Java language itself is also mostly funded by Oracle

Java is funded by Oracle, all of it.

People parrot to use OpenJDK without understanding it is mostly Oracle employees working on it.

And if you dislike Oracle, the other minor contributors are Red-Hat, IBM, SAP, Microsoft, Alibaba, Azul,... which for many HNers are the same.

Well, they never made the jump to Python 3. But shipping 2.7 interpreters in 2024 was quite an achievement on its own. So their users already know this pain. And from my experience in academia, python 2.7 and java 8 will probably be used for another 20 years before the last machine running that stuff burns out.