3 ms·

They kinda are: "This issue is to fully eliminate LLVM, Clang, and LLD libraries from the Zig project." https://github.com/ziglang/zig/issues/16270 https://gith

by Meneth 6mo ago

They kinda are: "This issue is to fully eliminate LLVM, Clang, and LLD libraries from the Zig project." https://github.com/ziglang/zig/issues/16270 https://github.com/ziglang/zig/issues/16270

flykespice 6mo ago
I find that a very bold move, how will they reivent the wheel on the man-years of optimization work went into LLVM to their own compiler infrastructure?
- geodel 6mo ago
  All that will still be available just not in main zig repo. Someone may have asked same question about LLVM when GNU compiler exist.
- convolvatron 6mo ago
  as a comment about a particular project and its goals and timelines, this is fine. as a general statement that we should never revisit things its pretty offensive. llvm makes a lot of assumptions about the structure of your code and the way its manipulated. if I were working on a language today I would try my best to avoid it. the back ends are where most of the value is and why I might be tempted to use it. we should really happy that language evolution has started again. language monoculture was really dreary and unproductive. 20 years ago you would be called insane for throwing away all the man-years of optimization baked into oracle, and I guess postgres or mysql if you were being low rent. and look where we are today, thousands of people can build databases.
- dnautics 6mo ago
  They're just removing the obligate dependency. I'm pretty sure they will keep it around as a first-class supported backend target for compilation.
  - jibal 5mo ago
    No, the whole point is to eliminate dependencies that they have to maintain. "not obligate" really doesn't mean anything if it's available as a backend--the obligation is on the Zig developers to keep it working, and they want to eliminate that obligation. And the original question was "how will they reivent the wheel on the man-years of optimization work went into LLVM to their own compiler infrastructure?" -- the answer is that Andrew naively believes that they can recreate comparable optimization. There are a whole lot of misstatements about Zig and other matters in the comments here by people who don't have much knowledge about what they are talking about--much of the discussion of using low-level vs high-level languages for writing compilers is nonsense. And one person wrote of "Zig and D" as if those languages are comparable, when D is at least as high level as C++, which it was intended to replace.
    - dnautics 5mo ago
      > the answer is that Andrew naively believes that they can recreate comparable optimization. That's exactly wrong. > There are a whole lot of misstatements about Zig and other matters in the comments here by people who don't have much knowledge about what they are talking about. Well spoken. You should look in the mirror.
    - jibal 5mo ago
      To clarify, my statement was based on comments I have seen and heard from Andrew Kelley when discussing this subject. I can't locate those at the moment, but here is https://news.ycombinator.com/item?id=39156426 https://news.ycombinator.com/item?id=39156426 by mlugg, a primary member of the Zig development team (emphasis added): "To be clear, we aren't saying it will be easy to reach LLVM's optimization capabilities. That's a very long-term plan, and one which will unfold over a number of years. The ability to use LLVM is probably never going away, because there might always be some things it handles better than Zig's own code generation. However, trying to get there seems a worthy goal; at the very least, we can get our self-hosted codegen backends to a point where they perform relatively well in Debug mode without sacrificing debuggability." The current interim plan (which I think was developed after the comments that I heard from Andrew, perhaps in recognition of their naivete) is for Zig to generate LLVM binary files that can be passed to a separate LLVM instance as part of the build process. Is that "a first-class supported backend target for compilation"? I suppose it's a matter of semantics, but that certainly won't be the current LLVM backend that does LLVM API calls. P.S. It may be helpful to read through https://github.com/ziglang/zig/issues/13265 https://github.com/ziglang/zig/issues/13265
- bsder 6mo ago
  Proebsting's Law: Compiler Advances Double Computing Power Every 18 Years You need to implement very few optimizations to get the vast majority of compiler improvements. Many of the papers about this suggest that we would be better off focusing on making quality of life improvements for the programmer (like better debugger integration) rather than abstruse and esoteric compiler optimizations that make understanding the generated code increasingly difficult.
Pay08 6mo ago
Yes, as a backend. Clang as the `zig cc` frontend will stay (and become optional) to my knowledge.
ulbu 6mo ago
libraries, not processes.
baranul 5mo ago
Or maybe look at something like Zen C. A language without the baggage or change in direction. [1] https://github.com/zenc-lang/zenc https://github.com/zenc-lang/zenc

by Meneth 6mo ago

They kinda are: "This issue is to fully eliminate LLVM, Clang, and LLD libraries from the Zig project." https://github.com/ziglang/zig/issues/16270 https://github.com/ziglang/zig/issues/16270

flykespice 6mo ago

I find that a very bold move, how will they reivent the wheel on the man-years of optimization work went into LLVM to their own compiler infrastructure?

geodel 6mo ago
All that will still be available just not in main zig repo. Someone may have asked same question about LLVM when GNU compiler exist.
convolvatron 6mo ago
as a comment about a particular project and its goals and timelines, this is fine. as a general statement that we should never revisit things its pretty offensive. llvm makes a lot of assumptions about the structure of your code and the way its manipulated. if I were working on a language today I would try my best to avoid it. the back ends are where most of the value is and why I might be tempted to use it. we should really happy that language evolution has started again. language monoculture was really dreary and unproductive. 20 years ago you would be called insane for throwing away all the man-years of optimization baked into oracle, and I guess postgres or mysql if you were being low rent. and look where we are today, thousands of people can build databases.
dnautics 6mo ago
They're just removing the obligate dependency. I'm pretty sure they will keep it around as a first-class supported backend target for compilation.
- jibal 5mo ago
  No, the whole point is to eliminate dependencies that they have to maintain. "not obligate" really doesn't mean anything if it's available as a backend--the obligation is on the Zig developers to keep it working, and they want to eliminate that obligation. And the original question was "how will they reivent the wheel on the man-years of optimization work went into LLVM to their own compiler infrastructure?" -- the answer is that Andrew naively believes that they can recreate comparable optimization. There are a whole lot of misstatements about Zig and other matters in the comments here by people who don't have much knowledge about what they are talking about--much of the discussion of using low-level vs high-level languages for writing compilers is nonsense. And one person wrote of "Zig and D" as if those languages are comparable, when D is at least as high level as C++, which it was intended to replace.
  - dnautics 5mo ago
    > the answer is that Andrew naively believes that they can recreate comparable optimization. That's exactly wrong. > There are a whole lot of misstatements about Zig and other matters in the comments here by people who don't have much knowledge about what they are talking about. Well spoken. You should look in the mirror.
  - jibal 5mo ago
    To clarify, my statement was based on comments I have seen and heard from Andrew Kelley when discussing this subject. I can't locate those at the moment, but here is https://news.ycombinator.com/item?id=39156426 https://news.ycombinator.com/item?id=39156426 by mlugg, a primary member of the Zig development team (emphasis added): "To be clear, we aren't saying it will be easy to reach LLVM's optimization capabilities. That's a very long-term plan, and one which will unfold over a number of years. The ability to use LLVM is probably never going away, because there might always be some things it handles better than Zig's own code generation. However, trying to get there seems a worthy goal; at the very least, we can get our self-hosted codegen backends to a point where they perform relatively well in Debug mode without sacrificing debuggability." The current interim plan (which I think was developed after the comments that I heard from Andrew, perhaps in recognition of their naivete) is for Zig to generate LLVM binary files that can be passed to a separate LLVM instance as part of the build process. Is that "a first-class supported backend target for compilation"? I suppose it's a matter of semantics, but that certainly won't be the current LLVM backend that does LLVM API calls. P.S. It may be helpful to read through https://github.com/ziglang/zig/issues/13265 https://github.com/ziglang/zig/issues/13265
bsder 6mo ago
Proebsting's Law: Compiler Advances Double Computing Power Every 18 Years You need to implement very few optimizations to get the vast majority of compiler improvements. Many of the papers about this suggest that we would be better off focusing on making quality of life improvements for the programmer (like better debugger integration) rather than abstruse and esoteric compiler optimizations that make understanding the generated code increasingly difficult.

Pay08 6mo ago

Yes, as a backend. Clang as the `zig cc` frontend will stay (and become optional) to my knowledge.

ulbu 6mo ago

libraries, not processes.

baranul 5mo ago

Or maybe look at something like Zen C. A language without the baggage or change in direction. [1] https://github.com/zenc-lang/zenc https://github.com/zenc-lang/zenc