Hacker News new | past | comments | ask | show | jobs | submit login

Respectfully I'm not sure that's true.

> State-of-the-art optimizing compilers.

LLVM provides coverage for many of the new languages that are hyped these days (with the notable and truly unfortunate exception of Go). LLDB provides an excellent debugger infrastructure.

> State-of-the-art GCs.

True, there's some good work there but I'm excited about languages that don't need GCs at all, so that we can finally stop tricking the memory wizard into complying with our workloads and focus on determinism, power efficiency and memory efficiency.

> Low-overhead in-production profiling/monitoring/management.

Correct me if I'm wrong but a lot of that is available in dtrace is it not?

This is actually why I'm so excited by LLVM. I think it's the biggest advancement in computer science in ages and ages. It allows compiler engineers to focus on bringing what they do better and differently to the stack. It allows them to leverage the years of work and bundles of PHDs worth of research that went into the rest. All that time Go wasted developing assemblers for platforms should have been spent focusing on Go and letting LLVM handle it.

Over time the delta between what Java has and what LLVM has will shrink which in turn narrows the gap between Java and every other LLVM based language.

Think about it, macOS is basically just various front-ends for LLVM. Apple's implementations of OpenCL and OpenGL, the Metal Shading Language and Core Image are all wrappers for LLVM. Swift is a wrapper for LLVM. Clang makes C and C++ fancy wrappers for LLVM. Rust is a wrapper for LLVM. Almost everything your mac does is a fancy front-end for LLVM. Even Safari was (until B3 backend) a fancy front end for LLVM.




As I said in another comment, there can be more than one thing that's cutting edge, especially as the JVM and LLVM operate at completely different levels. Never mind GCs -- LLVM isn't even safe, and neither is WASM; and that's good at that low level. In fact, LLVM is employed by Falcon, the Zing JVM's JIT, and OpenJDK's HotSpot is compiled to LLVM on Mac.

> I'm excited about languages that don't need GCs at all, so that we can finally stop tricking the memory wizard into complying with our workloads and focus on determinism, power efficiency and memory efficiency.

That's fine, but it seems like giving up GCs comes with its own non-negligible costs, so much so that the two hardly compete in the same domains.

> Correct me if I'm wrong but a lot of that is available in dtrace is it not?

They have similarities (closer analogs would be https://github.com/btraceio/btrace and http://byteman.jboss.org/ than JFR), yes, but operate at different levels with somewhat different capabilities.

> This is actually why I'm so excited by LLVM. I think it's the biggest advancement in computer science in ages and ages.

LLVM is popular, extremely useful, and quite cutting edge in its domain, but there isn't much of a "computer science" advancement as there is, e.g., in Graal/Truffle.

> It allows them to leverage the years of work and bundles of PHDs worth of research that went into the rest.

It certainly does, but there's a lot that LLVM doesn't give language designers that a JVM does, like GCs and high-level language interop.

> Over time the delta between what Java has and what LLVM has will shrink which in turn narrows the gap between Java and every other LLVM based language.

I don't know if LLVM wants to operate at Java's level or vice versa. While LLVM may offer some basic GC and Java may offer "safe" LLVM with things like Sulong, I believe their main focus will be their own respective levels.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: