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

141–144 of 144 posts

Re: Lightpanda migrate DOM implementation to Zig

#141

Post by bnolsen »

IshKebab wrote: post #78
mijoharas wrote: post #15

Earlier quoted context omitted.

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

Having worked with c++ strings and also string views I find zigs simple fat pointer to be fairly direct and straightforward, and a bit refreshing. Ownership is being coupled in with the type..

Re: Lightpanda migrate DOM implementation to Zig

#142

Post by jamiejquinn »

Zambyte wrote: post #136
jamiejquinn wrote: post #98

Earlier quoted context omitted.

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

Delightful, I'll play about with both, thanks!

Re: Lightpanda migrate DOM implementation to Zig

#143

Post by Ygg2 »

pron wrote: post #135
Ygg2 wrote: post #134

Earlier quoted context omitted.

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

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

Most? You still haven't proved that. So most Rust programs mostly use GC, yet it's not a GC language; those are some very mind-contorting definitions.

> The laws of physics absolutely do not predict that the relative cost of CPU to RAM will decrease substantially.

Laws of physics do absolutely tell you that more computation means more heat. Also trying to approach the size of atoms is another no-go. That's why current chip densities have stalled but have been kept on life support via chip stacking and gate redesigns. The 2nm process is mostly a marketing term (https://en.wikipedia.org/wiki/2_nm_process) the actual gate is around 45x20nm.

Not to mention that when working with the way atoms work (i.e. their random nature) and small scales, small irregularities mean low yields.

They put a soft cap on any exponential curve. And hard cap by placing a literal singularity.

> I don't know how reasonable it is to think that.

Why not? With modern collections (std::vector, std::span, and std::string) and modern pointers (std::unique_ptr, std::shared_ptr) you get decent memory safety.

> Because it's both explicit and simple.

Being a simple language doesn't guarantee lack of complexity in implementation (see Brainfuck). The question is how much language complexity buys implementation simplicity. C++ of course has neither because it started with a backwards compatibility goal (it did get abandoned at some point).

By Zig's explicitness, you mean everything is public? I've seen that stuff backfire spectacularly, because you don't get any encapsulation, which means maximum coupling.

Re: Lightpanda migrate DOM implementation to Zig

#144

Post by pron »

Ygg2 wrote: post #143
pron wrote: post #135

Earlier quoted context omitted.

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

> No. Most memory management in Rust is not through it's GC, even though most Rust programs do use the GC to some extent. Most? You still haven't proved that. So most Rust programs mostly use GC, yet it's not a GC language; those are some very mind-contorting definitions. > The laws of physics absolutely do not predict that the relative cost of CPU to RAM will decrease substantially. Laws of physics do absolutely tel…

> So most Rust programs mostly use GC, yet it's not a GC language; those are some very mind-contorting definitions.

I don't think these definitions are very meaningful. In memory management literature, any technique that reclaims heap memory after a heap object is not reachable is called "garbage collection". Call it a "GC language" or not, it collects heap memory using techniques in the GC literature after objects become unreachable using reference counting with a special construct for the single reference case.

There isn't too much that you can learn just by saying "GC", because the memory/CPU tradeoffs can be more different between two GCs than between one GC and some memory management style in C. So the debate on terminology is less substantial and more about how different people colloquially refer to things with different terms. But Rc/Arc are a very common, established, and traditional GC implementation (and a simple one if you ignore the large and rather elaborate implementation of malloc/free we have these days in the runtime, which is necessary for decent performance on multicore machines).

> They put a soft cap on any exponential curve. And hard cap by placing a literal singularity.

How does any of this predict that processing will become cheaper relative to memory? Note that the trend over the past 4 decades has been the opposite.

> Being a simple language doesn't guarantee lack of complexity in implementation (see Brainfuck).

I didn't think that every simple language is easy to understand, but I find Zig simple and easy to understand.

> By Zig's explicitness, you mean everything is public?

What I meant was that there are no calls/operations performed in a subroutine that aren't visible in the text of the subroutine. This is very important to me in low-level programming. Of course, different people from different domains may have different preferences. Much of my low-level programming was in safety-critical hard realtime, and Zig just appeals more to how I like to think about control over the hardware and about correctness. It's not universal, and I'm sure Rust appeals more to other low-level programmers.

Post reply on HN