> They are heavy, bloated, and try to do everything, at the end of the day they pick the lowest common denominator, for everything, and they ship it What does

> They are heavy, bloated, and try to do everything, at the end of the day they pick the lowest common denominator, for everything, and they ship it What does this even mean? > They want compile to a small executable, they are stuck and ended up just zipping everything and calling it a day Both can compile executables the same size as go? See core-rt or the graalvm native-image compiler. > They want to interop with native world, but they introduce runtime overhead and their GC/memory model is a barrier Java's GC's are probably better than any on the market, including go's. And I will agree that currently native interop from the JVM is more expensive than it should be, but they're working on it. > They want to AOT compile, but their runtime and libraries rely a lot on runtime reflection. Easily solved by just declaring what you reflect upon or using runtime agents to find it. It's more difficult than a language than was designed to do it from the start, but eventually all of the big libraries will have it declared already. Hibernate already does [0][1] [0] https://github.com/hibernate/hibernate-orm/blob/5eedda9a467fef44d924f64203023b2345b8415f/hibernate-graalvm/src/main/java/org/hibernate/graalvm/internal/GraalVMStaticAutofeature.java https://github.com/hibernate/hibernate-orm/blob/5eedda9a467f... [1] https://github.com/hibernate/hibernate-orm/blob/5eedda9a467fef44d924f64203023b2345b8415f/hibernate-graalvm/src/main/java/org/hibernate/graalvm/internal/StaticClassLists.java https://github.com/hibernate/hibernate-orm/blob/5eedda9a467f...