← Back to context

Comment by gf000

6 days ago

They trade blows, and have different philosophies (complex runtime, simpler language vs the reverse).

E.g. on the GC side Java is ahead of any other platform, especially with the low-latency ZGC garbage collector.

The counterpoint is that Java has so much SOTA GC work precisely because the language makes writing efficient code that doesn't heavily tax the GC basically impossible.

  • Tell me you haven't looked at Java in 15 years without telling me.

    Given that the vast majority of non-GC language code does a terrible job of managing memory, it's not difficult at all for the JVM to win out on efficient, reliable systems.

    • To be clear, I think that GC is absolutely the right approach, you just need an object model that lets you write idiomatic code that allocates an order of magnitude or 2 less. Once Valhala is (finally) released, the Java ecosystem will start to have the tools to write efficient code (the same tools that C# has had for ~2 decades now), but until then it's just completely impossible to write object oriented code in Java without millions of allocations per second.

I would love to have a Java compiler with the capabilities of the .net compiler. To make incremental builds to aid code completion including type information, looking past simple syntactical errors, fixing them, and continuing compilation.

Currently, this is “magic” embedded in eclipse, IntelliJ, and maybe a bit in the vscode plugin. Imagine having a Java LSP running that can provide all this information while typing.

.net has had this for ages. From a language design I think that is wonderful.

  • Java LSP backends are basically headless Eclipse and NetBeans, they definitely go beyond syntactical errors.

    There's also the upcoming Metals v2 that's using another compiler frontend optimized for performance, Google Turbine: https://metals-lsp.org

    Actionable diagnostics for Java aren't implemented yet though.

  • It also slows VS code a lot, is not properly documented, and still relies on concatenating strings together, due to Source Generators interaction with attributes.