source_raw_snapshot
{
"id": "45c82a5a-e6ab-4fe9-91cc-e380b591d9df",
"daily_ranking_item_id": "4652da76-f87f-4461-a2da-13112c894f24",
"source": "hacker_news",
"external_id": "48338673",
"fetched_at": "2026-05-30T22:01:15.405Z",
"story_raw": {
"by": "kristoff_it",
"id": 48338673,
"url": "https://ziglang.org/devlog/2026/#2026-05-30",
"kids": [
48339182,
48340669,
48339902,
48338964,
48339397,
48339872,
48340426,
48339206,
48339091
],
"time": 1780162162,
"type": "story",
"score": 141,
"title": "Zig ELF Linker Improvements Devlog",
"descendants": 21
},
"stats_raw": {
"time": 1780162162,
"score": 141,
"descendants": 21
},
"aux_raw": {
"external_url": "https://ziglang.org/devlog/2026/#2026-05-30",
"hn_comment_url": "https://news.ycombinator.com/item?id=48338673",
"normalized_text": null,
"external_article": {
"title": "Devlog ⚡ Zig Programming Language",
"excerpt": "This page contains a curated list of recent changes to main branch Zig.\n\nThis page contains entries for the year 2026 . Other years are available in the Devlog archive page .\n\nI’ve spent the past few weeks working on our new ELF linker which debuted in Zig 0.16.0. At the time of the 0.16.0 release, this linker implementation was in its fairly early stages, and only really supported linking Zig-only code without any external libraries (even libc)—hence why it was (and still is) disabled by default (it can be enabled with -fnew-linker ). However, quite a lot of progress has been made since that initial release!\n\nHere’s a nice milestone—as of my latest PR , the new ELF linker is capable of building the self-hosted Zig compiler with LLVM and LLD libraries enabled, a task which requires quite a few features under the hood.\n\nOf course, an ELF linker isn’t necessarily the most exciting thing in the world, which is why the headline feature of this new linker is its support for fast incremental compilation. After the recent enhancements, it is now possible (on x86_64 Linux) to perform incremental rebuilds while linking external libraries, C sources, etc—without any additional performance ov",
"final_url": "https://ziglang.org/devlog/2026/#2026-05-30",
"fetched_at": "2026-05-30T22:01:12.630Z",
"description": null
},
"selected_comments": [
{
"id": 48339182,
"raw": {
"by": "bpavuk",
"id": 48339182,
"kids": [
48340962,
48340705,
48340405
],
"text": "I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement and that will let me iterate at the speed of JS or Python with performance of C or Rust. even Andrew's initial dream - to create a DAW with uncompromising UX - will become much easier to create. once someone creates a Zig-native immediate-mode or reactive UI framework, that is.<p>I am still a little salty about `@cImport` removal, though! without it, I can't confidently call it "Kotlin of C" anymore.",
"time": 1780165181,
"type": "comment",
"parent": 48338673
},
"body": "I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement and that will let me iterate at the speed of JS or Python with performance of C or Rust. even Andrew's initial dream - to create a DAW with uncompromising UX - will become much easier to create. once someone creates a Zig-native immediate-mode or reactive UI framework, that is. I am still a little salty about `@cImport` removal, though! without it, I can't confidently call it \"Kotlin of C\" anymore.",
"is_op": false,
"author": "bpavuk",
"raw_body": "I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement and that will let me iterate at the speed of JS or Python with performance of C or Rust. even Andrew's initial dream - to create a DAW with uncompromising UX - will become much easier to create. once someone creates a Zig-native immediate-mode or reactive UI framework, that is.<p>I am still a little salty about `@cImport` removal, though! without it, I can't confidently call it "Kotlin of C" anymore.",
"created_at": 1780165181,
"reply_count": 3
},
{
"id": 48340669,
"raw": {
"by": "onlyrealcuzzo",
"id": 48340669,
"text": "I've been building a memory safe language that transpiles to Zig with a Go-like runtime that can run interpreted (no GC) or compiled - high-level that feels like Ruby but with incremental typing like TypeScript.<p>The Zig team between 0.16 and this has really made me glad I chose Zig as the target instead of Rust - which probably would've been a lot easier to target (since it's already memory safe).<p>I believed it had the best build system design and was the best transpilation target, and I <i>really</i> believe that 6 months later.<p>The main reason I wanted no GC is because I think aliasing is the root of all evil, and I want a language with zero global complexity (but doesn't require a PhD to use).",
"time": 1780175615,
"type": "comment",
"parent": 48338673
},
"body": "I've been building a memory safe language that transpiles to Zig with a Go-like runtime that can run interpreted (no GC) or compiled - high-level that feels like Ruby but with incremental typing like TypeScript. The Zig team between 0.16 and this has really made me glad I chose Zig as the target instead of Rust - which probably would've been a lot easier to target (since it's already memory safe). I believed it had the best build system design and was the best transpilation target, and I really believe that 6 months later. The main reason I wanted no GC is because I think aliasing is the root of all evil, and I want a language with zero global complexity (but doesn't require a PhD to use).",
"is_op": false,
"author": "onlyrealcuzzo",
"raw_body": "I've been building a memory safe language that transpiles to Zig with a Go-like runtime that can run interpreted (no GC) or compiled - high-level that feels like Ruby but with incremental typing like TypeScript.<p>The Zig team between 0.16 and this has really made me glad I chose Zig as the target instead of Rust - which probably would've been a lot easier to target (since it's already memory safe).<p>I believed it had the best build system design and was the best transpilation target, and I <i>really</i> believe that 6 months later.<p>The main reason I wanted no GC is because I think aliasing is the root of all evil, and I want a language with zero global complexity (but doesn't require a PhD to use).",
"created_at": 1780175615,
"reply_count": 0
},
{
"id": 48339902,
"raw": {
"by": "librasteve",
"id": 48339902,
"kids": [
48340163
],
"text": "There has been some speculation about porting the Raku backend (Meta-Object Aware Runtime Virtual Machine - MOARVM)from C to Zig. For example the wider set of Zig Hash options could be a big optimization.<p>Since you ask, the front end is self hosting in NQP and with the ripening RakuAST project increasingly in Raku Grammars. The new AST (6.e.PREVIEW) will bring much better introspection and high level optimization handles. So the potential to refactor/rewrite the VM for substantial speed gains is wide open.<p>Anyway those with skills and interest are welcome to join the -Ofun at <a href=\"https://raku.org/community\" rel=\"nofollow\">https://raku.org/community</a>",
"time": 1780170195,
"type": "comment",
"parent": 48338673
},
"body": "There has been some speculation about porting the Raku backend (Meta-Object Aware Runtime Virtual Machine - MOARVM)from C to Zig. For example the wider set of Zig Hash options could be a big optimization. Since you ask, the front end is self hosting in NQP and with the ripening RakuAST project increasingly in Raku Grammars. The new AST (6.e.PREVIEW) will bring much better introspection and high level optimization handles. So the potential to refactor/rewrite the VM for substantial speed gains is wide open. Anyway those with skills and interest are welcome to join the -Ofun at https://raku.org/community",
"is_op": false,
"author": "librasteve",
"raw_body": "There has been some speculation about porting the Raku backend (Meta-Object Aware Runtime Virtual Machine - MOARVM)from C to Zig. For example the wider set of Zig Hash options could be a big optimization.<p>Since you ask, the front end is self hosting in NQP and with the ripening RakuAST project increasingly in Raku Grammars. The new AST (6.e.PREVIEW) will bring much better introspection and high level optimization handles. So the potential to refactor/rewrite the VM for substantial speed gains is wide open.<p>Anyway those with skills and interest are welcome to join the -Ofun at <a href=\"https://raku.org/community\" rel=\"nofollow\">https://raku.org/community</a>",
"created_at": 1780170195,
"reply_count": 1
},
{
"id": 48338964,
"raw": {
"by": "teabee89",
"id": 48338964,
"text": "This is the promise that blew my mind the first time I heard about Zig years ago. So happy to see this become reality!",
"time": 1780163840,
"type": "comment",
"parent": 48338673
},
"body": "This is the promise that blew my mind the first time I heard about Zig years ago. So happy to see this become reality!",
"is_op": false,
"author": "teabee89",
"raw_body": "This is the promise that blew my mind the first time I heard about Zig years ago. So happy to see this become reality!",
"created_at": 1780163840,
"reply_count": 0
},
{
"id": 48339397,
"raw": {
"by": "derefr",
"id": 48339397,
"kids": [
48340123
],
"text": "So, this linker does fast incremental linking, which is great for development iteration speed.<p>But I assume that any kind of incremental linking, is mutually exclusive with link-time optimization? I.e. you'd never want to use this option for a release build?",
"time": 1780166534,
"type": "comment",
"parent": 48338673
},
"body": "So, this linker does fast incremental linking, which is great for development iteration speed. But I assume that any kind of incremental linking, is mutually exclusive with link-time optimization? I.e. you'd never want to use this option for a release build?",
"is_op": false,
"author": "derefr",
"raw_body": "So, this linker does fast incremental linking, which is great for development iteration speed.<p>But I assume that any kind of incremental linking, is mutually exclusive with link-time optimization? I.e. you'd never want to use this option for a release build?",
"created_at": 1780166534,
"reply_count": 1
}
],
"presentation_fields": {
"title": "Zig ELF Linker Improvements Devlog",
"tagline": "ziglang.org",
"website_url": "https://ziglang.org/devlog/2026/#2026-05-30",
"canonical_url": "https://news.ycombinator.com/item?id=48338673"
},
"external_url_hostname": "ziglang.org",
"selected_comments_raw": [
{
"by": "bpavuk",
"id": 48339182,
"kids": [
48340962,
48340705,
48340405
],
"text": "I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement and that will let me iterate at the speed of JS or Python with performance of C or Rust. even Andrew's initial dream - to create a DAW with uncompromising UX - will become much easier to create. once someone creates a Zig-native immediate-mode or reactive UI framework, that is.<p>I am still a little salty about `@cImport` removal, though! without it, I can't confidently call it "Kotlin of C" anymore.",
"time": 1780165181,
"type": "comment",
"parent": 48338673
},
{
"by": "onlyrealcuzzo",
"id": 48340669,
"text": "I've been building a memory safe language that transpiles to Zig with a Go-like runtime that can run interpreted (no GC) or compiled - high-level that feels like Ruby but with incremental typing like TypeScript.<p>The Zig team between 0.16 and this has really made me glad I chose Zig as the target instead of Rust - which probably would've been a lot easier to target (since it's already memory safe).<p>I believed it had the best build system design and was the best transpilation target, and I <i>really</i> believe that 6 months later.<p>The main reason I wanted no GC is because I think aliasing is the root of all evil, and I want a language with zero global complexity (but doesn't require a PhD to use).",
"time": 1780175615,
"type": "comment",
"parent": 48338673
},
{
"by": "librasteve",
"id": 48339902,
"kids": [
48340163
],
"text": "There has been some speculation about porting the Raku backend (Meta-Object Aware Runtime Virtual Machine - MOARVM)from C to Zig. For example the wider set of Zig Hash options could be a big optimization.<p>Since you ask, the front end is self hosting in NQP and with the ripening RakuAST project increasingly in Raku Grammars. The new AST (6.e.PREVIEW) will bring much better introspection and high level optimization handles. So the potential to refactor/rewrite the VM for substantial speed gains is wide open.<p>Anyway those with skills and interest are welcome to join the -Ofun at <a href=\"https://raku.org/community\" rel=\"nofollow\">https://raku.org/community</a>",
"time": 1780170195,
"type": "comment",
"parent": 48338673
},
{
"by": "teabee89",
"id": 48338964,
"text": "This is the promise that blew my mind the first time I heard about Zig years ago. So happy to see this become reality!",
"time": 1780163840,
"type": "comment",
"parent": 48338673
},
{
"by": "derefr",
"id": 48339397,
"kids": [
48340123
],
"text": "So, this linker does fast incremental linking, which is great for development iteration speed.<p>But I assume that any kind of incremental linking, is mutually exclusive with link-time optimization? I.e. you'd never want to use this option for a release build?",
"time": 1780166534,
"type": "comment",
"parent": 48338673
}
]
},
"selection_meta": {
"discussion_depth": "top_comments_v1",
"external_article": {
"status": "ok",
"final_url": "https://ziglang.org/devlog/2026/#2026-05-30",
"status_code": 200,
"content_type": "text/html",
"failure_reason": null
},
"snapshot_version": "hn_story_v3",
"selected_comments_count": 5,
"external_article_resolved": true,
"text_normalization_applied": false
},
"created_at": "2026-05-30T22:01:15.588Z",
"updated_at": "2026-05-30T22:01:15.588Z"
}