{"slug": "clang", "name": "Clang", "category": "dev-libs", "category_name": "Libraries and frameworks", "description": "", "recommenders": 3, "commenters": 10, "warners": 2, "score": 2.495, "rising": 1.67, "first": "2025-12-09", "latest": "2026-09-30", "why": "Clang already had the full C99 designated init feature set in C++ mode implemented long before C++20 and it worked just fine.", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 2, "neutral": 4, "compare": 2, "warn": 2}, "spark": [0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "Clang already had the full C99 designated init feature set in C++ mode implemented long before C++20 and it worked just fine.", "icon": true, "domain": null, "github_repo": null, "official_url": "https://clang.llvm.org", "pricing": "", "aliases": ["Clang", "clang"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 798625840, "item_id": 49914115, "url": "https://news.ycombinator.com/item?id=49914115", "by": "etyp", "date": "2026-09-30", "stance": "recommend", "quote": "I will say I much preferred working with Clang's.", "excerpt": "Ah, I used EDG for static analysis, but joined when we were switching over to using Clang for the frontend. I can't say for sure, but part of it was definitely just to save money using open source. The code that was hacked on top of EDG was also ridiculous, so there was a lot of accumulated tech debt there. Looking back at that code definitely brings back memories. As a consumer of both frontends, I will say I much p", "context": "worked on static analysis", "use_case": "C++ frontend for static analysis", "switched_from": "EDG", "story": "EDG C++ front-end goes public"}, {"id": 795875200, "item_id": 49742200, "url": "https://news.ycombinator.com/item?id=49742200", "by": "spacedcowboy", "date": "2026-09-17", "stance": "recommend", "quote": "clang is very eager to vectorise (for good reason, it makes a difference)", "excerpt": "I'd already written a lot of it in ObjC, thinking it would be \"just for me\" before I moved to wanting it running on the FPGA. Three options - Port the ObjC runtime to my little OS on the FPGA ? - Rewrite everything in C so the native FPGA tools could compile it - Make it compile itself and treat the ObjC version as a bootstrap. #3 seemed the best option :) Blewit is a reasonably-sized project, but it's not on the sam", "context": "writes an ObjC-like compiler", "use_case": "compiler", "switched_from": "", "story": "Show HN: An ObjC-like compiler for Mac ARM, x86_64(Linux, Win), WASM, & others"}, {"id": 772235936, "item_id": 48264746, "url": "https://news.ycombinator.com/item?id=48264746", "by": "flohofwoe", "date": "2026-05-25", "stance": "recommend", "quote": "Clang already had the full C99 designated init feature set in C++ mode implemented long before C++20 and it worked just fine.", "excerpt": "> I wrote this after repeatedly seeing experienced C programmers hit the same sharp edges while moving into modern C++ codebases. ...and I've seen this when moving into the opposite direction. Since C++ is stuck with a ca 1995 non-standard subset of C, they usually have no clue what features were added to C in C99. > I\u2019d also be curious which C constructs people still genuinely miss in modern C++. Not implementing th", "context": "", "use_case": "C/C++ compiler", "switched_from": "", "story": null}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 753117969, "item_id": 47069873, "url": "https://news.ycombinator.com/item?id=47069873", "by": "pseudohadamard", "date": "2026-02-18", "stance": "warn", "quote": "it's only gcc and to a lesser extent clang", "excerpt": "I think it's a circular problem, the gcc developers are very insular and respond to outside input with anything from ignoring it to getting into long lawyeristic arguments why, if you squint at the text just right, their way is the only right way, which strongly discourages outside contributions. There's only so many hours in the day and arguing till you're blue in the face that silently mutating a piece of code into", "context": "", "use_case": "C compiler", "switched_from": "", "story": "What every compiler writer should know about programmers (Anton Ertl, 2015) [pdf]"}, {"id": 739343088, "item_id": 46208943, "url": "https://news.ycombinator.com/item?id=46208943", "by": "thefaux", "date": "2025-12-09", "stance": "warn", "quote": "Clang and gcc are abysmal on these benchmarks.", "excerpt": "I liked the first few paragraphs, but the article took a wrong turn for me when it pivoted to ir. Compiler ir need not be fiendishly complex, though modern compilers, particularly clang and gcc can create this impression. There are two nice benchmarks that I use to measure the complexity of a compiler: how long is the compiler and how long does it take to self compile. Clang and gcc are abysmal on these benchmarks. I", "context": "", "use_case": "compiler", "switched_from": "", "story": "Compiler Engineering in Practice \u2013 Part 1: What Is a Compiler?"}]}], "who": [{"by": "etyp", "context": "worked on static analysis", "url": "https://news.ycombinator.com/item?id=49914115", "date": "2026-09-30"}, {"by": "spacedcowboy", "context": "writes an ObjC-like compiler", "url": "https://news.ycombinator.com/item?id=49742200", "date": "2026-09-17"}, {"by": "netdur", "context": "creator of the C+ language", "url": "https://news.ycombinator.com/item?id=49385761", "date": "2026-08-21"}], "tags": [], "use_cases": ["compiler", "c++ frontend for static analysis", "compiling c/c++", "compiling and testing c code", "performance baseline", "compiler for new language"], "compared": [{"slug": "gcc", "name": "GCC", "co": 6, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=49730393", "title": "Show HN: An ObjC-like compiler for Mac ARM, x86_64(Linux, Win), WASM, & others", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=49913192", "title": "EDG C++ front-end goes public", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49799306", "title": "When the Debugger Lies", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49798204", "title": "AMD's random number generator can't generate a 0?", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49320866", "title": "The case against a C alternative (2022)", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48228618", "title": "item 48228618", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {"warn": 1}, "2026-01": {}, "2026-02": {"compare": 1, "warn": 1}, "2026-03": {"neutral": 1}, "2026-04": {}, "2026-05": {"recommend": 1}, "2026-06": {}, "2026-07": {}, "2026-08": {"neutral": 1}, "2026-09": {"compare": 1, "neutral": 2, "recommend": 1}, "2026-10": {}}, "quotes": [{"id": 798625840, "item_id": 49914115, "url": "https://news.ycombinator.com/item?id=49914115", "by": "etyp", "date": "2026-09-30", "stance": "recommend", "quote": "I will say I much preferred working with Clang's.", "excerpt": "Ah, I used EDG for static analysis, but joined when we were switching over to using Clang for the frontend. I can't say for sure, but part of it was definitely just to save money using open source. The code that was hacked on top of EDG was also ridiculous, so there was a lot of accumulated tech debt there. Looking back at that code definitely brings back memories. As a consumer of both frontends, I will say I much p", "context": "worked on static analysis", "use_case": "C++ frontend for static analysis", "switched_from": "EDG", "story": "EDG C++ front-end goes public"}, {"id": 797287793, "item_id": 49830487, "url": "https://news.ycombinator.com/item?id=49830487", "by": "VorpalWay", "date": "2026-09-24", "stance": "neutral", "quote": "at least modern GCC and Clang will warn and/or error for this", "excerpt": "It makes no sense to me that C and C++ didn't require a diagnostic for this, rather you hit UB. I know that at least modern GCC and Clang will warn and/or error for this (not sure which as I use -Werror), but still, this is pointless UB to have. And no, in this case I don't buy that a C90 compiler would have been unable to check this.", "context": "", "use_case": "compiling C/C++", "switched_from": "", "story": "When the Debugger Lies"}, {"id": 796796289, "item_id": 49799768, "url": "https://news.ycombinator.com/item?id=49799768", "by": "strenholme", "date": "2026-09-22", "stance": "neutral", "quote": "I now test the XOF in both GCC and clang at multiple optimization levels", "excerpt": "Yes, /dev/(u)random is supposed to do that, but what if there\u2019s a bug in a kernel (e.g. some embedded system which may not even be running Linux) which causes /dev/(u)ramdom to be less than secure? There\u2019s also issues where, for example, it may no longer be possible to read /dev/(u)random after putting the process in a chroot() sandbox (chroot() isn\u2019t defined in POSIX so its behavior is not guaranteed to be consisten", "context": "", "use_case": "compiling and testing C code", "switched_from": "", "story": "AMD's random number generator can't generate a 0?"}, {"id": 795875200, "item_id": 49742200, "url": "https://news.ycombinator.com/item?id=49742200", "by": "spacedcowboy", "date": "2026-09-17", "stance": "recommend", "quote": "clang is very eager to vectorise (for good reason, it makes a difference)", "excerpt": "I'd already written a lot of it in ObjC, thinking it would be \"just for me\" before I moved to wanting it running on the FPGA. Three options - Port the ObjC runtime to my little OS on the FPGA ? - Rewrite everything in C so the native FPGA tools could compile it - Make it compile itself and treat the ObjC version as a bootstrap. #3 seemed the best option :) Blewit is a reasonably-sized project, but it's not on the sam", "context": "writes an ObjC-like compiler", "use_case": "compiler", "switched_from": "", "story": "Show HN: An ObjC-like compiler for Mac ARM, x86_64(Linux, Win), WASM, & others"}, {"id": 795805056, "item_id": 49737816, "url": "https://news.ycombinator.com/item?id=49737816", "by": "spacedcowboy", "date": "2026-09-17", "stance": "compare", "quote": "Right now we\u2019re sometimes on a par with a clang-compiled C program, but otherwise between 1.1x and 1.8x slower.", "excerpt": "Hi, thanks for the kind words and interest :) It is indeed the goal to have a language better than (or at least fixing some of the pain points of) ObjC, and to make it truly cross-platform and just as easy to grok. Coming from C, I think ObjC was pretty much at the sweet-spot for complexity vs flexibility - there\u2019s only a few things you have to learn over and above C and you get so much from that little extra. I\u2019m al", "context": "retired, ex-Apple", "use_case": "performance baseline", "switched_from": "", "story": "Show HN: An ObjC-like compiler for Mac ARM, x86_64(Linux, Win), WASM, & others"}, {"id": 790172176, "item_id": 49385761, "url": "https://news.ycombinator.com/item?id=49385761", "by": "netdur", "date": "2026-08-21", "stance": "neutral", "quote": "in fact it uses Clang as its compiler", "excerpt": "I am guilty in a sense, I started a new programming language called C+ and one of the pillars I set was that it should not be an alternative to C (or any other language), in fact it uses Clang as its compiler, most of the points in the article still hold, but I hope it doesn\u2019t stop people from coming up with new ideas and actually implementing them in this field, you don't have to be next big thing to be awesome", "context": "creator of the C+ language", "use_case": "compiler for new language", "switched_from": "", "story": "The case against a C alternative (2022)"}, {"id": 772235936, "item_id": 48264746, "url": "https://news.ycombinator.com/item?id=48264746", "by": "flohofwoe", "date": "2026-05-25", "stance": "recommend", "quote": "Clang already had the full C99 designated init feature set in C++ mode implemented long before C++20 and it worked just fine.", "excerpt": "> I wrote this after repeatedly seeing experienced C programmers hit the same sharp edges while moving into modern C++ codebases. ...and I've seen this when moving into the opposite direction. Since C++ is stuck with a ca 1995 non-standard subset of C, they usually have no clue what features were added to C in C99. > I\u2019d also be curious which C constructs people still genuinely miss in modern C++. Not implementing th", "context": "", "use_case": "C/C++ compiler", "switched_from": "", "story": null}, {"id": 758333232, "item_id": 47395827, "url": "https://news.ycombinator.com/item?id=47395827", "by": "kristianp", "date": "2026-03-15", "stance": "neutral", "quote": "clang -O3 -march=native nbody-gcc-6.c -o nbody.clang6", "excerpt": "I've checked some run times on my M1 mac mini, and have realised the C run time of 2.1s for n-body is the figure from the benchmark game itself, which is 50 million iterations on a very old i5. It would have made sense if they'd run the C version on their M4 pro and used the same number of iterations to get a true comparison there. Obviously the main point of the article is to compare different python optimisations, ", "context": "", "use_case": "benchmarking C n-body", "switched_from": "", "story": "Python: The Optimization Ladder"}, {"id": 753117969, "item_id": 47069873, "url": "https://news.ycombinator.com/item?id=47069873", "by": "pseudohadamard", "date": "2026-02-18", "stance": "warn", "quote": "it's only gcc and to a lesser extent clang", "excerpt": "I think it's a circular problem, the gcc developers are very insular and respond to outside input with anything from ignoring it to getting into long lawyeristic arguments why, if you squint at the text just right, their way is the only right way, which strongly discourages outside contributions. There's only so many hours in the day and arguing till you're blue in the face that silently mutating a piece of code into", "context": "", "use_case": "C compiler", "switched_from": "", "story": "What every compiler writer should know about programmers (Anton Ertl, 2015) [pdf]"}, {"id": 752377554, "item_id": 47023597, "url": "https://news.ycombinator.com/item?id=47023597", "by": "jasode", "date": "2026-02-15", "stance": "compare", "quote": "In contrast, gcc/clang can have more isolation without each version interfering with each other.", "excerpt": ">It starts by not looking into Windows through UNIX developer glasses. People don't need any UNIX biases to just want multiple versions of MSVS to work the way Microsoft advertises. For example, with every new version of Visual Studio, Microsoft always says you can install it side-by-side with an older version. But every time, the new version of VS has a bug in the install somewhere that changes something that breaks", "context": "", "use_case": "compilers", "switched_from": "", "story": "I Fixed Windows Native Development"}, {"id": 739343088, "item_id": 46208943, "url": "https://news.ycombinator.com/item?id=46208943", "by": "thefaux", "date": "2025-12-09", "stance": "warn", "quote": "Clang and gcc are abysmal on these benchmarks.", "excerpt": "I liked the first few paragraphs, but the article took a wrong turn for me when it pivoted to ir. Compiler ir need not be fiendishly complex, though modern compilers, particularly clang and gcc can create this impression. There are two nice benchmarks that I use to measure the complexity of a compiler: how long is the compiler and how long does it take to self compile. Clang and gcc are abysmal on these benchmarks. I", "context": "", "use_case": "compiler", "switched_from": "", "story": "Compiler Engineering in Practice \u2013 Part 1: What Is a Compiler?"}]}