Scala support is still being finished, however the project team decide to go ahead releasing 4.0.0 at the beginning of the year avoiding the block until the Scala support work was complete. You can follow its development on GitHub or the official Discord server.
JavaScript's support has been moved to the reactiverse project. It's an incubation like project for projects that aren't fully 1.0.0 yet. In there you will find https://reactiverse.io/es4x/, the EcmaScript support For Vert.x. It's a new approach of using vert.x with GraalVM to provide modern ES language features such as ES12, instead of the old Nashorn ES5.1.
It also changes the development workflow from a maven-based project to a NPM-based project which should be more familiar to JavaScript developers.
It does work on a stock openjdk11 with similar performance (but I don't have numbers to show). What happens in this case is that we can load the graal compiler to replace the default jit but it will not allow you to use other languages as only graaljs currently runs on this mode.
Hi, I'm the author of ES4X I'd love to check your graphql test. I've no experience on Apollo so if you could share a test/benchmark it would be great to see where the bottlenecks come from.
> "so it's actually something not that non-special."
That is not totally true, This is a mix of 2 things, using the JVM (which like you said is being tuned and optimized for heavy loads) + using a true asynchronous and reactive programming (and IO) model built on great technologies such as (in this specific case: Kotlin, Eclipse Vert.x and Netty).
As an experiment if you would pick another random set of libraries (imagine a servlet container) achieving the same results would not be so trivial, see for example:
Vertx is polyglot, you can use js and npm if you like, so in this respect vertx can be more productive as it allows you too use the tool that works best for your problem, be it npm, maven, gradle or language: java, javascript, kotlin, etc...
