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

101–110 of 144 posts

Re: Lightpanda migrate DOM implementation to Zig

#101

Post by shepherdjerred »

neoden wrote: post #99
shepherdjerred wrote: post #77

Earlier quoted context omitted.

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.

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

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.

Re: Lightpanda migrate DOM implementation to Zig

#102

Post by pron »

pjmlp wrote: post #72
pron wrote: post #54

Earlier quoted context omitted.

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

Re: Lightpanda migrate DOM implementation to Zig

#103

Post by dwattttt »

bluecalm wrote: post #95
pjmlp wrote: post #72

Earlier quoted context omitted.

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

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.

Re: Lightpanda migrate DOM implementation to Zig

#104

Post by IshKebab »

kryps wrote: post #35
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).

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.

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.

Re: Lightpanda migrate DOM implementation to Zig

#105

Post by dwattttt »

dnautics wrote: post #100
pjmlp wrote: post #4

Earlier quoted context omitted.

And use-after-free, when that arena's memory goes away.

Yeah that's certainly possible but leaking a pointer like this seems like it would be really easy to spot?

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.

Re: Lightpanda migrate DOM implementation to Zig

#106

Post by pyrolistical »

defen wrote: post #83
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.

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?

Both c# and swift have first party c abi integration

Re: Lightpanda migrate DOM implementation to Zig

#107

Post by pron »

7bit wrote: post #85
pron wrote: post #34

Earlier quoted context omitted.

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…

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.

Then we're in agreement. Both languages give you something that may be important, but it has a price.

Re: Lightpanda migrate DOM implementation to Zig

#108

Post by krichprollsch »

warpech wrote: post #22
nicoburns wrote: post #7

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

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

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.

Re: Lightpanda migrate DOM implementation to Zig

#109

Post by tcfhgj »

pron wrote: post #34
7bit wrote: post #24

Earlier quoted context omitted.

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

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…

Imo "safety" in safe Rust is higher than it is in more popular languages.

Data races, type state pattern, lack of nulls, ...

Re: Lightpanda migrate DOM implementation to Zig

#110

Post by pron »

tcfhgj wrote: post #109
pron wrote: post #34

Earlier quoted context omitted.

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…

Imo "safety" in safe Rust is higher than it is in more popular languages. Data races, type state pattern, lack of nulls, ...

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.

Post reply on HN