<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>swagonomixxx</author><text>Devil&amp;#x27;s advocate: more diverse compiler tech will mean a more fragmented community and a larger probability of divergence across implementations.&lt;p&gt;People think the C compiler community is dominated by GCC and Clang, and it is, but there are literally 1000s of implementations out there in the wild. Most are necessary, because we need code generated for some obscure processor architecture that&amp;#x27;s completely proprietary, but you can create that &amp;quot;backend&amp;quot; in LLVM itself - it&amp;#x27;s a new target architecture instead of e.g x86.&lt;p&gt;The great thing about LLVM is that it&amp;#x27;s effectively the quickest (and probably the best) way to generate machine code without putting in too much effort, for a language. Whether that language be a research language or an existing industry language (say, C), that kind of establishment is hugely valuable.&lt;p&gt;A great example of a good monoculture is the Go monoculture. Sure, there&amp;#x27;s gccgo, but the proportion of people using that vs. the reference implementation is minimal, and that reduced fragmentation is actually a good thing for practitioners (which most engineers are, not PL researchers).</text><parent_chain><item><author>pizlonator</author><text>This is really great. The world needs more diverse compiler tech. The llvm monoculture is constraining what kind of compiler research folks do to just the things that are practical to do in llvm.&lt;p&gt;I particularly suspect that if something like Cranelift gets evolved more then it will eventually reach throughput parity with llvm, likely without actually implementing all of the optimizations that llvm has. It shouldn’t be assumed that just because llvm has an optimization that this optimization is profitable anywhere but llvm or at all.&lt;p&gt;Final thought, someone should try this with B3. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;webkit.org&amp;#x2F;docs&amp;#x2F;b3&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;webkit.org&amp;#x2F;docs&amp;#x2F;b3&amp;#x2F;&lt;/a&gt;</text></item></parent_chain></comment><story><title>A possible new back end for Rust</title><url>https://jason-williams.co.uk/a-possible-new-backend-for-rust</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>edwintorok</author><text>Worth mentioning other alternative small backends: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;c9x.me&amp;#x2F;compile&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;c9x.me&amp;#x2F;compile&amp;#x2F;&lt;/a&gt;</text><parent_chain><item><author>pizlonator</author><text>This is really great. The world needs more diverse compiler tech. The llvm monoculture is constraining what kind of compiler research folks do to just the things that are practical to do in llvm.&lt;p&gt;I particularly suspect that if something like Cranelift gets evolved more then it will eventually reach throughput parity with llvm, likely without actually implementing all of the optimizations that llvm has. It shouldn’t be assumed that just because llvm has an optimization that this optimization is profitable anywhere but llvm or at all.&lt;p&gt;Final thought, someone should try this with B3. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;webkit.org&amp;#x2F;docs&amp;#x2F;b3&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;webkit.org&amp;#x2F;docs&amp;#x2F;b3&amp;#x2F;&lt;/a&gt;</text></item></parent_chain></comment><story><title>A possible new back end for Rust</title><url>https://jason-williams.co.uk/a-possible-new-backend-for-rust</url></story>