Discussion summary

Discussions about LLVM focus on its role as an open-source compiler infrastructure, its accessibility for LLMs, and concerns over slow compilation times. Some users consider ditching LLVM for faster alternatives in development workflows.

What the discussion says

  • LLVM is widely used for compiler development and tools.
  • Its slow compile times are problematic for rapid development.
  • There is interest in faster alternatives, but few are production-ready.
LLVM is an open source system for compiler design.
visha1v
LLVM is accessible to LLMs and can be quickly set up.
kelseyfrog

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • LLVM here refers to the LLVM Compiler Infrastructure, an open source software system created to simplify the design and implementation of compilers and a wide range of compiler-based tools.
  • As opposed to what?
  • This infrastructure is also slow and leads to poor compilation times for any language that uses llvm as a backend. In an era of automatic code generation, this will become more and more of a problem as llvm compilation times will become a huge bottleneck. I am very bearish on llvm as a technology and while I will acknowledge its influence, I expect that it is at or near its peak and market share will decline dramatically over the next five to ten years.
  • > In an era of automatic code generation

    lol what does this even mean

  • > leads to poor compilation times for any language that uses llvm as a backend

    it doesn't take long for user delay to sum to more than developer delay

  • It makes perfect sense to ditch LLVM in development contexts, as its slowness is antithetical to developer productivity — most obviously in tight edit-compile-test loops. And this becomes orders of magnitude more salient when the edit-compile-test loop is being driven by AI.

    But even when languages are described as "moving away" that usually means building their own very fast-compiling/min-optimising x64/ARM backend for development builds, while still acknowledging the need for LLVM for highly optimised release builds.

  • Where are the fast alternatives though that do the same level of optimizations?

    LLVM might not be the fastest, but when you get to the point that build times become a problem, your code base is too big (or your frontend is doing silly things). Maybe ask your 'automatic code generation' to generate less code bloat ;)

  • 5 years? There would need to be already production ready, growing alternative
  • I’ve been shocked by how much LLVM leaves on the table while designing Logos language! Some very exciting benchmarks coming soon that we’ve been working on for over 6 months, but LLVM misses a LOT of potential optimizations when you have a strong type system!
  • Is there a URL for that language? It is unfortunately a bit un-googleable!
  • It's also fairly accessible to LLMs. I was surprised at how quickly a self-hosting compiler could be brought up using the LLVM ecosystem.
  • That's what I've been doing with a custom jank implementation, taking advantage of the LLVM changes contributed upstream to LLVM 22.
  • While LLVM is undoubtedly a great project for compiler research, lets not forget those that predated it with similar ideas like the Amsterdam Compiler Toolkit, or IBM's PL.8 compiler for the RISC project.