Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lightpanda migrate DOM implementation to Zig

lightpanda.io

Post reply on HN
Print view View original

131–140 of 144 posts

Re: Lightpanda migrate DOM implementation to Zig

#131

Post by super_flanker »

bluecalm wrote: post #124
dwattttt wrote: post #103

Earlier quoted context omitted.

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 politica…

I was referring to mandate to use it at big companies. This is a political achievement. Teams/contributors making their own choice and then shipping good software counts as technical one but that wasn't the main point of the post I replied to.

> I was referring to mandate to use it at big companies.

I've worked in almost all of big tech, and these companies don't create mandate just because "Trust me bro" or to gain some "political achievements". Their are teams who champion new technology/languages, they create proof of what new technology will bring to the table which cannot be filled with existing ones. I left amazon 7 years ago so don't know about recent development. However at Meta/Google teams are encouraged to choose from the mandate languages and if they can't they need to request for exemption and justify the exception.

Re: Lightpanda migrate DOM implementation to Zig

#132

Post by Ygg2 »

pron wrote: post #125
Ygg2 wrote: post #122

Earlier quoted context omitted.

> Except I never called it "a GC language" (whatever that means). I said, and I quote, "Rust does have a GC". Ok, semantics aside, my point still stands. C also has a GC. See Boehm GC. And before you complain RC is part of std I will point that std is optional and is on track to become a freestanding library. > Can you accept that your prerequisites and compromises might not be universal Not the way hardware is movin…

> C also has a GC. See Boehm GC. And before you complain RC is part of std I will point that std is optional and is on track to become a freestanding library. Come on. The majority of Rust programs use the GC. I don't understand why it's important to you to debate this obvious point. Rust has a GC and most Rust programs use it (albeit to a much lesser extent than Java/Python/Go etc.). I don't understand why it's a bi…

> Come on. The majority of Rust programs use the GC.

This part is false. You make a ridiculous statement and expect everyone to just nod along.

I could see this being true iff you say all Rust UI programs use "RC".

> This is simply not true. There are and have always been types of software that, for whatever reason, need low-level control over memory usage, but the overall number of such cases has been steadily decreasing over the past decades

Without ever increasing memory/CPU, you're going to have to squeeze more performance out of the stone (more or less unchanging memory/CPUs).

GC will be a mostly unacceptable overhead in numerous instances. I'm not saying it will be fully gone, but I don't think the current crop of C-likes is accidental either.

> I understand that's something you believe, but it's not supported empirically

It's supported by Google's usage of Rust.

https://security.googleblog.com/2025/11/rust-in-android-move...

> Stable and high-quality changes differentiate Rust. DORA uses rollback rate for evaluating change stability. Rust's rollback rate is very low and continues to decrease, even as its adoption in Android surpasses C++.

So for similar patches, you see fewer errors in new code. And the overall error rate still favors Rust.

Re: Lightpanda migrate DOM implementation to Zig

#133

Post by pron »

Ygg2 wrote: post #132
pron wrote: post #125

Earlier quoted context omitted.

> C also has a GC. See Boehm GC. And before you complain RC is part of std I will point that std is optional and is on track to become a freestanding library. Come on. The majority of Rust programs use the GC. I don't understand why it's important to you to debate this obvious point. Rust has a GC and most Rust programs use it (albeit to a much lesser extent than Java/Python/Go etc.). I don't understand why it's a bi…

> Come on. The majority of Rust programs use the GC. This part is false. You make a ridiculous statement and expect everyone to just nod along. I could see this being true iff you say all Rust UI programs use "RC". > This is simply not true. There are and have always been types of software that, for whatever reason, need low-level control over memory usage, but the overall number of such cases has been steadily decre…

> Without ever increasing memory/CPU, you're going to have to squeeze more performance out of the stone (more or less unchanging memory/CPUs).

The memory overhead of a moving collector is related only to the allocation rate. If the memory/CPU is sufficient to cover that overhead, which, in turn help save more costly CPU, it doesn't matter if the relative cost reduced (also, it's not even reduced; you're simply speculating that one day it could be).

> I'm not saying it will be fully gone

That's a strange expression given that the percentage of programs written in languages that rely primarily on a GC for memory management has been rising steadily for about 30 years with no reversal in trend. This is like saying that more people will find the cost of typing a text message unacceptable so we'll see a rise in voicemail messages, but of course text messaging will not be fully gone.

Even embedded software is increasingly written in languages that rely heavily on GC. Now, I don't know the future market forces, and maybe we won't be using any programming languages at all but LLMs will be outputting machine code directly, but I find it strange to predict with such certainty that the trend we've been seeing for so long will reverse in such full force. But ok, who knows. I can't prove that the future you're predicting is not possible.

> It's supported by Google's usage of Rust.

There's nothing related here. We were talking about how Zig's design could assist in code reviews and testing, and therefore in the total reduction of bugs, and you said that maybe a complex language like Rust, with lots of implicitness but also temporal memory safety could perhaps have a positive effect on other bugs, too, in comparison. What you linked to is something about Rust vs C and C++. Zig is at least as different from either one as it is from Rust.

> And the overall error rate still favors Rust.

Compared to C++. What does it have to do with anything we were talking about?

Re: Lightpanda migrate DOM implementation to Zig

#134

Post by Ygg2 »

pron wrote: post #133
Ygg2 wrote: post #132

Earlier quoted context omitted.

> Come on. The majority of Rust programs use the GC. This part is false. You make a ridiculous statement and expect everyone to just nod along. I could see this being true iff you say all Rust UI programs use "RC". > This is simply not true. There are and have always been types of software that, for whatever reason, need low-level control over memory usage, but the overall number of such cases has been steadily decre…

> Without ever increasing memory/CPU, you're going to have to squeeze more performance out of the stone (more or less unchanging memory/CPUs). The memory overhead of a moving collector is related only to the allocation rate. If the memory/CPU is sufficient to cover that overhead, which, in turn help save more costly CPU, it doesn't matter if the relative cost reduced (also, it's not even reduced; you're simply specul…

> That's a strange expression given that the percentage of programs written in languages that rely primarily on a GC for memory management has been rising steadily for about 30 years

I wish I knew what you mean by programs relying primarily on GC. Does that include Rust?

Regardless, but extrapolating current PL trends so far is a fools errand. I'm not looking at current social/market trends but limits of physics and hardware.

> There's nothing related here. We were talking about how Zig's design could assist in code reviews and testing

No, let me remind you:

> > [snip] Rust defends you from common mistakes, but overall for similar codebases you see fewer bugs.

> I understand that's something you believe, but it's not supported empirically we were talking how not having to worry about UB allows for easier defect catching.

> Compared to C++.

Overall, I think using C++ with all of its modern features should be in the ballpark of safe/fast as Zig, with Zig having a better compile time. Even if it isn't a 1-to-1 comparison with Zig, we have other examples like Bun vs Deno, where Bun incurs more segfaults (per issue).

Also don't see how much of Zig design could really assist code reviews and testing.

Re: Lightpanda migrate DOM implementation to Zig

#135

Post by pron »

Ygg2 wrote: post #134
pron wrote: post #133

Earlier quoted context omitted.

> Without ever increasing memory/CPU, you're going to have to squeeze more performance out of the stone (more or less unchanging memory/CPUs). The memory overhead of a moving collector is related only to the allocation rate. If the memory/CPU is sufficient to cover that overhead, which, in turn help save more costly CPU, it doesn't matter if the relative cost reduced (also, it's not even reduced; you're simply specul…

> That's a strange expression given that the percentage of programs written in languages that rely primarily on a GC for memory management has been rising steadily for about 30 years I wish I knew what you mean by programs relying primarily on GC. Does that include Rust? Regardless, but extrapolating current PL trends so far is a fools errand. I'm not looking at current social/market trends but limits of physics and…

> Does that include Rust?

No. Most memory management in Rust is not through it's GC, even though most Rust programs do use the GC to some extent.

> I'm not looking at current social/market trends but limits of physics and hardware.

The laws of physics absolutely do not predict that the relative cost of CPU to RAM will decrease substantially. Unforeseen economic events may always happen, but they are unforeseen. It's always possible that current trends would reverse, but that's a different matter from assuming they are likely to reverse.

> Overall, I think using C++ with all of its modern features should be in the ballpark of safe/fast as Zig, with Zig having a better compile time.

I don't know how reasonable it is to think that. If Rust's value comes from eliminating spatial and temporal memory safety issues, surely there's value in eliminating the more dangerous of the two, which Zig does as well as Rust (but C++ doesn't).

But even if you think that's reasonable for some reason, I think it's at least as reasonable to think the opposite, given that in almost 30 years of programming in C++, by far my biggest issue with the language has been its complexity and implicitness, and Zig fixes both. Given how radically different Zig is from C++, my preferenece for Zig stems precisely from it solving what is, to me, the biggest issue with C++.

> Also don't see how much of Zig design could really assist code reviews and testing.

Because it's both explicit and simple. There are no hidden operations performed by a routine that do not appear in that routine's code. In C++ (or Rust), to know whether there's some hidden call to a destructor/trait, you have to examine all the types involved (to make matters worse, some of them may be inferred).

Re: Lightpanda migrate DOM implementation to Zig

#136

Post by Zambyte »

jamiejquinn wrote: post #98
IshKebab wrote: post #78

Earlier quoted context omitted.

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).

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...

As of 0.15.X, you can build strings using a std.Io.Writer. You can either:

- use std.Io.Writer.fixed to use a slice for the memory, and use .buffered() when you're done to get the subslice of the buffer that contains your string

or

- Create an instance of std.Io.Writer.Allocating with an allocator, and use .toOwnedSlice() when you're done to get your allocated string.

In both cases you just use regular print functions to build your string.

Depending on your needs, it may also be good to use a fixed writer with a dynamically allocated slice, where the size of the allocation is computed using std.fmt.count(). This can be better than using std.Io.Writer.Allocating because you can avoid doing multiple allocations.

Re: Lightpanda migrate DOM implementation to Zig

#137

Post by drannex »

drnick1 wrote: post #69
anal_reactor wrote: post #36

Earlier quoted context omitted.

The problem is that the number of browser engines is n=2.

Interestingly, Ladybird, which aims at being the n = 3, is also written in C++.

Ladybird is in the process of switching over to Swift, and has been for a little over a year now.

Not linking to the pedophilic nazi-site, and as Nitter is dead-ish, here is the full-text announcement archived on tildes: https://tildes.net/~comp/1j7m/ladybird_chooses_swift_as_its_...

Re: Lightpanda migrate DOM implementation to Zig

#138

Post by rtfeldman »

neoden wrote: post #61

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

Claude Opus 4.5 is completely fluent in Zig.

I use it constantly, and it never occurred to me that someone might think there was a problem to be solved there.

Re: Lightpanda migrate DOM implementation to Zig

#139

Post by surajrmal »

paavohtl wrote: post #57
surajrmal wrote: post #50

Earlier quoted context omitted.

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++.

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...

Sure and android is a small part of Google. Everyone in ads, search, cloud are still predominantly c++ (or something higher level like Java). Rust is gaining momentum but overall it's still small.

Re: Lightpanda migrate DOM implementation to Zig

#140

Post by Jweb_Guru »

dnautics wrote: post #93
Jweb_Guru wrote: post #58

Earlier quoted context omitted.

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.

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.

Believe it or not, using arenas does not provide free memory safety. You need to statically bound allocations to make sure they don't escape the arena (which is exactly how arenas work in Rust, but not Zig). There are also quite a lot of ways of generating memory unsafe code that aren't just use after free or array-out-of-bounds in a language like Zig, especially in the context of stuff like DOM nodes where one frequently needs to swap out pointers between elements of one type and a different type.
Post reply on HN