# How we are going to sell Zig? **URL:** \ **Category:** Brainstorming\ **Tags:** language, c, safety\ **Created:** [November 29, 2024, 1:55pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069 "2024-11-29T13:55:28Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![g41797](https://ziggit.dev/user_avatar/ziggit.dev/g41797/32/3339_2.png) [@g41797](https://ziggit.dev/u/g41797)\ **Post date:** [November 29, 2024, 1:55pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/1 "2024-11-29T13:55:28Z")
[A New Era for C and C++? Goodbye, Rust?](https://www.youtube.com/watch?v=V_QAJAhbH9A) raised my attention. There have already been several discussion on “safe” topic on the forum. They all concerned technical side. And this is mainly marketing issue, because Zig will be compared not with C, but with the future “ **Great Safe C** ”. How we are going to sell Zig? ---
**Author:** ![IntegratedQuantum](https://ziggit.dev/user_avatar/ziggit.dev/integratedquantum/32/782_2.png) [@IntegratedQuantum](https://ziggit.dev/u/IntegratedQuantum)\ **Post date:** [November 29, 2024, 3:56pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/2 "2024-11-29T15:56:38Z")
I think the major advantage of Zig is that it was designed with safety in mind. Sure you can stick extra safety measures on top of C, but it won’t be for free. You will always pay a higher performance cost than the equivalent check in Zig. Take the slice for example. In Zig the compiler knows that it is a pointer and a length, and the safety check can be done on the length. However in Safe C the equivalent `struct {T* ptr; usize len;}` would require adding a third, hidden attribute to the pointer for bounds checking. ---
**Author:** ![Dok8tavo](https://ziggit.dev/user_avatar/ziggit.dev/dok8tavo/32/707_2.png) [@Dok8tavo](https://ziggit.dev/u/Dok8tavo)\ **Post date:** [November 29, 2024, 4:03pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/3 "2024-11-29T16:03:43Z")
I’m actually really interested in this topic, although I’m nowhere near knowledgeable enough to really grasp what’s happening. ---
**Author:** ![daredemo](https://ziggit.dev/user_avatar/ziggit.dev/daredemo/32/3595_2.png) [@daredemo](https://ziggit.dev/u/daredemo)\ **Post date:** [November 29, 2024, 4:09pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/4 "2024-11-29T16:09:07Z")
The thing is… you should not force a language to a task. Some tasks are solved more naturally in some languages than others. To some extent that goes with devs too. If you don’t like (relatively) low level stuff like C and zig, then it would be hard sell anyway. Probably, instead of “selling”, we should just be honest what are the features. It can backfire if you hype something and can’t deliver. Before switching to zig, I did try rust as I was constantly bombarded by hype how good it is… and don’t get me wrong, it is good for some tasks… but the more I was writing the more I disliked the experience. ---
**Author:** ![Dok8tavo](https://ziggit.dev/user_avatar/ziggit.dev/dok8tavo/32/707_2.png) [@Dok8tavo](https://ziggit.dev/u/Dok8tavo)\ **Post date:** [November 29, 2024, 4:25pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/5 "2024-11-29T16:25:46Z")
I agree that marketing isn’t necessarily the good approach. Together we serve the users. The goal isn’t to sell Zig, but to find out what’s the best “Great Safe C” for a given use-case. If Zig 1.0 really is that good that it should be the replacement for C, then it will be as long as the transition from C so Zig is smooth enough. If not there’s no point to “sell” it. ---
**Author:** ![pachde](https://ziggit.dev/user_avatar/ziggit.dev/pachde/32/2485_2.png) [@pachde](https://ziggit.dev/u/pachde)\ **Post date:** [November 29, 2024, 5:54pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/6 "2024-11-29T17:54:31Z")
I expect that by the time Zig reaches 1.0, it will be developing a rich tooling ecosystem that include linters and verifiers that can help cover a lot of the “safety” territory. ---
**Author:** ![mnemnion](https://ziggit.dev/user_avatar/ziggit.dev/mnemnion/32/2478_2.png) [@mnemnion](https://ziggit.dev/u/mnemnion)\ **Post date:** [November 29, 2024, 7:49pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/7 "2024-11-29T19:49:24Z")
Rust evangelism has pushed the notion of ‘memory safe’ as a property of languages, rather than of programs. I think this was largely inadvertent on the part of the core contributors to the language, to be clear, but it muddles the discourse. Python code isn’t memory safe if there’s a bug in the Python interpreter, its garbage collector, or (main threat) any of the C code linked through the FFI. Rust code isn’t memory safe if there are mistakes in the implementation of Rust, or (main threat) if any unsafe blocks are incorrect. Both of these languages reduce the surface area where memory bugs can happen, but it’s _programs_ which are memory safe, not _languages_. Zig does a lot to make it easier and more practical to write memory-safe programs. It’s a language with explicit memory management, and that does allow for memory bugs, of course. But things like null-safety, bounds-checking (in safe release modes), pervasive slices, an idiomatic use of the GPA in debug modes to detect memory bugs, the ease of using patterns like arenas to reduce the surface area of possible memory bugs, these things add up. I don’t expect Zig will need much selling. For the kind of code where Zig really shines, developers are already aware of both the promise of Rust, and the sacrifices needed to cooperate with the strict lifetime and mutability rules, and are able to weigh the benefits of both approaches. Sometimes that balance tilts one way, sometimes the other. What we need to do is keep writing good software in Zig. I expect it will find its natural niche in high-assurance software: performance-critical low-level systems where bugs are not an acceptable outcome. These systems don’t have a special carve-out for memory bugs, where it’s ok to have logic bugs or crash on a bounds-check as long as memory isn’t corrupted. Bugs are _not acceptable_ and memory bugs are _an_ example of an unacceptable defect which must be corrected before the software is complete. Zig’s values are a natural fit here, because it provides all the tools needed to detect memory errors in the course of development, and also emphasizes simplicity, explicit control flow, and _legibility_ of the source code. TigerBeetle is actively demonstrating that Zig is a useful language for this kind of task. ---
**Author:** ![cztomsik](https://ziggit.dev/user_avatar/ziggit.dev/cztomsik/32/3032_2.png) [@cztomsik](https://ziggit.dev/u/cztomsik)\ **Post date:** [November 29, 2024, 7:56pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/8 "2024-11-29T19:56:02Z")
I hope Zig gets pinning and ability to detect if I’ve accidentally returned a pointer to the current function scope. For the last 2 ys, these were the only bugs I had/found. EDIT: What I’m trying to say is that Zig is IMHO very close to “safe” languages already. If you pass allocators and use arena to denote lifetimes, and compile with ReleaseSafe, you should be quite ok. ---
**Author:** ![andrewrk](https://ziggit.dev/user_avatar/ziggit.dev/andrewrk/32/7011_2.png) [@andrewrk](https://ziggit.dev/u/andrewrk)\ **Post date:** [November 29, 2024, 8:47pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/9 "2024-11-29T20:47:39Z")
> How are we going to sell Zig? Make great software that users love. Don’t say it’s written in Zig, just make everyone want to use the software. Make the software fast and bug-free without putting “blazingly fast” in your readme. Quietly delight users, and then when they look under the hood, they find Zig and think, “I knew it!”. Just my opinion. ---
**Author:** ![Calder-Ty](https://ziggit.dev/user_avatar/ziggit.dev/calder-ty/32/10237_2.png) [@Calder-Ty](https://ziggit.dev/u/Calder-Ty)\ **Post date:** [November 29, 2024, 9:21pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/10 "2024-11-29T21:21:31Z")
Odd business plan. Was hoping for more conventional ideas like “vendor lock in”, or Open Core Model. /sarc “The compiler is free, but you have to buy the proprietary optimizations” ---
**Author:** ![Sze](https://ziggit.dev/user_avatar/ziggit.dev/sze/32/496_2.png) [@Sze](https://ziggit.dev/u/Sze)\ **Post date:** [November 30, 2024, 1:19am UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/11 "2024-11-30T01:19:43Z")
> [@mnemnion](#): > > Rust code isn’t memory safe if there are mistakes in the implementation of Rust, or (main threat) if any unsafe blocks are incorrect. And there are implementation bugs ([which take a long time to fix](https://github.com/rust-lang/rust/issues/25860)), demonstrated by this package [GitHub - Speykious/cve-rs: Blazingly 🔥 fast 🚀 memory vulnerabilities, written in 100% safe Rust. 🦀](https://github.com/Speykious/cve-rs) : > **cve-rs** implements the following bugs in safe Rust: > > - Use after free > - Buffer overflow > - Segmentation fault > > **cve-rs** also contains safe reimplementations of: > > - `std::mem::transmute` > - `std::ptr::null()`/`null_mut()` but for references Explained in these videos: - Safe Rust AIN’T SAFE!? (cve-rs) [https://www.youtube.com/watch?v=vfMpIsJwpjU](https://www.youtube.com/watch?v=vfMpIsJwpjU) - “Horribly Unsafe” Safe Rust!? (transmute in cve-rs) [https://www.youtube.com/watch?v=qqgDuEi7OU0](https://www.youtube.com/watch?v=qqgDuEi7OU0) Every language that claims to be safe has this issue, that it may not actually live up to that 100% in its implementation, personally I don’t really want to rely on a type system that is complex, because I see the implementation of the language as part of my responsibility as a developer and ultimately I would want to understand not only how to use the language, but also how it is implemented. IMHO Rust seems too complex to me, like it would require several people each specialized in one area, with Zig I feel more hopeful that I may have an at least basic understanding of all of its parts, eventually, in a more practical amount of time. I also find the approach of having a multitude of tools, that when applied correctly, provide safety in specific ways, a more practical way to approach safety. That way specific tools can have a bug, while others still work, seems like this would allow for a more gradual and incremental way to approach a more safe future. When safety is discussed, I always have to think about lock-picking demonstrations and the various ways they get around a lock that was supposed to be safe. I think safety shouldn’t be thought of as a global property, but instead as something that needs to be considered at every level of detail and for every boundary or new element that is added. When a language is hyped for being safe, but then its implementation has bugs, I think all people using the resulting software end up in a worse place, where the developers are less aware of having to look out for exploits, like what is demonstrated above, and operating from a false sense of security. If anything I would want the Rust community to put a spotlight on these soundness issues and develop practices around making sure that none of those are used in popular packages, until they are fixed. Currently it seems to me like not many people are aware of these problems existing, which means that less careful developers may add packages to their projects that use those exploits. (To be fair, maybe it is more known once you are actually part of the community, than it seems to me looking from the outside?) With languages that don’t claim to be safe, developers are more prepared to take responsibility for the code and dependencies that they rely on and to carefully vet them. (But to be fair, there is also no guarantee that they actually do it.) Ultimately I think both approaches have their benefits (complex type system vs simpler type system), but I think Rust has some problems to overcome in its implementation and personally I would like it if those were communicated in a more prominent space, to people who consider using the language, instead of having to read a [blog post](https://blog.rust-lang.org/2024/06/26/types-team-update.html), which seems a bit like shoving it under the carpet. ---
**Author:** ![permutationlock](https://ziggit.dev/user_avatar/ziggit.dev/permutationlock/32/9958_2.png) [@permutationlock](https://ziggit.dev/u/permutationlock)\ **Post date:** [November 30, 2024, 4:12am UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/12 "2024-11-30T04:12:03Z")
Inspired by Zig, in my personal C projects I’ve been using a `get` macro that gives trapped slice bounds checking in sanitized debug builds and no overhead in release. Obviously not idiomatic, but it is essentially equivalent to Zig outside of using `get(slice, i)` rather than `slice[i]` syntax. ---
**Author:** ![MaciekLeks](https://ziggit.dev/user_avatar/ziggit.dev/maciekleks/32/2110_2.png) [@MaciekLeks](https://ziggit.dev/u/MaciekLeks)\ **Post date:** [September 7, 2026, 8:27am UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/13 "2026-09-07T08:27:03Z")
I know the discussion [New Proposal by Andrew: introduce an actually memory safe (unlike Rust) compilation mode inspired by Fil-C ](https://ziggit.dev/t/new-proposal-by-andrew-introduce-an-actually-memory-safe-unlike-rust-compilation-mode-inspired-by-fil-c/16796) is closed, but I would like to come back to it. I found an opinion there that this topic should be postponed and that more “super-duper” features should be added first on the road to 1.0. Since I am almost 50, I have seen many great projects that ended up with “nothing”. For example, I strongly believed that Julia would become the first-choice language for deep learning. So let me say one thing: the “drama” around Bun should be taken very seriously, because it could be a question of “to be or not to be” for Zig in the near or more distant future. So, in my opinion, memory management should be treated as a high-priority topic before 1.0. We live in the real world, and if something is treated as the core of everything — like memory management — then it should also be treated this way by the Zig community. Otherwise, it may be too late. ---
**Author:** ![floooh](https://ziggit.dev/user_avatar/ziggit.dev/floooh/32/2989_2.png) [@floooh](https://ziggit.dev/u/floooh)\ **Post date:** [September 7, 2026, 9:00am UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/14 "2026-09-07T09:00:00Z")
PS: apologies, I didn’t mean to reply to a zombie thread 😃 PPS: I confused ‘Safe C++’ and ‘Profiles’. Safe C++ is already officially dead (this was the proposal by the Circle C++ author: [Safe C++ proposal is not being continued - Simone Bellavia's Web Page](https://sibellavia.lol/posts/2025/09/safe-c-proposal-is-not-being-continued/)). The fact that whatever solution the C++ Committee favours (in this case: ‘Profiles’) will never lead to anything remains true though (e.g. ‘Profiles’ also looks like it’s dead in the water) But to reply to @MaciekLeks: > So, in my opinion, memory management should be treated as a high-priority topic before 1.0 Zig already has a very good memory and lifetime management strategy via arena allocators. It has no concept of ‘ownership’ though, but fixing this problem **without downsides** is very hard and hasn’t been solved anywhere yet. I guess you mean ‘memory safety’ though. In that case: we need more options that sit between C, Java and Rust in the triangle of “memory safety vs performance vs ergonomics”. If you get 100% memory safety but with the same downsides as Rust or Java, then the language is already irrelevant. Original reply to the first post: Video is completely devoid of useful information 😕 IMHO: at this point, ‘Safe C++’ will never happen, it’s just a distraction by the C++ Committee to make it look like they do something about the topic. A memory safe and mostly compatible C++ variant does already exist (Circle C++), but IIRC the committee refused to even look at it when the author approached them. Fil-C looks more interesting because it can compile most C code without changes, but for code that is potentially unsafe (e.g. lots of heap allocations) it incurs a hefty runtime performance hit (but still probably faster than ASAN), it’s only fast for code that has been designed to be runtime-memory ‘robust’ in the first place (to avoid the absolutist word ‘safe’). It would probably be better if operating systems start to directly support running WASM blobs, since that’s most likely faster than Fil-C. Also, already today, most C and C++ code could be made “mostly safe” if developers would start using existing tools (static analyzers, fuzzing, UBSAN, ASAN, TSAN, …) in their workflows, so improving the usability and workflow integration of those tools would go a long way (Zig is doing a great job at that). The video doesn’t mention LLMs, but personally I think that LLMs as ‘passive bug scanners’ (in addition to traditional code analysis methods) do a good job finding issues (but of course also not waterproof) - it’s _much_ more expensive and takes much longer than traditional analysis methods though. I wonder what traditional static analysis would look like if we were ready to throw the same amount of compute resources at it like we do at LLMs. Also consider that internal memory safety _should not matter_ when the code runs properly sandboxed. E.g. the fact that memory corruption issues can be exploited needs to be ultimately tackled by the sandboxes (web browsers and operating systems). Splitting a program into smaller components, each running isolated might also be a useful approach. Etc.. etc… TL;DR: there is no silver bullet to memory safety vs performance vs ergonomics. ---
**Author:** ![vrypan](https://ziggit.dev/user_avatar/ziggit.dev/vrypan/32/10150_2.png) [@vrypan](https://ziggit.dev/u/vrypan)\ **Post date:** [September 13, 2026, 7:27pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/15 "2026-09-13T19:27:14Z")
It seems to me that the main competitor right now is Rust. Rust is the cool compiled language. I’m not the best person to talk about low-level technical advantages. But one of the reason I like Zig compared to Rust is Zig is easier to read, with fewer idioms, and abstractions. In the AI era, the ergonomics or reading and unpacking code will become more important than writing it because less and less code will be written by humans. But where it matters, humans will want to read the code, and Zig is much more legible. ---
**Author:** ![MaciekLeks](https://ziggit.dev/user_avatar/ziggit.dev/maciekleks/32/2110_2.png) [@MaciekLeks](https://ziggit.dev/u/MaciekLeks)\ **Post date:** [September 14, 2026, 2:07pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/16 "2026-09-14T14:07:23Z")
@vrypan so, please read this post [Zig vs Rust in 2026](https://zackoverflow.dev/writing/zig-vs-rust-in-2026/) I don’t agree with you. Julia is much more readable than Python in the ML domain — and so what? I love Zig and use it, but I can’t shake the feeling that Zig is now where Julia was relative to Python 10 or 11 years ago. ---
**Author:** ![vrypan](https://ziggit.dev/user_avatar/ziggit.dev/vrypan/32/10150_2.png) [@vrypan](https://ziggit.dev/u/vrypan)\ **Post date:** [September 14, 2026, 2:16pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/17 "2026-09-14T14:16:38Z")
Hmm.. I don’t get how this post is an argument against what I wrote. You are making the case that Rust is easier to write than Zig , where I supported Zig is easier to **read** than Rust. ---
**Author:** ![pierrelgol](https://ziggit.dev/user_avatar/ziggit.dev/pierrelgol/32/10233_2.png) [@pierrelgol](https://ziggit.dev/u/pierrelgol)\ **Post date:** [September 14, 2026, 4:08pm UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/18 "2026-09-14T16:08:51Z")
Like many have said, I think it’s something organic, you don’t need to “sell” it, if it’s good it will naturally become predominant. It’s the same theory in economics, there is a saying that goes like “Bad money drives out good” aka Gresham’s Law. This means that in a system where actors are competing fairly, have equal access to information and price, they will inevitably, use the bad money to buy the goods and hoard the valuable one. Zig is great, it’s clearly an improvement over C, and overtime it will convince more people, they will see others have success with the language, and make great projects, and it will inevitably drives them to also try it, and have success too. I don’t know if it’s ever going to be as predominant as C, since C has become more than a language, it has been elevated to the position of universal interface thanks to it’s ABI. But who knows, I think beside the great community, one of the clear advantage that Zig has over C, is how much more reusable it is, what made C so popular was how reusable it was thanks to it’s portability, but even there there’s still a lot of limitations, like if you have a great library but it uses a lot of memory allocations with malloc, suddenly you might not be able to reuse it for a little esp32, meanwhile in zig you could just pass a stack allocator and still reuse the code. Same with Io strategy now thanks to the Io interface, or the Reader/Writer, all those interface makes zig even more reusable and portable than C is. ---
**Author:** ![MaciekLeks](https://ziggit.dev/user_avatar/ziggit.dev/maciekleks/32/2110_2.png) [@MaciekLeks](https://ziggit.dev/u/MaciekLeks)\ **Post date:** [September 15, 2026, 6:23am UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/19 "2026-09-15T06:23:54Z")
@vrypan, I do not think that Rust is simpler to write. I have never thought that. I only wanted to show you that there are people for whom the Rust approach to code — maybe its verbosity — is not a problem, but a benefit. @pierrelgol, recently I wrote a Squid helper in Zig for a quite large corporation (Time was crucial to start the testing phase of a much larger project, so I had a chance to choose a language). I am not sure if it will go to production, because it is not written in a better-known language like Rust. As someone said, if you leave, it would be much easier to find someone with C or Rust skills. Every time a large and visible project, like Bun, moves away from Zig, it is a signal to the world — even if it is not deserved — that Zig could be only a passing language. I only want to say that this situation should be treated very seriously. ---
**Author:** ![pierrelgol](https://ziggit.dev/user_avatar/ziggit.dev/pierrelgol/32/10233_2.png) [@pierrelgol](https://ziggit.dev/u/pierrelgol)\ **Post date:** [September 15, 2026, 7:46am UTC](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069/20 "2026-09-15T07:46:32Z")
I understand your suggestion, but I do not believe in it. I work in the defense industry, more precisely in R&D I was hired to work on mostly embedded/semi-embedded development, I rewrote the firmware I was given from C++ to C, rewriting portions of libcamera, opencv, using libcurl, libgiod, reworking the driver for the imu, compiling a custom raspberry pi kernel with basically everything not needed disabled. Then I recently started rewriting it in Zig, I showed my boss the performance, the fact that now I was able to to a 60fps h264 stream in 40ms max and that p99/95/50 was extremely stable which even Libcamera (the C++ industry standard) isn’t able to achieve. While implementing every IPA the same way it does, simply because I stay in DMA, I use Async/Await thanks to Io, I wrote low level bindings to V4l2, I avoid copies, I avoid false sharing, I cache align things, I use DOD design when possible, I avoid 30 layers of Class Inheritance and abstractions, and i push the hardware to it’s limit, without any dynamic memory allocation. That’s all possible, thanks to Zig. Since in my C version I was just able to remove abstraction layers, and remove unnecessary threads, but I wasn’t able to control everything so neatly, so easily, getting everything right, required too much time. So my point is just that my boss loved the C version, and he was flabbergasted by the Zig version, and you know what ? he doesn’t even know it’s written in Zig, and I don’t think he cares, he just like the fact that in my time here, I’ve made his software 10x more performant, more testable by abstracting where it make sense and implementing interface where it matters, by caring and trying to do a good job, and I think Zig, like any tool is great because it allows you to make great things. I don’t think Zig needs to worry, because the results should speak for themselves, making great software is hard, making great software and having people use it is the easy part of the equation, the hard part is making great software. [Next page](https://ziggit.dev/t/how-we-are-going-to-sell-zig/7069.md?page=2)