[HN Gopher] Why we built Lightpanda in Zig
___________________________________________________________________
Why we built Lightpanda in Zig
Author : ashvardanian
Score : 134 points
Date : 2025-12-05 18:29 UTC (4 hours ago)
(HTM) web link (lightpanda.io)
(TXT) w3m dump (lightpanda.io)
| websiteapi wrote:
| has there ever been a project that became popular and/or
| successful because of its programming language? does it really
| matter to the end user what language it's in if it works well?
| rudedogg wrote:
| The language tends to affect everything, but to give a quick
| Developer example there's Zed. Developers use it because it's
| fast. Same with Sublime Text.
|
| Your criticism makes more sense with products targeting non-
| technical users though. But IMO tech choices have cascading
| effects. I won't buy a vehicle if the infotainment software
| sucks, and that's the 2nd largest purchase I'll ever make.
| websiteapi wrote:
| zed is a great example. most people use vscode, that is
| javascript. which ai code editors are built from scratch that
| aren't forked vscode?
| rudedogg wrote:
| Just Zed (if AI features are a requirement) as far as I
| know.
|
| But to elaborate, they've found a niche simply by using
| Rust and rendering the GUI in a performant way on the GPU.
| I'm not saying performance is the only thing, but for a
| chunk of people it is something they care about.
| data-ottawa wrote:
| Good performance is a strong proxy for making other good
| software decisions. You generally don't get good
| performance if you haven't thought things through or
| planned for features in the long term.
| sroussey wrote:
| I hate all infotainment systems, so I'm still on a car from
| 22 years ago -- with no screen and ratting me out on how I
| drive to unknown entities.
|
| If I had the optional GPS screen from 22yr ago, I think I
| would have ripped it out and replaced it a bunch of times or
| just bought a new car.
|
| I'm curious to try the new iDrive 10. We will see...
| CooCooCaCha wrote:
| This post is aimed at developers and hackernews is a
| technically focused forum. So I care as a developer.
|
| If language doesn't matter then why not go build something in
| fortran or brainfuck?
| grayhatter wrote:
| > If language doesn't matter then why not go build something
| in fortran or brainfuck?
|
| Because if you're getting lunch, and someone suggests
| Burgers, Sushi, or Casu martzu. Only two are actually
| reasonable.
|
| Yes, yes, if I'm allergic to shellfish, I might want to make
| sure I have an EpiPen before getting sushi. But that doesn't
| mean it's a meaningful problem.
| pklausler wrote:
| I really don't understand the disdain for Fortran on HN.
| While it's not the most well-defined or portable programming
| language in the world, it does its job pretty well for those
| who need it, and has more actively maintained implementations
| than any language I can think of apart from C.
| aeve890 wrote:
| Now that you mention it I think this is a new trend. I pretty
| sure I've seen more "written in Rust/Go/Zig" than any other
| language out there. I've never seen a post like "new cli,
| written in C++" for example. I don't know if it's just some
| kind of tribalism or a way to attract talent to your project.
|
| I think end users don't give a shit about the tech stack of a
| software. Why would they?
| femiagbabiaka wrote:
| I think I'll take the side of no (as long as it's
| fast/safe/good) and also I never find the reasoning in these
| language comparisons to be that compelling anyways. A "why we
| like $FOO" is better than "why $FOO works better/is better for
| us than $BAR", since the latter is almost always going to be
| incomplete.
| mitchellh wrote:
| There are second order effects. You definitely attract
| different types of talent depending on the technology stack of
| choice. And building the right group of talent around an early
| stage product/company is an extremely impactful thing on the
| product. And blogs are an impactful talent marketing source.
|
| This doesn't guarantee any sort of commercial success because
| there are so many follow on things that are important
| (product/market fit, sales, customer success, etc.) but it's
| pretty rough to succeed in the follow ons when the product
| itself is shit.
|
| For first order effects, if a product's target market is
| developer oriented, then marketing to things developers care
| about such as a programming language will help initial
| adoption. It can also help the tool get talked about more
| organically via user blogs, social media, word of mouth, etc.
|
| Basically, yeah, it matters, but as a cog in a big machine like
| all things.
| gorjusborg wrote:
| There's a big part of me that agrees with your implied
| conclusion, that it shouldn't matter.
|
| On the other hand, I've found that core decisions like language
| ecosystem choice can be a good leading indicator of other
| seemingly unrelated decisions.
|
| When I see someone choose a tool that I think is extremely well
| suited for a purpose, it makes me curious to see what else we
| agree on.
|
| The Oven team, the ones who created the Bun runtime, is a good
| example for me. I think Zig is probably the best compromise out
| there right now, for my sensibilities. The Oven folks, who
| chose to use Zig to implement Bun, _also_ made a lot of product
| decisions I really agree with.
| karmakaze wrote:
| This is one of my assessments/red-flags when interviewing
| with a company. Their tech stack/choices is a reflection of
| their engineering culture. If they chose Zig or Rust, I'd
| want to hear why that was a better choice than using a gc'd
| language.
| Milpotel wrote:
| > If they chose Zig or Rust, I'd want to hear why that was
| a better choice than using a gc'd language.
|
| Come on, they advertise with benchmarks hence it's quite
| obvious why they didn't chose a gc'd language.
| cgh wrote:
| https://paulgraham.com/avg.html
|
| Paul Graham is one of the founders of Y Combinator, the company
| that hosts Hacker News.
| karmakaze wrote:
| Yes. I don't think Linux would have succeeded if written in a
| language other than C. Today is a different story.
|
| Yes it matters to me as an end user if my web browser is more
| or less likely to have vulnerabilities in it. Choice of
| programming language has an impact on that. It doesn't have to
| be Rust, I'd use a browser written in Pony.
|
| If I were making something that had to be low-level and not
| have security bugs, my statement would be:
|
| > I'm not smart enough to build a big multi-threaded project in
| a manual memory-managed language that doesn't have
| vulnerabilities. I want help from the language & compiler.
|
| The size and longevity of the team matters a lot too. The
| larger it gets the more problematic it is to keep the bugs out.
| Milpotel wrote:
| The opposite is true: there are a lot of projects that failed
| because of the chosen language.
| OnionBlender wrote:
| What are some famous examples?
| 9rx wrote:
| Most seem to agree that NeXTSTEP/macOS/iOS wouldn't have
| succeeded without Objective-C. So much of the functionality
| that made it stand out was predicated on Objective-C's somewhat
| unique programming model.
|
| Of course, it's all just 1s and 0s at the end of the day. You
| can ultimately accomplish the same in any language. But the
| design of the language does shape the way developers end up
| thinking about the problems. If NeXT had used, say, C++
| instead, it is unlikely that the people involved would have
| ever come to recognize the same possibilities.
| ok123456 wrote:
| Ruby on Rails.
| DanielHB wrote:
| There have been some large scale companies that went under
| because of platforms chosen to develop their products in. First
| that comes to mind is MySpace with Dreamweaver.
| lvl155 wrote:
| This is actually a great summary of Zig. I am with the author: I
| am too old and stupid to use Rust properly. Whenever I watch
| someone like Gjengset write Rust, I realize I am doing it wrong.
| observationist wrote:
| I'd like to see a setup with Lightpanda feeding a local/private
| AI, with content rendered post-curation. You could filter out all
| the garbage at the intake, instead of doing all the plug-ins,
| extensions, add-ons, DNS and whackamole arms race.
|
| AI researchers need to hurry up and invent the next big paradigm
| shift so AI on your phone is as good as SoTA bots, so we can stay
| ahead of the enshittification curve.
|
| Awesome software - I've been meaning to build a crawler and this
| does the trick.
| francisbouvier wrote:
| Author and founder here. Thank you!
| mustpax wrote:
| I feel like I'm missing something. How do people justify the
| security implications of manual memory management when building a
| publicly accessible web service with Zig?
| ridiculous_leke wrote:
| In practice aren't such services behind a reverse proxy/WAF?
| The other day I found an endpoint in the wild outputting a DB
| table. I tried fuzzing it to gather more evidence of a SQL
| injection vuln but my attempts were flagged by AWS WAF.
| Svoka wrote:
| No, you don't.
|
| Lets be honest Zig is a shiny new shit for people who doesn't
| want to learn and want everything to be familiar but new.
|
| Criticism of it is not allowed and would be downvoted by
| bandwagon fanboys.
| gorjusborg wrote:
| Years ago, when I initially picked up Rust, I loved it. It does a
| lot of things right. At the same time, though, I knew there was a
| possibility of it going wrong in two opposite directions:
|
| 1. Developers balked at being required to take on the cognitive
| load required to allow GC-less memory management
|
| 2. Developers wore their ability to take on that cognitive load
| as a badge of honor, despite it not being in their best interest
|
| I eventually came to the decision to stop developing in Rust,
| despite its popularity. It _is_ really cool that its creators
| pulled it off. It was quite an achievement, given how different
| it was when it came out. I think that if I had to implement a
| critical library I would consider using Rust for it, but as a
| general programming language I want something that allows me to
| focus my mental facilities on the complexities of the actual
| problem domain, and I felt that it was too often too difficult to
| do that with Rust.
| azaras wrote:
| What are you developing in?
| gorjusborg wrote:
| Depends on the problem at hand.
|
| Zig where I used to use C/Rust (but admittedly I spent the
| least time here).
|
| Go where I used to use Java.
|
| Bun/Node for typescript/javascript, where each is
| appropriate, but I favor Bun for standalone application
| programming and local scripting.
| littlestymaar wrote:
| > Zig where I used to use C/Rust (but admittedly I spent
| the least time here).
|
| I really don't understand how that fit with the "I want
| something that allows me to focus my mental facilities on
| the complexities of the actual problem domain".
|
| For low-level stuff, Rust allows to offload the cognitive
| load of maintaining the ownership requirements to the
| machine. On the opposite, Zig is exactly like C as it
| forces you to think about it all the time or you just shoot
| yourself in the foot at the first opportunity...
|
| For stuff that can be done with managed languages, then
| absolutely, the GC allows to completely ignore that aspect,
| at the cost of some performance you don't always care about
| because how fast the modern hardware is.
| zozbot234 wrote:
| Rust does not require GC-less memory management. It supports
| reference counting out of the box, and reference counting is a
| kind of GC. It's not inherently any harder to use than Swift
| (another memory-safe language) which plenty of average
| developers use to code for Apple platforms.
| K0nserv wrote:
| It's not quite a fully formed argument, but I'm coming to the
| view that Rust mostly requires less cognitive load than other
| languages. I'm coming at this from the perspective of
| "cognitive load" meaning, roughly "the measure of the number of
| things you need to keep in working memory". Rust is no doubt
| difficult to learn, there are many concepts and a lot of
| syntax, but when you grasp it cognitive load is actually lower.
| Rust encodes so much more about the program in text than peer
| languages so there are fewer things to keep in your head. One
| good example of this is pointer lifetimes in Zig and C which
| you have to keep in your head, whereas in Rust you don't.
|
| My own appreciation for Rust is rooted in humility. I know I'm
| an overgrown monkey prone to all kinds of mistakes. I
| appreciate Rust for helping me avoid that side of me
| zozbot234 wrote:
| > Rust is no doubt difficult to learn, there are many
| concepts and a lot of syntax
|
| People love to say this, but C++ is routinely taught as a
| _first_ programming language to novice programmers (this used
| to be even more clearly the case before Java and Python
| largely took on that role) and Rust is undoubtedly simpler
| than C++.
| tehjoker wrote:
| That's true, but as someone that doesn't do much rust, C++
| is a language where there are less restrictions and you can
| use little parts of the language, whereas Rust is supposed
| to be a simpler language overall, but with more concepts to
| learn up-front to prevent things that happen where there
| are no rules....
| zozbot234 wrote:
| You can use "little parts of the language" in Rust too;
| the cleanest and most foundational part of Rust is pure
| value-based programming with no mutability or referencing
| at all, much like in a functional language (but with
| affine types!). Everything else is built quite cleanly on
| top of that foundation, even interior mutability which is
| often considered incredibly obscure. (It's called
| "interior" because the outer cell's identity doesn't
| really mutate, even though its _content_ obviously does.)
| bsder wrote:
| Precisely.
|
| You can _subset_ C++ and still knock out a program.
|
| You cannot subset Rust and still create a program.
| vablings wrote:
| I gave up on a C++ after trying to learn on and off for
| years. LNK1009 still haunts me in my sleep. I am now an
| avid self-taught rust programmer and I feel like I have the
| power to create almost anything I can imagine using rust.
| This is great for hobby people
| com2kid wrote:
| The mentality around lifetimes is different in Zig if you are
| using it for the correct types of problems.
|
| For example, a command line utility. In a CLI tool you
| typically _don 't free memory_. You just allocate and exit
| and let the OS clean up memory.
|
| Historically compilers were all like this, they didn't free
| memory, they just compiled a single file and then exited!
| This ended up being a problem when compilers moved more into
| a service model (constant compilation in the background,
| needing to do whole program optimization, loading into memory
| and being called on demand to compile snippets, etc), but for
| certain problem classes, not worrying about memory safety is
| just fine.
|
| Zig makes it easy to create an allocator, use it, then just
| free up all the memory in that region.
|
| Right tool for the job and all that.
| dnautics wrote:
| I'm not convinced that you can't borrow check in zig...
| (disclaimer, i'm working on compile time memory safety for
| zig)
| whytevuhuni wrote:
| I've been having an absolutely great time with Rust's
| bumpalo crate, which works very similarly. The lifetime
| protection still works great, and it's actually a lot more
| permissive than normal Rust, since it's the same lifetime
| everywhere.
|
| The sad exception is obviously that Rust's std collections
| are not built on top of it, and neither is almost anything
| else.
|
| But nevertheless, I think this means it's not a Zig vs Rust
| thing, it's a Zig stdlib vs Rust stdlib thing, and Rust's
| stdlib can be replaced via #[no_std]. In the far future,
| it's likely someone will make a Zig-like stdlib for Rust
| too, with a &dyn Allocator inside collections.
| zozbot234 wrote:
| > In the far future, it's likely someone will make a Zig-
| like stdlib for Rust too, with a &dyn Allocator inside
| collections.
|
| This exists in the nightly edition of Rust, but is
| unlikely to become a feature in its current form because
| the alternative of "Storages" seems to be a lot more
| flexible and to have broader applicability.
| motoboi wrote:
| I'm starting to form an image of the zig community: people that
| like to write and reason, nice typography, videogame inspired
| visuals.
| drnick1 wrote:
| I have seen this time and time again: first complain that C/C++
| are too complex or lack feature X, new language is proposed, then
| sooner or later people find out that's it's not fast, expressive,
| flexible enough or imposes a nonstandard way of doing things
| (Rust), then back to C/C++ and few years after the cycle repeats.
| cgh wrote:
| Most of the article is about why they didn't use C or C++.
| loxodrome wrote:
| I just want Zig with classes, Zig++. :(
| Mond_ wrote:
| What exactly do you need that Zig doesn't have? Inheritance?
| cgh wrote:
| Proper interfaces would be nice. I realize that eg tagged
| unions work for most cases but the syntactic sugar would
| reduce a bit of friction.
| TSiege wrote:
| Isn't the whole point of zig that it eschews classes and object
| oriented programming?
| dnautics wrote:
| You can bind functions to structs and first parameter is
| special cased when it's a pointer-to or a const version of
| the structs... What more do you want really besides
| inheritance (which is considered dangerous by many). In the
| era of LLMs do you really want that sort of "hidden action"
| that you force the LLM to inefficently reason through?
| F3nd0 wrote:
| Or possibly Objective-Zig. :-)
| jkelleyrtp wrote:
| I mean you can opine about how Rust isn't suited for browser
| development, but as someone building a browser in Rust, I think
| it's just fine. If anything, Rust has been really shining in this
| project since Rust _was designed to build a web browser_.
|
| https://github.com/dioxuslabs/blitz
|
| Also I think it's a little ridiculous to build yet another new
| browser in a new language when so many amazing pieces are just
| sitting around ready for someone to use. Come contribute, we're
| already much further along :)
|
| https://github.com/DioxusLabs/blitz/pull/292
| zem wrote:
| agreed about rust literally being designed to build a browser,
| but when it was developed there were many amazing pieces
| sitting around in c++ :) let the zig folks have a go at
| building their own ecosystem.
| jkelleyrtp wrote:
| That's why Rust was introduced into Firefox piece by piece.
| The goal wasn't to rewrite firefox in Rust - just to migrate
| the scary bits over to a memory safe lang. You can feel a lot
| of that in the servo codebase, weird pointer semantics as a
| result of needing to be API compatible with the C++ adapters.
|
| If I were building a company around a new browser, I'd reach
| for the solid stuff that can be pulled in. Our whole blitz
| project is designed to be modular exactly for that use-case.
| littlestymaar wrote:
| > but when it was developed there were many amazing pieces
| sitting around in c++ :) let the zig folks have a go at
| building their own ecosystem.
|
| Servo had Mozilla's backing in that endeavor though, and even
| then they didn't manage to ship a full browser in a decade,
| the problem is just that hard.
| stefanka wrote:
| I'm really excited for blitz, thanks for this amazing project.
| Do you intend to wipe a full fledged browser out of it?
| jkelleyrtp wrote:
| The browser UI will likely be more of a cool demonstration of
| the project instead of the end goal. We want blitz to exist
| to help make it easier to build stuff like lightpanda.
| There's a whole world of interesting browser forks that
| _could_ exist but don 't, and being able to easily remix the
| browser opens the door to new stuff like AI automation,
| hybrid native gui frameworks, better accessibility tools,
| etc.
| Svoka wrote:
| I was using C++ and C for decades, and I do a lot of embedded
| programming for fun. I switched completely to Rust about half a
| year ago. Friction went away very fast. Fun thing is that looking
| at my old C code now I see so many pitfalls I was oblivious
| about, just because I started to use Rust.
|
| I mean, Rust does have a learning curve, but its complexity is
| overexaggerated imo. Yes, you have to learn something new, but
| how it is a problem?
|
| I don't understand why pick language because it looks familiar
| and you don't have to change how you think. For me that is
| basically a problem with Zig - I can do everything Zig does in
| C++, having decades of libraries and infra while Rust actually
| contributes to the end product.
| 0xbadcafebee wrote:
| Keep in mind you'll be using a different language in the future.
| All software is maintained for a given amount of time and then
| sunset. What matters is the lifecycle of the thing you're making
| now. Pick whatever is maintainable for that application and time
| frame.
|
| Throwaway script? Use anything. A mobile app? Whatever gets it on
| the devices you're targeting today, that works for the life of
| the device/OS/etc. A backend API that will power a large
| platform? Something maintainable (by people other than yourself)
| for 3-5 years. Firmware for IoT that will remain in industrial
| systems for 20 years? Something that is well established and
| supported with a good number of other people who can fix it in
| the long haul.
| wilkystyle wrote:
| I like this take. While I've primarily lived in Python for much
| of my career (and I don't see that changing soon), I've tried
| to find reasons to use other languages in at least a hobby
| capacity so that I can (1) keep my learning muscles warmed up
| and (2) because they can often shape how I think about software
| in general.
|
| Like the Alan Perlis (I think) quote goes: _" A language that
| doesn't affect the way you think about programming is not worth
| knowing."_
| dangoor wrote:
| Something interesting about your comment is that HN also has a
| post today (https://tigerbeetle.com/blog/2025-10-25-synadia-
| and-tigerbee...) about TigerBeetle's support for Zig and their
| reason for using Zig specifically talked about wanting
| something for a long time horizon:
|
| > Investing in creating a database like TigerBeetle is a long
| term effort. Databases tend to have a long half life (e.g.
| Postgres is 30 years old). And so, while Zig being early in
| 2020 did give me pause, nevertheless Zig's quality, philosophy
| and simplicity made sense for a multi-decade horizon.
| Svoka wrote:
| The biggest reason against Rust is 3 year old article from
| personal blog. Trying to reproduce benchmark result from it
| result in failure because Zig code fails to compile.
|
| Meanwhile Rust compiles just fine. Even updating toolchain to
| newest causes no issues and benchmark still runs. All I had to do
| is remove pinning to old toolchain, and bump language version to
| latest. Also changing dependency version to latest worked without
| an issue.
|
| You'd think that performing all advanced memory manipulations you
| would want all the safety you want, but hey. Zig is cool this
| days.
|
| Go figure.
| cloudhead wrote:
| > LLMs deserve a 100x better browser.
|
| Hold on, why can't humans have a 100x better browser?
| coppsilgold wrote:
| Lightpanda doesn't appear to be interested in impersonating a
| more popular browser. How will such a strategy not end in
| failure?
| dzogchen wrote:
| > Anyone who's fought with CMake or dealt with header file
| dependencies knows this pain. For a small team trying to move
| quickly, we didn't want to waste time debugging build
| configuration issues.
|
| I find this take a bit hard to believe. There's no way that Zig
| is some kind of magic bullet that avoids build configuration
| challenges. Especially not considering you are building a browser
| on top of V8 in a different programming language.
|
| CMake is quite crufty, but there's toolchains for every system
| under the Sun and this is what makes it actually less painful in
| a lot of cases. Glossing over your build files it does not look
| particularly scalable or portable. Nice that Zig allows you to
| write build config in Zig though.
___________________________________________________________________
(page generated 2025-12-05 23:00 UTC)