[HN Gopher] Lightpanda migrate DOM implementation to Zig
___________________________________________________________________
Lightpanda migrate DOM implementation to Zig
Author : gearnode
Score : 180 points
Date : 2026-01-12 09:42 UTC (13 hours ago)
(HTM) web link (lightpanda.io)
(TXT) w3m dump (lightpanda.io)
| barishnamazov wrote:
| This reminds me of the Servo project's journey. Always impressed
| to see another implementation of the WHATWG specs.
|
| It's interesting to see Zig being chosen here over Rust for a
| browser engine component. Rust has kind of become the default
| answer for "safe browser components" (e.g., Servo, Firefox's
| oxidation), primarily because the borrow checker maps so well to
| the ownership model of a DOM tree in theory. But in practice, DOM
| nodes often need shared mutable state (parent pointers, child
| pointers, event listeners), which forces you into Rc<RefCell<T>>
| hell in Rust.
|
| Zig's manual memory management might actually be more ergonomic
| for a DOM implementation specifically because you can model the
| graph relationships more directly without fighting the compiler,
| provided you have a robust strategy for the arena allocation.
| Excited to learn from Lightpanda's implementation when it's out.
| fbouvier wrote:
| Hi, I am Francis, founder of Lightpanda. We wrote a full
| article explaining why we choose Zig over Rust or C++, if you
| are interested: https://lightpanda.io/blog/posts/why-we-built-
| lightpanda-in-...
|
| Our goal is to build a headless browser, rather than a general
| purpose browser like Servo or Chrome. It's already available if
| you would like to try it: https://lightpanda.io/docs/open-
| source/installation
| barishnamazov wrote:
| Thanks Francis, appreciate the nice & honest write-up with
| the thought process (while keeping it brief).
| parhamn wrote:
| Off topic note: I read the website and a few pages of the
| docs and it's unclear to me for what I can use LightPanda
| safely. Like say I wanted to swap my it as my engine on
| playwright, what are the tradeoffs? What things are
| implemented, what isnt?
| h33t-l4x0r wrote:
| I think it's really more of an alternative to JSDom than it
| is an alternative to Chromium. It's not going to fool any
| websites that care about bots into thinking it's a real
| browser in other words.
| fbouvier wrote:
| Thanks for the feedback, we will try to make this clearer
| on the website. Lightpanda works with Playwright, and we
| have some docs[1] and examples[2] available.
|
| Web APIs and CDP specifications are huge, so this is still
| a work in progess. Many websites and scripts already work,
| while others do not, it really depends on the case. For
| example, on the CDP side, we are currently working on
| adding an Accessibility tree implentation.
|
| [1] https://lightpanda.io/docs/quickstart/build-your-first-
| extra...
|
| [2] https://github.com/lightpanda-
| io/demo/tree/main/playwright
| epolanski wrote:
| I was actually interested into using lightpanda for E2Es
| to be honest, because halving the feedback cycle would be
| very valuable to me.
| infogulch wrote:
| Maybe you should recommend a recipe for configuring
| playwright with both chromium and lightpanda backends so
| a given project can compare and evaluate whether
| lightpanda could work given their existing test cases.
| nicoburns wrote:
| I see you're using html5ever for HTML parsing, and like it's
| trait/callback based API (me too). It looks like style/layout
| is not in scope at the moment, but if you're ever looking at
| adding style/layout capabilities to lightpanda, then you may
| find it useful to know that Stylo [0] (CSS / style system)
| and Taffy [1] (box-level layout) are both avaiable with a
| similar style of API (also Parley [2] which has a slightly
| different API style but can be combined with Taffy to
| implement inline/text layout).
|
| [0]: https://github.com/servo/stylo
|
| [1]: https://github.com/DioxusLabs/taffy
|
| [2]: https://github.com/linebender/parley
|
| ---
|
| Also, if you're interested in contributing C bindings for
| html5ever upstream then let me know / maybe open a github
| issue.
| quotemstr wrote:
| Choosing something like Zig over C++ on simplicity grounds is
| going to be a false economy. C++ features exist _for a
| reason_. The complexity is in the domain. You can 't make a
| project simpler by using a simplistic language: the
| complexity asserts itself somehow, somewhere, and if a
| language can't express the concept you want, you'll end up
| with circumlocution "patterns" instead.
|
| Build system complexity disappears when you set it up too.
| Meson and such can be as terse as your Curl example.
|
| I mean, it's your project, so whatever. Do what you want. But
| choosing Zig for the stated reasons is like choosing a car
| for the shape of the cupholders.
| hnlmorg wrote:
| That's not fully true though. There's different types of
| complexity:
|
| - project requirements
|
| - requirements forced upon you due to how the business is
| structured
|
| - libraries available for a particular language ecosystem
|
| - paradigms / abstractions that a language is optimised for
|
| - team experiences
|
| Your argument is more akin to saying "all general purpose
| languages are equal" which I'm sure you'd agree is false.
| And likewise, complexity can and will manifest itself
| differently depending on language, problems being solved,
| and developer preferences for different styles of software
| development.
|
| So yes, C++ complexity exists for a reason (though I'd
| personally argue that "reason" was due to "design by
| committee"). But that doesn't mean that reason is directly
| applicable to the problems the LightPanda team are
| concerned about solving.
| vegabook wrote:
| C++ features for complexity management are not ergonomic
| though, with multiple conflicting ideas from different eras
| competing with each other. Sometimes demolition and rebuild
| from foundations is paradoxically simpler.
| meheleventyone wrote:
| > C++ features exist for a reason.
|
| But sometimes not good ones. Lot's of domains make
| tradeoffs about what features of C++ to actually make use
| of. It's an old language with a lot of cruft being used
| across a wide set of problems that don't necessarily share
| engineering trade offs.
| Philpax wrote:
| Your Swiss Army Knife with a myriad of 97 oddly-shaped
| tools may be able to do any job anyone could ask of it, but
| my Swiss Army Knife of 10 well-designed tools that are
| optimal for my set of tasks will get _my_ job done with
| much less frustration.
| zipy124 wrote:
| A lot of them only still exist for backwards
| compatabilities sake though. And a decent amount because
| adding something as a language extension rather than
| building the language around it has consequences.
| jandrewrogers wrote:
| C++ features exist for a reason but it may not be a reason
| that is applicable to their use case. For example, C++ has
| a lot of features/complexity that are there primarily to
| support low-level I/O intensive code even though almost no
| one writes I/O intensive code.
|
| I don't see why C++ would be materially better than Zig for
| this particular use case.
| Jweb_Guru wrote:
| Respectfully, for browser-based work, simplicity is
| absolutely not a good enough reason to use a memory-unsafe
| language. Your claim that Zig is in some way safer than Rust
| for something like this is flat out untrue.
| hello_moto wrote:
| In that blog post, the author said safer than C not Rust.
| dnautics wrote:
| What is your attack model here? Each request lives in its
| own arena allocator, so there is no way for any potentially
| malicious JavaScript to escape and read memory owned by any
| other request, even if there is a miscode. otherwise, VM
| safety is delegated to the V8 core.
| nwienert wrote:
| Would be helpful to compare Lightpanda to Webkit, Playwright
| has a driver for example and its far faster and less resource
| hungry than Chrome.
|
| When I read your site copy it struck me as either naive to
| that, or a somewhat misleading comparison, my feedback would
| be just to address it directly alongside Chrome.
| aatd86 wrote:
| Would be great if it could be used as a wasm library... Just
| saying... Is it? I would actually need and use this.
| pjmlp wrote:
| And use-after-free, when that arena's memory goes away.
| pron wrote:
| But arenas have substantial benefits. They may be one of the
| few remaining reasons to use a low-level (or "systems
| programming") language in the first place. Most things are
| tradeoffs, and the question isn't what you're giving up, but
| whether you're getting the most for what you're paying.
| pjmlp wrote:
| Arenas are also available in languages with automatic
| memory management, e.g. D, C# and Swift, to use only modern
| languages as example.
|
| Thus I don't consider that a reason good enough for using
| Zig, while throwing away the safety from modern languages.
| pron wrote:
| First, Zig is more modern than any of the languages you
| mention. Second, I'm not aware that any of those
| languages offer arenas similar in their power and utility
| to Zig's while offering UAF-freedom at the same time.
| Note that "type-safe" arenas are neither as powerful as
| general purpose arenas nor fully offer UAF-freedom. I
| could be wrong (and if I am, I'd really love to see an
| arena that's both general and safe), but I believe that
| in all these languages you must compromise on either
| safety or the power of the arena (or both).
| metaltyphoon wrote:
| > First, Zig is more modern than any of the languages you
| mention
|
| How so? This feels like an empty statement at best.
| pron wrote:
| "modern: relating to the present or recent times as
| opposed to the remote past". I agree it's not a useful
| concept here but I didn't bring it up. Specifically, I
| don't think there's any consideration that had gone into
| the design of D, C#, or Rust that escaped Zig's designer.
| He just consciously made different choices based on the
| data available and his own judgment.
| pjmlp wrote:
| Not really modern, it is Object Pascal/Modula-2
| repackaged in C like syntax.
|
| The only thing relatively modern would be compile time
| execution, if we forget about how long some languages
| have had reader macros, or similar capabilities like D's
| compile time metaprogramming.
|
| Also it is the wrong direction when the whole industry is
| moving into integrity by default on cyber security
| legislation.
|
| There are several examples around of doing arenas in said
| languages.
|
| https://dlang.org/phobos/std_experimental_allocator.html
|
| You can write your own approach with the low level
| primitives from Swift, or ping back into the trusty
| NSAutoreleasePool.
|
| One example for C#, https://github.com/Enichan/Arenas
| pron wrote:
| > Not really modern, it is Object Pascal/Modula-2
| repackaged in C like syntax.
|
| That's your opinion, but I couldn't disagree more. It
| places partial evaluation as its biggest focus more so
| than any other language in history, and is also
| extraordinarily focused on tooling. There isn't any piece
| of information nor any technique that was known to the
| designers of those older languages and wasn't known to
| Zig's designer. In some situations, he intentionally
| chose different tradeoffs _on which there is no
| consensus_. It 's strange to insist that there is some
| consensus when many disagree.
|
| I have been doing low-level programming (in C, C++, and
| Ada in the 90s) for almost 30 years, and over that time I
| have not seen a low-level language that's as
| revolutionary in its approach to low-level programming as
| Zig. I don't know if it's good, but I find its design
| revolutionary. You certainly don't have to agree with my
| assessment, but you do need to acknowledge that some
| people very much see it that way, and don't think it's
| merely a "repackaged" Pascal-family language in any way.
|
| I guess you could say that you personally don't care
| about Zig's primary design points and when you ignore
| them you're left with something that you find similar to
| other languages, but that's like saying that if you don't
| care about Rust's borrow- and lifetime checking, it's
| basically just a mix of C++ and ML. It's perfectly valid
| to not care about what matters most to some language's
| designer, and it's perfectly valid to claim that what
| matters to them most is misguided, but it is not valid to
| ignore a language's design core when describing it just
| because you don't care about it.
|
| > Also it is the wrong direction when the whole industry
| is moving into integrity by default on cyber security
| legislation.
|
| Again, that is an opinion, but not one I agree with. For
| one, Rust isn't as safe as other safe languages given its
| relatively common reliance on unsafe. If spatial and
| temporal memory safety were the dominating concerns,
| there wouldn't be a need for Rust, either (and it
| wouldn't have exposed unsafe). Clearly, everyone
| recognises that there are other concerns that sometimes
| dominate, and it's pretty clear that some people, who are
| no less knowledgeable about the software industry and its
| direction, prefer Zig. There is no consensus here either
| way, and I'm not sure there can be one. They are
| different languages that suit different people/projects'
| preferences.
|
| Now, I agree that there's definitely more motion toward
| more correctness - which is great! - and I probably
| wouldn't write a banking or healthcare system in Zig, but
| I wouldn't write it in Rust, either. People reach for low
| level languages precisely when there may be a need to
| compromise on safety in some way, and Rust and Zig make
| _different_ compromises, both of which - as far as I can
| tell - can be reasonable.
|
| > There are several examples around of doing arenas in
| said languages.
|
| From what I can tell, all of them either don't provide
| freedom from UAF, or they're not nearly as general as a
| proper arena.
|
| I know of one safe and general arena design in RTSJ,
| which immidiately prevents a reference to a non-enclosing
| arena from being written into an object, but it comes
| with a runtime cost (which makes sense for hard realtime,
| where you want to sacrifice performance for worst-case
| predictability).
| defen wrote:
| Wouldn't C# and Swift make it tough to integrate with
| other languages? Whereas something written in Zig (or
| Rust) can integrate with anything that can use the C ABI?
| pyrolistical wrote:
| Both c# and swift have first party c abi integration
| dnautics wrote:
| Yeah that's certainly possible but leaking a pointer like
| this seems like it would be really easy to spot?
| dwattttt wrote:
| It's harder than you'd expect. Depending on what kind of
| bucketing an arena does (by size or by type), a stale
| reference may end up pointing to another piece of memory of
| the correct type, which is still wrong, but more subtly
| than a crash.
| IshKebab wrote:
| I don't think it's really that bad in Rust. If you're happy
| with an arena in Zig you can do exactly the same thing in Rust.
| There are a ton of options listed here:
| https://donsz.nl/blog/arenas/
|
| Some of them even prevent use after free (the "ABA mitigation"
| column).
| mijoharas wrote:
| I'm not super experienced with zig, but I always think that
| in the same way that rust forces you to think about ownership
| (by having the borrow checker - note: I think of this as a
| good thing personally) zig makes you think upfront about your
| allocation (by making everything that can allocate take an
| allocator argument.).
|
| It makes everything very explicit, and you can always _see_
| where your allocations are happening in a way that you can't
| (as easily, or as obviously - imo) in rust.
|
| It seems like something I quite like. I'm looking forward to
| rust getting an effects system/allocator api to help a little
| more with that side of things.
| silon42 wrote:
| The problem is deallocation... unless you tie the allocated
| object to an arena allocator with a lifetime somehow (Rust
| can model that).
| mijoharas wrote:
| Yep, rust forces you to think about lifetimes. Zig only
| suggests it (because you're forced to think about
| allocation, which makes you naturally think about the
| lifetime usually) but does not help you with it/ensure
| correctness.
|
| It's still nice sometimes to ensure that you have to
| think about allocation everywhere, and can change the
| allocation strategy for something that works for your
| usecase. (hence why I'm looking forward to the allocator
| api in rust to get the best of both worlds).
| IshKebab wrote:
| That's true and I liked the idea of it until I started
| writing some Zig where I needed to work with strings. Very
| painful. I'm sure you typically get a bit faster string
| manipulation code than what you'd get with Rust but I don't
| think it's worth the cost (Rust is pretty fast already).
| jamiejquinn wrote:
| Can't agree more. I hope someone puts some work into a
| less painful way to manage strings in std. I would but I
| don't manipulate strings quite enough to support usecases
| more than basically concatenation...
| pjmlp wrote:
| Which is hardly any different from me using PurifyPlus back
| in 2000.
| IshKebab wrote:
| It's very different.
| kryps wrote:
| No, you can't do the same thing in Rust, because Rust crates
| and the standard library generally use the global allocator
| and not any arena you want to use in your code.
| IshKebab wrote:
| I mean you can store the nodes in an arena so you don't
| have to deal with the borrow checker getting upset with
| your non-tree ownership structure. That's the context. We
| weren't talking about arena use for speed/efficiency
| purposes. In that case you are right; it's much more
| awkward to use custom allocators in Rust.
| galangalalgol wrote:
| Too late now, but is the requirement for shared mutable state
| inherent in the problem space? Or is it just because we still
| thought OOP was cool when we started on the DOM design?
| 7bit wrote:
| > without fighting the compiler
|
| It's unfortunate that "writing safe code" is constantly being
| phrased in this way.
|
| The borrow checker is a deterministic safety net. Claiming Zig
| is easier ignores that its lack of safety checks is what makes
| it feel easier; if Zig had Rust's guarantees, the complexity
| would be the same. Comparing them like this is apples vs.
| oranges.
| senko wrote:
| The fact that Zig doesn't have Rust's guarantees doesn't mean
| Zig does not have safety checks. The safety checks that Zig
| does have are _different_ , and are different in a way that's
| uniquely useful for this particular project.
|
| Zig's check absolutely don't go to the extent that Rust's do,
| which is kind of the point here. If you _do_ need to go
| beyond safe code in Rust, Zig is safer than unsafe code in
| Rust.
|
| Saying Zig lacks safety checks is unfortunate, although I
| wouldn't presume you meant it literally and just wanted to
| highlight the difference.
| pjmlp wrote:
| Thing is, those safety checks are also available in C and
| C++, provided that one uses the right tools like PVS and
| PurifyPlus (just to quote two examples), and now ongoing AI
| based tooling efforts for verification, thus the question
| is why a language like Zig in the 21st century, other than
| "I don't like either C++ or Rust".
| 7bit wrote:
| I never said Zig has no safety features. What I said is
| true, though. If it would have Rusts guarantees (as in: The
| same) it would be more complex.
| pron wrote:
| That's a very narrow way of looking at things. ATS has a much
| stronger "deterministic safety net" than Rust, yet the reason
| to use Rust over ATS is that "fighting the compiler" is
| easier in Rust than in ATS. On the other hand, if any cost is
| worth whatever level of safety Rust offers for any project,
| than Rust wouldn't exist because there are far more popular
| languages with equal (or better) safety. So Rust's design
| itself is an admission that 1. more compile-time safety is
| always better, even if it complicates the language (or
| everyone who uses Rust should use ATS), and 2. any cost is
| worth paying for safety (or Rust wouldn't exist in the first
| place).
|
| Safety has some value that isn't infinite, and a cost that
| isn't zero. There are also different kinds of safety with
| different value and different costs. For example, spatial
| memory safety appears to have more value than temporal safety
| (https://cwe.mitre.org/top25/archive/2025/2025_cwe_top25.html
| ) and Zig offers spatial safety. The question is always what
| you're paying and what you're getting in return. There
| doesn't appear to be a universal right answer. For some
| projects it may be worth it to pay for more safety, and for
| other it may be better to pay for something else.
| Ygg2 wrote:
| > 1. more compile-time safety is always better, even if it
| complicates the language (or everyone who uses Rust should
| use ATS), and 2. any cost is worth paying for safety (or
| Rust wouldn't exist in the first place).
|
| You keep repeating this. It's not true. If what you said
| was true, Rust would have adopted HKT, and God knows
| whatever type astronomy Haskell & Scala cooked up.
|
| There is a balancing act, and Rust decided to plant a flag
| in memory safety without GC. The fact that Zig, didn't
| expand on this, but went backwards is more of an indictment
| of programmers unwilling to adapt and perfect what came
| before, but to reinvent it in their own worse way.
|
| > There are also different kinds of safety with different
| value and different costs. For example, spatial memory
| safety appears to have more value than temporal safety (htt
| ps://cwe.mitre.org/top25/archive/2025/2025_cwe_top25.html)
|
| How did you derive this from the top 25 of CWEs? Let's say
| you completely remove the spatial memory issues. You still
| get temporal memory issues at #6.
| pron wrote:
| Rust does have a GC, but I agree it planted its flag at
| some intermediate point on the spectrum. Zig didn't "go
| backwards" but planted its own flag ever so slightly
| closer to C than to ATS (although both Rust and Zig are
| almost indistinguishable from C when compare to ATS). I
| don't know if where Rust planted its flag is universally
| better than where Zig planted its flag, but 1. no one
| else does either, 2. both are compromises, and 3. it's
| uncertain whether a universal sweet spot exists in the
| first place.
|
| > How did you derive this from the top 25 of CWEs? Let's
| say you completely remove the spatial memory issues. You
| still get temporal memory issues at #6.
|
| Sure, but spatial safety is higher. So if Rust's
| compromise, we'll exact a price on temporal safety and
| have both temporal and spatial safety, is reasonable,
| then so is Zig's that says, the price on temporal safety
| is too high for what you get in return, but spatial
| safety only is a better deal. Neither go as far as ATS in
| offering, in principle, the ability to avoid all bugs.
| Nobody knows whether Rust's compormise is universally
| better than Zig's or vice versa (or perhaps neither is
| universally better), but I find it really strange to
| arbitrarily claim that one compromise is reasonable and
| the other isn't, where both are obviously compromises
| that recognise there are different benefits and different
| costs, and that not every benefit is worth any cost.
| Ygg2 wrote:
| > Rust does have a GC
|
| It doesn't. Not by any reasonable definition of having a
| GC.
|
| And "opt-in non-tracing GC that isn't used largely
| throughout the standard library" is not a reasonable
| definition.
|
| > Nobody knows whether Rust's compormise is universally
| better than Zig's
|
| When it comes to having more segfaults, we know. Zig
| "wins" most segfaults per issue Razzie Award.
|
| This is what happens when you ignore one type of memory
| safety. You have to have both. Just ask Go.
| pron wrote:
| > And "opt-in non-tracing GC that isn't used largely
| throughout the standard library" is not a reasonable
| definition.
|
| Given that refcounting and tracing are the two classic GC
| algorithms, I don't see what specifying "non tracing"
| here does, and reference-counting with special-casing of
| the one reference case is still reference counting. I
| don't know if the "reasonable definition" of GC matters
| at all, but if it does, this does count as one.
|
| I agree that the one-reference case is handled in the
| language and the shared reference case is handled in the
| standard library, and I think it can be reasonable to
| call using just the one-reference case "not a GC", but
| most Rust programs do use the GC for shared references.
| It is also true that Rust depends _less_ on GC than Java
| or Go, but that 's not the same as not having one.
|
| > When it comes to having more segfaults, we know. Zig
| "wins" most segfaults per issue Razzie Award.
|
| And Rust wins the Razzie Award for most painful
| development and lack of similarly powerful arenas. It's
| like declaring that you win by paying $100 for something
| while I paid $50 for something else without comparing
| what we got for the money, or declaring that you win by
| getting a faster car without looking at how much I paid
| for mine.
|
| > This is what happens when you ignore one type of memory
| safety.
|
| When you have less safety for any property, you're
| guarnateed to have more violations. This is what you buy.
| Obviously, this doesn't mean that avoiding those extra
| violations is necessarily worth the cost you pay for that
| extra safety. When you buy something, looking just at
| what you pay or just at what you get doesn't make any
| sense. The question is whether this is the best deal for
| your case.
|
| Nobody knows if there is a universal best deal here let
| alone what it is. What is clear is that nothing here is
| free, and that nothing here has infinite value.
| Ygg2 wrote:
| > I don't know if the "reasonable definition" of GC
| matters at all
|
| If you define all non-red colors to be green, it is
| impossible to talk about color theory.
|
| > And Rust wins the Razzie Award for most painful
| development and lack of similarly powerful arenas.
|
| That's a non-quantifiable skill issue. Segfaults per
| issue is a quantifiable thing.
|
| > When you have less safety for any property, you're
| guarnateed to have more violations.
|
| If that's what you truly believed outside some debate
| point. Then you'd be advocating for ATS or Ada.SPARK, not
| Zig.
| pron wrote:
| > If you define all non-red colors to be green, it is
| impossible to talk about color theory.
|
| Except reference counting is one of _the_ two classical
| GC algorithms (alongside tracing), so I think it 's
| strange to treat it as "not a GC". But it is true that
| GC/no-GC distinction is not very meaningful given how
| different the tradeoffs that different GC algorithms make
| are. Even within these basic algorithms there are
| combinations. For example a mark-and-sweep collector is
| quite different from a moving collector, or CPython uses
| refcouting for some things and tracing for others.
|
| > That's a non-quantifiable skill issue. Segfaults per
| issue is a quantifiable thing.
|
| That it's not as easily quantifiable doesn't make it any
| less real. If we compare languages only by easily
| quantifiable measures, there would be few differences
| between them (and many if not most would argue that we're
| missing the differences that matter to them most). For
| example, it would be hard to distinguish between Java and
| Haskell. It's also not necessarily a "skill issue". I
| think that even skilled Rust users would admit that
| writing and maintaining a large program in TypeScript or
| Java takes less effort than doing the same in Rust.
|
| Also, ATS has many more compile-time safety capabilities
| than either Rust or Zig (in fact, compared to ATS, Rust
| and Zig are barely distinguishable in what they can
| guarantee at runtime), so according to your measure, both
| Rust and Zig lose when we consider other alternatives.
|
| > Then you'd be advocating for ATS or Ada.SPARK, not Zig.
|
| Quite the opposite. I'm pointing out that, at least as
| far as this discussion goes, every added value comes with
| added cost that needs to be considered. If what you truly
| believed is that more compile-time safety always wins,
| then it is you who should be advocating for ATS over
| Rust. I'm saying that we don't know where the cost-benfit
| sweet point is or, indeed, even if there's only one such
| sweey point or multiple. I'm certainly not advocating for
| Zig as a universal choice. I'm advocating for selecting
| the right tradeoffs for every project, and I'm rejecting
| the claim that whatever benefits Rust or Zig have
| compared to the other are free. Both (indeed, all
| languages) require you to pay in some way to get what
| they're offering. In other words, I'm advocating can both
| be more or less appropriate than the other, depending on
| the situation and against the position that Rust is
| always superior, which is based on only looking at its
| advantages and ignoring its disadvantages (which, I
| think, are quite significant).
| Ygg2 wrote:
| > Except reference counting is one of the two classical
| GC algorithms (alongside tracing), so I think it's
| strange to treat it as "not a GC". But it is true that
| GC/no-GC distinction is not very meaningful given how
| different the tradeoffs that different GC algorithms make
| are.
|
| That's not the issue. Calling anything with opt-in
| reference counting a GC language. You're just fudging
| definitions to get to the desired talking point. I mean,
| C is, by that definition, a GC language. It can be
| equipped with
|
| > That it's not as easily quantifiable doesn't make it
| any less real.
|
| It makes it more subjective and easy to bias. Rust has a
| clear purpose. To put a stop to memory safety errors.
| What does it's painful to use? Is it like Lisp to Haskell
| or C to Lisp.
|
| > For example, it would be hard to distinguish between
| Java and Haskell.
|
| It would be possible to objectively distinguish between
| Java and Haskell, as long as they aren't feature-by-
| feature compatible.
|
| If you can make a program that halts on that feature, you
| can prove you're in language with that feature.
|
| > If what you truly believed is that more compile-time
| safety always wins, then it is you who should be
| advocating for ATS over Rust.
|
| Yeah, because you fight a strawman. Having a safe
| language is a precondition but not enough. I want it to
| be as performant as C as well.
|
| Second, even if you have the goal of moving to ATS,
| developing ATS-like isn't going to help. You need a mass
| of people to move there.
| pron wrote:
| > Calling anything with opt-in reference counting a GC
| language
|
| I didn't call it "a GC language" (I don't know what that
| term would even mean). I said, and I quote "Rust does
| have a GC". That's it. And it does. Calling it "opt in"
| when most Rust programs use the GC is also misleading.
|
| > Rust has a clear purpose. To put a stop to memory
| safety errors.
|
| Yes, but 1. other languages do it, too, so clearly
| "stopping memory errors" isn't enough, 2. Rust does it in
| a way that requires much more use of unsafe escape
| hatches than other languages, so it clearly recognises
| the need for some compromise, and 3. Rust's safety very
| much comes at a cost.
|
| So its purpose may be clear, but it is also very clear
| that it makes tradeoffs and compromises, which implies
| that other tradeoffs and compromises may be reasonable,
| too.
|
| But anyway, having a very precise goal makes some things
| quantifiable, but I don't think anyone thinks that's what
| makes a language better than another. C and JS also have
| very clear purposes, but does that make them better than,
| say, Python?
|
| > Having a safe language is a precondition but not
| enough. I want it to be as performant as C as well... You
| need a mass of people to move there.
|
| So clearly you have a few prerequisites, not just memory
| safety, _and_ your recognise the need for some pragmatic
| compromises. Can you accept that your prerequisites and
| compromises might not be universal and there may be
| others that are equally reasonable, all things
| considered?
|
| I am a proponent of software correctness and formal
| methods (you can check out my old blog:
| https://pron.github.io) and I've learnt a lot over my
| decades in industry about the complexities of software
| correctness. _When_ I choose a low-level language, to
| switch away from C++ my prerequisites are: a simple
| language with no implicitness (I want to see every
| operation on the page) as I think it makes code reviews
| more effective (the effectiveness of code reviews has
| been shown empirically, although not the relationship to
| language design) and fast compilation to allow me to
| write more tests and run them more often.
|
| I'm not saying that my requirements are universally
| superior to yours, and my interests also lie in a high
| emphasis on correctness (which extends far beyond mere
| memory safety), it's just that my conclusions and perhaps
| personal preferences lead me to prefer a different path
| to your preferred one. I don't think anyone has any
| objective data to support the claim that my preferred
| path to correctness is superior to yours or vice-versa.
|
| I can say, however, that in the 1970s, proponents of
| deductive proofs warned of an impending "software crisis"
| and believed that proofs are the only way to avoid it (as
| proofs are "quantifiably" exhaustive). Twenty years
| later, one of them, Tony Hoare, famously admitted he was
| wrong, and that less easily quantifiable approaches
| turned out to be more effective than expected (and more
| effective than deductive proofs, at least of complicated
| properties). Again, we must be careful not to extrapolate
| in either direction, but my point is that software
| correctness is a very complicated subject, and nobody
| knows what the "best" path is, or even if there is one
| such best path.
| 7bit wrote:
| You're changing the argument. The point wasn't whether more
| safety is "worth it", but that comparing ease while
| ignoring which invariants are enforced is misleading. Zig
| can feel simpler because it encodes fewer guarantees. I'm
| not saying one approach is better, only that this
| comparison shifts the goalposts.
| pron wrote:
| Then we're in agreement. Both languages give you
| something that may be important, but it has a price.
| tcfhgj wrote:
| Imo "safety" in safe Rust is higher than it is in more
| popular languages.
|
| Data races, type state pattern, lack of nulls, ...
| pron wrote:
| This is comparing what Rust has and other languages don't
| without also doing the opposite. For example, Java
| doesn't enforce data-race freedom, but its data races are
| safe, which means you can write algorithms with benign
| races safely (which are very useful in concurrent
| programming [1]), while in Rust that requires unsafe.
| Rust's protection against memory leaks that can cause a
| panic is also weaker, as is Rust's ability to recover
| from panics in general. Java is now in the process of
| eliminating the unsafe escape hatch altogether except for
| FFI. Rust is nowhere near that. I.e. sometimes safe Rust
| has guarantees that mean that programs need to rely on
| unsafe code more so than in other languages, which allows
| saying that safe Rust is "safer" while it also means that
| fewer programs are actually written purely in safe Rust.
| The real challenge is increasing safety without also
| increasing the number of programs that need to circumvent
| it or increasing the complexity of the language further.
|
| [1]: A benging race is when multiple tasks/threads can
| concurrently write to the same address, but you know they
| will all write the same value.
| pron wrote:
| I don't think that a language that was meant to compete with
| C++ and in 10+ years hasn't captured 10% of C++'s (already
| diminished) market share could be said to have become "kind of
| the default" for anything (and certainly not when that requires
| generalising from n[?]1).
| anal_reactor wrote:
| The problem is that the number of browser engines is n=2.
| drnick1 wrote:
| Interestingly, Ladybird, which aims at being the n = 3, is
| also written in C++.
| pjmlp wrote:
| It has for Amazon, Adobe, Microsoft, Google and the Linux
| kernel.
|
| It remains to be seen which big name will make Zig
| unavoidable.
| surajrmal wrote:
| While certain teams within Google are using rust by
| default, I'm not sure rust is anywhere close in scale for
| new lines of code committed per week to c++.
| paavohtl wrote:
| For Android specifically, by Q3 of last year more new
| lines of Rust were being added per week than new lines of
| C++: https://security.googleblog.com/2025/11/rust-in-
| android-move...
| pron wrote:
| > It has for Amazon, Adobe, Microsoft, Google and the Linux
| kernel.
|
| I don't think so. I don't know about Adobe, but it's not a
| meaningful statement for the rest. Those companies default
| to writing safe code in languages other than Rust, and the
| Linux kernel defaults to unsafe code in C. BTW, languages
| favoured by those projects/companies do not reliably
| represent industry-wide preferences, let alone defaults.
| You could certainly say that of the two languages accepted
| so far in the Linux kernel, the only safe one is Rust, but
| there's hardly any "default" there.
|
| > It remains to be seen which big name will make Zig
| unavoidable.
|
| I have no idea whether or not Zig will ever be successful,
| but at this point it's pretty clear that Rust's success has
| been less than modest at best.
| pjmlp wrote:
| It is a clear mandate on those companies that whatever
| used to be C or C++, should be written in Rust for green
| field development.
|
| Whatever could be done in programming languages with
| automatic memory management was already being done.
|
| Anyone deploying serverless code into Amazon instances is
| running of top of Firecracker, my phone has Rust code
| running on it, and whatever Windows 11 draws something
| into the screen, it goes through Rust rewrite of the GDI
| regions logic, all the Azure networking traffic going
| through Azure Boost cards does so via Rust firmware.
|
| Adobe is the sponsor for the Hylo programming language,
| and key figures in the C++ community, are doing Rust
| talks nowadays.
|
| "Adobe's memory safety roadmap: Securing creativity by
| design"
|
| https://blog.adobe.com/security/adobes-memory-safety-
| roadmap...
|
| Any hobby language author would like to have 1% of the
| said modest Rust's success, I really don't get the
| continuous downplay of such achievement.
| bluecalm wrote:
| >>It is a clear mandate on those companies that whatever
| used to be C or C++, should be written in Rust for green
| field development. >>Any hobby language author would like
| to have 1% of the said modest Rust's success, I really
| don't get the continuous downplay of such achievement.
|
| This is a political achievement, not technical one.
| People are bitter about it as it doesn't feel organic and
| feel pushed onto them.
| dwattttt wrote:
| There is technical achievement in:
|
| > Anyone deploying serverless code into Amazon instances
| is running of top of Firecracker, my phone has Rust code
| running on it, and whatever Windows 11 draws something
| into the screen, it goes through Rust rewrite of the GDI
| regions logic, all the Azure networking traffic going
| through Azure Boost cards does so via Rust firmware.
|
| Ignoring it doesn't make those achievements political
| rather than technical.
| pron wrote:
| > It is a clear mandate on those companies that whatever
| used to be C or C++, should be written in Rust for green
| field development. Whatever could be done in programming
| languages with automatic memory management was already
| being done.
|
| I don't know how true either of these statements is or to
| what extent the mandate is enforced (at my company we
| also have language mandates, but what they mean is that
| to use a different language all you need is an
| explanation and a manager to sign off), but I'll ask
| acquaintances in those companies (Except Adobe; don't
| know anyone there. Although the link you provided doesn't
| say Rust; it says "Rust or Swift". It also commits only
| to "exploring ways to reduce the use of new C and C++
| code in safety critical parts of our products to a
| fraction of current levels").
|
| What I do know is that the rate at which Rust is adopted,
| is significantly lower than the rate at which C++, Java,
| C#, Python, TS, and even Go were adopted, even in those
| companies.
|
| Now, there's no doubt that Rust has some real adoption,
| and much more than just hobby languages. Its rate of
| adoption is significantly higher than that of Haskell, or
| Clojure, or Elixir were (but lower than that of Ruby or
| PHP). That is without a doubt a great accomplishment, but
| not what you'd expect from a language that wishes to
| become _the_ successor to C++ (and doesn 't suffer from
| lack of hype despite its advanced age). Languages that
| offer a significant competitive advantage, or even the
| perception of one, spread at a faster pace, certainly
| those that eventually end up in the top 5.
|
| I also think there's little doubt that the Rust "base" is
| more enthusiastic than that of any language I remember
| except maybe that of Haskell's resurgence some years back
| (and maybe Ruby), and that enthusiasm may make up for
| what they lack in numbers, but at some point you need the
| numbers. A middle-aged language can only claim to be the
| insurgent for so long.
| nicoburns wrote:
| This table is informative as to exactly what lightpanda is:
| https://lightpanda.io/blog/posts/what-is-a-true-headless-bro...
|
| TL;DR: It does the following:
|
| - Fetch HTML over the network
|
| - Parse HTML into a DOM tree
|
| - Fetch and execute JavaScript that manipulates the DOM
|
| But not the following:
|
| - Fetch and parse CSS to apply styling rules
|
| - Calculate layout
|
| - Fetch images and fonts for display
|
| - Paint pixels to render the visual result
|
| - Composite layers for smooth scrolling and animations
|
| So it's effectively a net+DOM+script-only browser with no
| style/layout/paint.
|
| ---
|
| Definitely fun for me to watch as someone who is making a
| lightweight browser engine with a different set of trade-offs
| (net+DOM+style/layout/paint-only with no script)
| karel-3d wrote:
| When I was working before on something that used headless
| browser agents, the ability to do a screenshot (or even a
| recording) was really great for debugging... so I am not sure
| about the "no paint". But hey everything in life is a trade-
| off.
| pzo wrote:
| yeah I feel the same, I think even having a screenshot of
| part of rendered page or full page can be useful even for
| machines considering how heavy those HTML can be to parse and
| expensive for LLM context. Sometimes (sub)screenshot is just
| a better kind of compression
| fbouvier wrote:
| Yes HTML is too heavy and too expensive for LLM. We are
| working on a text-based format more suitable for AI.
| httpteapot wrote:
| What do you think of the DeepSeek OCR approach where they
| say that vision tokens might better compress a document
| than its pure text representation?
|
| https://news.ycombinator.com/item?id=45640594
|
| I've spent some time feeding llm with scrapped web pages
| and I've found that retaining some style information
| (text size, visibility, decoration image content) is non
| trivial.
| fbouvier wrote:
| Keeping some kind of style information is definitely
| important to understand the semantics of the webpage.
| hobofan wrote:
| Really depends on what you want to do with the agents. Just
| yesterday I was looking for something like this for our web
| access MCP server[0]. The only thing that it needs to do is
| visit a website and get the content (with JS support, as it's
| expected that most pages today use JS), and then convert that
| to e.g. Markdown.
|
| I'm not too happy with the fact that Chrome is one of our
| memory-hungriest parts of all the MCP servers we have in use.
| The only thing that exceeds that in our whole stack is the
| Clickhouse shard, which comes with Langfuse. Especially if
| you are looking to build a "deep research" feature that may
| access a few hundreds of webpages in a short timeframe,
| having a lightweight alternative like Lightpanda can make
| quite the difference.
|
| [0]: https://github.com/EratoLab/web-access-mcp
| warpech wrote:
| > So it's effectively a net+DOM+script-only browser with no
| style/layout/paint.
|
| > ---
|
| > Definitely fun for me to watch as someone who is making a
| lightweight browser engine with a different set of trade-offs
| (net+DOM+style/layout/paint-only with no script)
|
| Both projects (Lightpanda, DioxusLabs/blitz) sound very
| interesting to me. What do you think about rendering patterns
| that require both script+layout for rendering, e.g. virtual
| scrolling of large tables?
|
| What would be a good pattern to make virtual scrolling work
| with Lightpanda or Blitz?
| nicoburns wrote:
| So Blitz does technically have scripting, it's just Rust
| scripting rather than JavaScript scripting. So the plan for
| virtual scrolling would likely be to implement it in Rust.
|
| If your aim is to render a UI (ala Electron/Flutter) then we
| have a React-style framework (Dioxus) that runs on top of
| Blitz, and allows you access to the low-level Rust API of the
| DOM for advanced use cases (although it's still a WIP and
| this API is a bit rough atm). I'm also hoping to eventually
| have a built-in `RecyclerView`-like widget for this (that can
| bypass the style/layout systems for much more efficient
| virtual scrolling).
| warpech wrote:
| Thanks! But I meant JS based virtual scrolling in web
| pages. E.g. dynamic data tables that only render the part
| of the table that fits in the viewport.
| krichprollsch wrote:
| For scrolling, when using Intersection Observer, we currently
| assume all elements are visible. So, if you register an
| observer, we will dispatch an entry indicating an
| intersection with a ratio of 1.0.
| everlier wrote:
| Wow. Lightpanda is absolutely bonkers of a project. I'd pay
| dearly for such an option a few years back.
| kristopolous wrote:
| I've been using it for months now ever since I saw their
| presentation at GitHub
|
| This is a common flow for me lightpanda url |
| markitdown (microsoft) | sd (day50 streamdown)
|
| I even have it as a shell alias, wv(). It's way better than the
| crusty old lynx and links on sites that need JS.
|
| It's solid. Definitely worth a check
| Philpax wrote:
| Oh, huh, being able to convert arbitrary websites that may use
| JS for rendering to Markdown could be very handy indeed. Thanks
| for the tip!
| daddykotex wrote:
| Thanks for the tip, that's very cool. I did not know about
| `markitdown` and `streamdown`.
| lewdwig wrote:
| A language which is not 1.0, and has repeatedly changed its IO
| implementation in a non-backwards-compatible way is certainly a
| courageous choice for production code.
| steeve wrote:
| the upside is absolutely worth it
| Philpax wrote:
| It's certainly not a choice I would have made, but there's
| sufficient precedent for it now (TigerBeetle, Ghostty, etc)
| that I can understand it.
| hu3 wrote:
| also Bun
| blue_pants wrote:
| also Roc
| Iridescent_ wrote:
| This one is far from prod-ready however
| ivanjermakov wrote:
| In my experience, migrating small-scale projects takes from
| minutes to single digit hours.
|
| Standard library is changing. The core language semantics - not
| so much. You can update from std.ArrayListUnmanaged to
| std.array_list.Aligned with to greps.
| bluecalm wrote:
| Right? People must really like the design choices in Zig to do
| that instead of choosing another language. It's very
| interesting just because of that.
| dnautics wrote:
| So, I'm noodling around with writing a borrow checker for zig,
| and you don't get to appreciate this working with zig on a day
| to day level, but the internals of how the zig compiler works
| are AMAZING. Also, the io refactor will (I think) let me
| implement aliasing checking (alias xor mutable).
| portly wrote:
| Love to see Zig winning!
| steeve wrote:
| This looks incredible, congratulations!
| fbouvier wrote:
| Thanks Steeve!
| tonyhart7 wrote:
| finally, rewrite in zig movement is coming
| deepriverfish wrote:
| it's so tiring that every time there's a post about something
| being implemented in Zig or C or C++, the Rust brigade shows up
| trying to pick up a fight.
| hobofan wrote:
| Maybe just a reflex by people that had to hear a decade of "why
| not C++" whenever it was mentioned that Rust is being used?
| esafak wrote:
| I don't know, man. At this point I'm liable to ask "Why _are_
| you using C++? " if you start a new project. Let _them_
| defend their language!
| pjmlp wrote:
| As part of the "all software should be liable brigade", it is a
| matter of misplaced goals after the cybersecurity agencies
| started looking into the matter.
| Klonoar wrote:
| It's a site where programming nerds congregate to waste time
| arguing with each other. Where do you think you are?
|
| This same pattern used to play out with Ruby, Lisp, and other
| languages in different eras of this site. It will probably
| never stop and calling it out seems to just fan the flames more
| than anything else.
| neoden wrote:
| I hate to say it, but time is quickly running out for Zig(( AI
| might never pick it up properly and without that it will never go
| out of its niche
| shepherdjerred wrote:
| Are you implying that programming languages are now going to be
| "frozen" because of AI?
|
| I can understand the source of concern but I wouldn't expect
| innovation to stop. The world isn't going to pause because of a
| knowledge cutoff date.
| neoden wrote:
| Innovation doesn't go for the sake of innovation itself.
| Innovation should serve a purpose. And the purpose of having
| programming languages is to overcome the limitations of human
| mind, of our attention span, of our ability to manipulate
| concepts expressed in abstractions and syntax. We don't know
| how long we'll need this.
|
| I really like Zig, I wish it appeared several years earlier.
| But rewriting everything in Zig might just not have practical
| sense soon.
| shepherdjerred wrote:
| I agree that programming languages will no longer need to
| be as accessible to humans.
|
| However there is still a strong argument to be made for
| protections/safety that languages can provide.
|
| e.g. would you expect a model (assuming it had the same
| expertise in each language) to make more mistakes in ASM,
| C, Zig, or Rust?
|
| I imagine most would agree that ASM/C would be likely to
| have the most mistakes simply because fewer constraints are
| enforced as you go closer to the metal.
|
| So, while we might not care about how easy it is for a
| human to read/write, there will still be a purpose for
| innovation in programming languages. But those innovations,
| IMO, will be more focused on how to make languages easier
| for AI.
| neoden wrote:
| > would you expect a model (assuming it had the same
| expertise in each language) to make more mistakes in ASM,
| C, Zig, or Rust?
|
| "assuming it had the same expertise in each language" is
| the most important part here, because the expertise of AI
| with these languages is very different. And, honestly, I
| bet on C here because its code base is the largest, the
| language itself is the easiest to reason about and we
| have a lot of excellent tooling that helps mitigate where
| it falls short.
|
| > I imagine most would agree that ASM/C would be likely
| to have the most mistakes simply because fewer
| constraints are enforced as you go closer to the metal.
|
| We need these constraints because we can't reliably track
| all the necessary details. But AI might be much more
| capable (read -- scalable) in that, so all the complexity
| that we need to accumulate in a programming language it
| might just know out of the way it's built.
| shepherdjerred wrote:
| I'm going to assume you're open to an honest discussion
| here.
|
| > "assuming it had the same expertise in each language"
| is the most important part here, because the expertise of
| AI with these languages is very different.
|
| You are correct, but I am trying to illustrate that
| assuming some ideal system with equal expertise, the
| languages with more safety would win out in
| productivity/bugs over those with less safety.
|
| As in to say that it could be worth investing further in
| safer programming languages because AI would benefit.
|
| > We need these constraints because we can't reliably
| track all the necessary details.
|
| AI cannot reliably track the details either (yet, though
| I am sure it can be done). Even if it could, it would be
| a complete waste of resources (tokens).
|
| Why have an AI determine the type of a variable when it
| could be done in a deterministic manner with a compiler
| or linter?
|
| To me these arguments closely mirror/follow arguments of
| static/dynamically typed languages for human programmers.
| Static type systems eliminate certain kinds of errors and
| can produce higher quality programs. AI systems will
| benefit in the same way if not more by getting instant
| feedback on the validity of their program.
| hu3 wrote:
| In my experience LLMs are really good at following code
| examples and constraints (tests).
|
| So even if they don't get to train much on some technology, all
| you need is some guidance docs in AGENTS.md
|
| There's a plus in being fresh too: LLMs aren't going to be
| heavily trained on outdated tutorials and docs. Like React for
| example.
| MrBuddyCasino wrote:
| _Because We 're Not Smart Enough for C++ or Rust_
|
| Very refreshing. Most engineers would rather saw their leg off.
| Copenjin wrote:
| Any older project similar to this? Headless browser with js
| support I mean, I want to check various implementations of this
| idea.
| pulkas wrote:
| zigdom all-diy
___________________________________________________________________
(page generated 2026-01-12 23:01 UTC)