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

71–80 of 144 posts

Re: Lightpanda migrate DOM implementation to Zig

#71

Post by pron »

Ygg2 wrote: post #63
pron wrote: post #48

Earlier quoted context omitted.

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

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

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

Re: Lightpanda migrate DOM implementation to Zig

#72

Post by pjmlp »

pron wrote: post #54
pjmlp wrote: post #43

Earlier quoted context omitted.

It has for Amazon, Adobe, Microsoft, Google and the Linux kernel. It remains to be seen which big name will make Zig unavoidable.

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

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.

Re: Lightpanda migrate DOM implementation to Zig

#73

Post by pjmlp »

pron wrote: post #51
pjmlp wrote: post #37

Earlier quoted context omitted.

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.

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), b…

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

Re: Lightpanda migrate DOM implementation to Zig

#74

Post by Ygg2 »

pron wrote: post #71
Ygg2 wrote: post #63

Earlier quoted context omitted.

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

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

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

Re: Lightpanda migrate DOM implementation to Zig

#75

Post by pjmlp »

deepriverfish wrote: post #60

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.

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.

Re: Lightpanda migrate DOM implementation to Zig

#76

Post by pron »

Ygg2 wrote: post #74
pron wrote: post #71

Earlier quoted context omitted.

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

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

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

Re: Lightpanda migrate DOM implementation to Zig

#77

Post by shepherdjerred »

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

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.

Re: Lightpanda migrate DOM implementation to Zig

#78

Post by IshKebab »

mijoharas wrote: post #15
IshKebab wrote: post #10

Earlier quoted context omitted.

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

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…

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).
Post reply on HN