HN user
New GraalVM project Crema now supports runtime class-loading. Here's a full Clojure runtime built with GraalVM native-image + Crema: https://github.com/borkdude/cream
That means that Java programmers have to be very careful when writing code
From JEP 444:
The scheduler does not currently implement time sharing for virtual threads. Time sharing is the forceful preemption of a thread that has consumed an allotted quantity of CPU time. While time sharing can be effective at reducing the latency of some tasks when there are a relatively small number of platform threads and CPU utilization is at 100%, it is not clear that time sharing would be as effective with a million virtual threads.
Also, in this scenario, i think the current scheduler (ForkJoin Pool) will use managed blocker to compensate those pinned carrier threads.
"write once, run anywhere"??
You know that the code compiled using future version of java won' work in older versions..rt? I would like to know if any other programming language does that kind of thing.
t should be as fast and easy to use and
How did you conclude that it's not fast? They are creating native binaries just like Go or any other AOT languages with GCs. Graal native images are as fast or faster than Go. Also it contains a REPL, that's why bigger size. So for CLI tooling as a developer using pkl, you won't see any difference if it's written in java + kotlin or golang.
For java/Kotlin, we are using JTE (https://jte.gg/#getting-started), pretty nice build tooling and IDE support to generate pre-compiled templates without additional code generation steps.
An average JVM needs 500+ MB of RAM
We are running small services with heap size under 100 MBs and is absolutely possible with new JVM versions. If you want ever smaller without JIT, native image is also an option. Moreover in most scenarios, JVM provide better peak performance. So here is a tradeoff
I don't see the advantage to this over async/await style programming
Harmonious with the platform (jvm) which is based on threads, better stack-traces, accurate profiling info and simpler programming model (without adding async/await/suspend keyword everywhere) etc are some of the advantages.
Modern java (check this - https://www.infoq.com/articles/data-oriented-programming-jav...) is really not that bad. Golang is like far more verbose than even JDK 8 (9 old release) for most parts. The issue is, many java users have only experience with spring ecosystem for doing most of the stuffs. There are far better alternatives in java ecosystem. There are other JVM languages like Kotlin with provides 100% interop with the ecosystems and is far better language than go.
The Go build tools fit your analogy better.
Go uses two build tools for any non-trivial projects. One write in go.mod and another in Make :D (see this - https://github.com/kubernetes/kubernetes/tree/master/build/r...)
Yes, IMO game changing for java. Read this JEP - https://openjdk.org/jeps/425
Here is a simple echo server running on Virtual thread (using same old blocking APIs, handle 5m persistent connections) - https://github.com/ebarlas/project-loom-c5m/blob/main/src/ma...
Check compose mpp, uses Kotlin and Skia under the hood. Really good performance overall.
because there’s nothing better!
You should check out compose multi platform - https://www.jetbrains.com/lp/compose-mpp/
May be by next LTS (java 21 - 2023 Sep) :D
None with the same performance characteristics,
Most JVM languages (Kotlin/Scala/Clojure) including Java :) In fact kotlin/java has better peak performance than Go. Main advantage for go is the reduced memory footprint.
Yes, nerdctl compose will work for most of the use cases. Check this compatibility guide - https://github.com/containerd/nerdctl/blob/master/docs/compo...
JDK is modular now and ecosystem is moving towards jlinked application. So no need for jdk on the target machine.
Probably once ZGC gets the generation support (https://github.com/openjdk/zgc/tree/zgc_generational) which will reduce the memory footprint.
jfyi: here is the latency GC numbers (JDK17) - https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html . The experience is vastly different compared to an 8 year old jdk version (jdk 8)
ton of the bullshit abstractions
Not sure how that's the Java's problem. Most of these abstraction come older frameworks. You can have these same abstraction/design pattern in Go also.
That's case for virtual threads also. It uses ForkJoinPool.ManagedBlocker to add additional threads.
"File I/O is problematic. Internally, the JDK uses buffered I/O for files, which always reports available bytes even when a read will block. On Linux, we plan to use io_uring for asynchronous file I/O, and in the meantime we’re using the ForkJoinPool.ManagedBlocker mechanism to smooth over blocking file I/O operations by adding more OS threads to the worker pool when a worker is blocked."
There are two more intersting features that work with Virtual threads,
Structured Concurrency - https://openjdk.java.net/jeps/8277129
Scope Locals - https://openjdk.java.net/jeps/8263012
Yeah that decision make sense for multi platform. Suspending functions will work on JS and Kotlin Native.
Is this the case very large go heaps? ZGC claims sub ms pause for TB heap size.
Primitive types are not in java 17. Hoping to preview it on 18
https://micronaut.io/ - low memory foot print, AOT first approach, catch most of the errors at compile time and highly productive.
Does playwright work out of the box in CI systems (github actions) or we have to explicitly install the browser binaries? I am planning to use playwright-java (https://playwright.dev/java/docs/intro)
You can do underscore import and local variable to workaround this limitation and I have seen that in the code.
with far less complexity by using an AOT compiled language.
Or use reflection free frameworks like Micronaut or Quarkus and enjoy the same productivity. The culprit here is no java, the spring framework.
2 hours till the JVM C2 compiler is able to fully optimize
That's really hard to believe claim with the request throughput you have.
"a guy who loves the project he works on"
Yes, he is Ron Pressler, project lead of Loom - https://twitter.com/pressron