Quite the opposite. Java is almost all about an optimising runtime with deep telemetry, and it helps with exactly the things AI needs the most help: https://youtu.be/fXBGBovpH88

▲

anko 3 hours ago | parent [-]

I now manage a team writing languages on the jvm. I have found the jvm ecosystem terrible for observability. Examples;

- junit parallelisation - how are shards handled? how do you balance the tasks across forked processes? What is the bottleneck? Options are 1) pay someone for better tooling or 2) write your own

- long pauses in garbage collection - how do you know which objects are causing the pauses? the options; 1) profiling 2) analysing heap dumps that you periodically capture 3) add metrics or gc logging

- what is the performance bottleneck? options 1) profiling

Sure AI can do this stuff, but it's painful and time consuming

Contrast it to Elixir on the BEAM;

- exunit parallelization - basically free and because you don't have coupling due to OOP. mocks are basically an antipattern

- long pauses due to gc? They just don't happen - everything is isolated and can be cleaned up in parallel.

- performance bottleneck? Open inspector and see what is doing all the reductions, and if any of the inbox queues are backlogged. You don't have to profile, you can just look in production - memory? Open inspector and sort processes by size descending. Again no profiling needed

▲

pron an hour ago | parent [-]

JFR is what you'd use for everything you need to know. It's depth and breadth are unmatched.

> Contrast it to Elixir on the BEAM;

Java is in the same performance class as C++. BEAM is wonderful in its own way, but it's not even in the same performance class as Go.

BEAM was designed for some interesting resilience in distributed systems. The JVM was designed to address the performance issues that programs in C++ and other low-level languages suffer from when they get large and/or are maintained/evolved for a long time.

> long pauses due to gc? They just don't happen - everything is isolated and can be cleaned up in parallel.

GC pauses in the JVM have been optional for a few years now. ZGC doesn't have GC pauses.

	▲	anko an hour ago \| parent [-]
		We're talking past each other a bit. I was just trying to give examples of where observability on the jvm isn't that great, because you were were stating it's where AI needs the most help. The parent was saying these new features don't matter as much post-AI and i think I agree with them. The AI can just write in rust if you need to optimise a hot loop, but if you need observability, you could do worse than the BEAM. > GC pauses in the JVM have been optional for a few years now. ZGC doesn't have GC pauses. yeah that's a fair comment, zgc is a lot better for pauses. I'd still say that it pulls along a fair bit of incidental complexity - it encourages you to allocate a fair amount of memory to your heap, which isn't ideal in this world of kubernetes and microservices. If you leave on uncommit (returning memory to he OS periodically) you get extra latency penalties which are just as painful as garbage collection stalls IMHO.