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.
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
> 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++.
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
That's true, but as someone that doesn't do much rust, C++ is a language where there are fewer 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....
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.)
You can absolutely make a complete, featureful program in Rust without naming a single lifetime, or even without dealing with a single reference/borrow.
But Rust is a dramatically smaller language than C++. The various subsets of C++ people usually carve out tend to be focused on particular styles of programming, like “no exceptions” or “no RTTI”. Notably never things like “signed integer overflow is now defined”, or “std::launder() is now unnecessary”.
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.
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.
> 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.
>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
I think we've heard these arguments ad nauseum at this point, but the longer I use Rust for ensuring long-term maintenance burden is low in large systems that I have to be absolutely, 10,000% correct with the way I manage memory the more it seems to reduce the effort required to make changes to these large systems.
In scenarios where multiple people aren't maintaining a highly robust system over a long period of time, e.g. a small video game, I think I'd absolutely prefer Zig or C++ where I might get faster iteration speed and an easier ability to hit an escape hatch without putting unsafe everywhere.
> I eventually came to the decision to stop developing in Rust, despite its popularity
It's also not very popular for a language that old. It's roughly as popular as Ada was when it was the same age Rust is today (there may not have been as many projects written in Ada then, but there were certainly much bigger/more important projects being written in Ada then). It's not nearly as popular as C, or C++, or Java, or C#, or Go were at that age.
The relatively small number of developers who program in Rust, and the smaller still number of them who use it at work, are certainly very enthusuastic about it, but an enthusiastic base and popularity are very different things.
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.
I don’t think it’s a useful observation. Lots of people come to Rust from OOP languages and try to make everything `Arc<dyn Interface>`, and it immediately fails, to their great frustration.
> 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.
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.
Back in the day, before I had our robot overlords to write code for me, I would just use C++ as a fancy C with classes and a larger standard library. Or Boost as they have some fun and exciting things to play with.
Now, the robots do a good enough job at writing clean C++ without going too crazy that I just kind of let them do their thing and review the very readable code to keep them on the right path.
I can't even imagine the nightmare with something like a browser where you'd be pulling in C++ dependencies from all over the place and each having their own way of doing things. I mean, I get annoyed when C libs don't do the 'object to be operated on' as the first argument to functions so they can't be trivially wrapped in Python C-API extensions super easily using generators.
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.
I am too old and stupid to not use Rust. I’m kidding of course, but the mental load of doing the things we used do in C++ is really noticeable once it’s gone.
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.
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.
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."
> 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.
I think CMake is cool when it works, but debugging it when it doesn't is hell. I've often spent an inordinate amount of time trying to figure out why doesn't it pick up library paths.
And although I know Microsoft is uncool, I still want to shill vckpkg as it seems they finally managed to create a usable cross platform package manager for C++
I wrote an article (this morning actually!) on picking up Rust to combat AI brain atrophy. My background is JVM-based (Kotlin), and my main contenders were Go vs Rust vs Zig.
My reasoning for settling on Rust:
If I wanted something more general-purpose and ergonomic, I'd stick with something like Kotlin, which has wider ecosystem support. Go could fit here too, but I've heard from more experienced folks that Go's simplicity can get limiting as codebases grow (and requires 100s of developers to be disciplined). Not impossible, just not as conducive.
But since I specifically wanted a performant systems language, I figured I'd go to the other extreme. So my choice was Rust or Zig. I eventually chose Rust (as complicated as Rust can seem) the borrow checker is pretty elegant once it clicks and provides the necessary safety net for a language I intentionally am choosing for more control.
I didn't read much past their headline and blurb, but I don't think they're aiming to compete with normal browsers. This seems like a Selenium situation but with AI integration on top.
What did I say that suggested they intend to compete with a normal browser?
Right now their browser is trivial to block, it provides no value that I can see. curl-impersonate is more useful than what they offer, at least it won't be stuck on captchas as often.
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?
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?
I downvoted because I'm interested in charitable, non-disparaging conversation. I post this so the above commenter doesn't confuse a downvote (1 bit of information) as validation of their claim. I'm personally uninterested in spending much time looking at Zig right now, but I'm keeping an eye on it and generally interested in the progression of languages over time.
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.
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.
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 :)
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.
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.
> 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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
Oh yes I know they do in this post, I meant more generally. Even myself I often wish I had a need to use a lower-level, cooler language, but the pragmatic side of me just can't justify it.
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.
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.
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.
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.
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.
> 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.
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?
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.
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.
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.
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
> 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++.
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
That's true, but as someone that doesn't do much rust, C++ is a language where there are fewer 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....
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.)
Precisely.
You can subset C++ and still knock out a program.
You cannot subset Rust and still create a program.
You can absolutely make a complete, featureful program in Rust without naming a single lifetime, or even without dealing with a single reference/borrow.
But Rust is a dramatically smaller language than C++. The various subsets of C++ people usually carve out tend to be focused on particular styles of programming, like “no exceptions” or “no RTTI”. Notably never things like “signed integer overflow is now defined”, or “std::launder() is now unnecessary”.
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.
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.
> 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.
I'm not convinced that you can't borrow check in zig... (disclaimer, i'm working on compile time memory safety for zig)
>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
I think we've heard these arguments ad nauseum at this point, but the longer I use Rust for ensuring long-term maintenance burden is low in large systems that I have to be absolutely, 10,000% correct with the way I manage memory the more it seems to reduce the effort required to make changes to these large systems.
In scenarios where multiple people aren't maintaining a highly robust system over a long period of time, e.g. a small video game, I think I'd absolutely prefer Zig or C++ where I might get faster iteration speed and an easier ability to hit an escape hatch without putting unsafe everywhere.
> I eventually came to the decision to stop developing in Rust, despite its popularity
It's also not very popular for a language that old. It's roughly as popular as Ada was when it was the same age Rust is today (there may not have been as many projects written in Ada then, but there were certainly much bigger/more important projects being written in Ada then). It's not nearly as popular as C, or C++, or Java, or C#, or Go were at that age.
The relatively small number of developers who program in Rust, and the smaller still number of them who use it at work, are certainly very enthusuastic about it, but an enthusiastic base and popularity are very different things.
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.
I don’t think it’s a useful observation. Lots of people come to Rust from OOP languages and try to make everything `Arc<dyn Interface>`, and it immediately fails, to their great frustration.
Do not do this.
I think it is inherently significantly harder to use than Swift.
I feel like vibe coding has completely changed this paradigm. Now all I care about is how fast and reliable the language is.
What are you developing in?
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.
> 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.
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.
Most of the article is about why they didn’t use C or C++.
Back in the day, before I had our robot overlords to write code for me, I would just use C++ as a fancy C with classes and a larger standard library. Or Boost as they have some fun and exciting things to play with.
Now, the robots do a good enough job at writing clean C++ without going too crazy that I just kind of let them do their thing and review the very readable code to keep them on the right path.
I can't even imagine the nightmare with something like a browser where you'd be pulling in C++ dependencies from all over the place and each having their own way of doing things. I mean, I get annoyed when C libs don't do the 'object to be operated on' as the first argument to functions so they can't be trivially wrapped in Python C-API extensions super easily using generators.
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.
I am too old and stupid to not use Rust. I’m kidding of course, but the mental load of doing the things we used do in C++ is really noticeable once it’s gone.
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.
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.
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."
> 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.
I think CMake is cool when it works, but debugging it when it doesn't is hell. I've often spent an inordinate amount of time trying to figure out why doesn't it pick up library paths.
And although I know Microsoft is uncool, I still want to shill vckpkg as it seems they finally managed to create a usable cross platform package manager for C++
I wrote an article (this morning actually!) on picking up Rust to combat AI brain atrophy. My background is JVM-based (Kotlin), and my main contenders were Go vs Rust vs Zig.
My reasoning for settling on Rust:
If I wanted something more general-purpose and ergonomic, I'd stick with something like Kotlin, which has wider ecosystem support. Go could fit here too, but I've heard from more experienced folks that Go's simplicity can get limiting as codebases grow (and requires 100s of developers to be disciplined). Not impossible, just not as conducive.
But since I specifically wanted a performant systems language, I figured I'd go to the other extreme. So my choice was Rust or Zig. I eventually chose Rust (as complicated as Rust can seem) the borrow checker is pretty elegant once it clicks and provides the necessary safety net for a language I intentionally am choosing for more control.
(here's my article on learning Rust if folks are interested: https://kau.sh/blog/learn-rust-ai-atrophy/) - different angle from the linked article.
I'm starting to form an image of the zig community: people that like to write and reason, nice typography, videogame inspired visuals.
> LLMs deserve a 100x better browser.
Hold on, why can't humans have a 100x better browser?
Because you can't sell a better browser to LLM companies. That's their current business model.
Lightpanda doesn't appear to be interested in impersonating a more popular browser. How will such a strategy not end in failure?
I didn't read much past their headline and blurb, but I don't think they're aiming to compete with normal browsers. This seems like a Selenium situation but with AI integration on top.
What did I say that suggested they intend to compete with a normal browser?
Right now their browser is trivial to block, it provides no value that I can see. curl-impersonate is more useful than what they offer, at least it won't be stuck on captchas as often.
I just want Zig with classes, Zig++. :(
Isn't the whole point of zig that it eschews classes and object oriented programming?
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?
Or possibly Objective-Zig. :-)
What exactly do you need that Zig doesn't have? Inheritance?
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.
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?
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.
I downvoted because I'm interested in charitable, non-disparaging conversation. I post this so the above commenter doesn't confuse a downvote (1 bit of information) as validation of their claim. I'm personally uninterested in spending much time looking at Zig right now, but I'm keeping an eye on it and generally interested in the progression of languages over time.
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.
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
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.
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.
> 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.
I’m really excited for blitz, thanks for this amazing project. Do you intend to wipe a full fledged browser out of it?
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.
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.
Author and founder here. Thank you!
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?
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.
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?
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.
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.
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…
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.
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.
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.
> 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.
Oh yes I know they do in this post, I meant more generally. Even myself I often wish I had a need to use a lower-level, cooler language, but the pragmatic side of me just can't justify it.
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.
https://paulgraham.com/avg.html
Paul Graham is one of the founders of Y Combinator, the company that hosts Hacker News.
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.
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.
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.
The opposite is true: there are a lot of projects that failed because of the chosen language.
What are some famous examples?
Eclipse, Azureus, Minecraft, MySpace with ColdFusion, OpenOffice's Java parts...
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?
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.
> 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.
Ruby on Rails.
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?
[dead]
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.
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.