zig VS rust

Compare zig vs rust and see what are their differences.


General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software. (by ziglang)


Empowering everyone to build reliable and efficient software. (by rust-lang)
Our great sponsors
  • WorkOS - The modern API for authentication & user identity.
  • Onboard AI - ChatGPT with full context of any GitHub repo.
  • InfluxDB - Power Real-Time Data Analytics at Scale
zig rust
800 2657
28,854 90,173
4.0% 2.1%
9.9 10.0
2 days ago 4 days ago
Zig Rust
MIT License GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of zig. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-02-05.
  • Show HN: Tokamak – A Dependency Injection-Centric Server-Side Framework for Zig
    6 projects | news.ycombinator.com | 5 Feb 2024
    Atop your readme, you point out that nginx or another reverse proxy should be used. Kudos for that.

    As for performance, I'd be curious what gains you get using `std.http.Server` with keepalive and a threadpool. Possibly you can re-use your ThreadContext - having 1 per thread in the threadpool that you can re-using. `std.Thread.Pool` is also very poorly tuned for a large number of small batch jobs, but that's a place to start.

    [1] https://github.com/ziglang/zig/blob/b3aed4e2c8b4d48b8b12f606...

    6 projects | news.ycombinator.com | 5 Feb 2024
    Yes, fundamentally. In Rust if you take a parameter of generic type T without any bounds, you cannot call anything on it except for things which are defined for all types. If you specify bounds, only things required by the bounds can be called (+ the ones for all types). Another difference is where you get an error when you try pass something which doesn't adhere to a certain trait. In Rust you will get an error at the call site, not at the place of use (except if you don't specify any bounds).

    Zig is doing just fine without any trait mechanism and it simplifies the language a lot but it does come up from time to time. The usual solution is to just get type information via @typeInfo and error out if the type is something you're not expecting [0]. Not everybody is happy about it though [1] because, among other things, it makes it more difficult to discover what the required type actually is.

    [0] https://github.com/ziglang/zig/blob/b3aed4e2c8b4d48b8b12f606...

    [1] https://github.com/ziglang/zig/issues/17198

  • New Linux glibc flaw lets attackers get root on major distros
    7 projects | news.ycombinator.com | 4 Feb 2024
    It's not so unusual to write the C runtime library in a different language.

    E.g. Zig is getting a libc written in Zig:


    Rust would work too of course.

  • Zig Roadmap 2024 [video]
    6 projects | news.ycombinator.com | 27 Jan 2024
    Hi, core team member here (I'm quoted in a parent comment!). The problem with LLVM is not that optimization is slow - it's perfectly acceptable for release builds to take arbitrarily long for optimal binaries. The problem is how long it takes to emit debug builds.

    Take building the Zig compiler itself in Debug mode. This process takes about 30 seconds running through the Zig pipeline (semantic analysis and generating LLVM IR), and then 90 seconds just spent waiting for LLVM to emit the binary. OTOH, when using our self-hosted x86_64 backend (which is now capable of building the compiler, although is incomplete enough that it's not necessarily integrated into our development cycle quite yet), that 30 seconds is essentially the full build (there are a couple of extra seconds on the end flushing the ELF file).

    I can tell you from first-hand experience that when fixing bugs, a huge amount of time is wasted just waiting for the compiler to build - lots of bugs can be solved with relative ease, but we need to test our fixes! Rebuilds are also made more common by the fact that LLVM has an unfortunate habit of butchering the debug information for some values even in debug builds, so we often have to rebuild with debug prints added to understand a problem. Making rebuilds 75% faster by just ditching LLVM would make a huge difference. Introducing incremental compilation (which we're actively working on) would make these rebuilds under a second, which would improve workflows a crazy amount. This would hugely increase our development velocity wrt both bugfixes and proposal implementation.

    It's also important to note that we have quite a few compiler bugs which are [caused by upstream LLVM bugs](https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen...). LLVM often ships with regressions which we report before releases come out and they simply don't fix. In the long term, eliminating the use of LLVM as our main code generation backend will mean that all bugs encountered are our own, and thus can be solved more easily.

    6 projects | news.ycombinator.com | 27 Jan 2024
    > If anything this will further worsen LLVM-powered build-times, surely? What's the motivation here?

    The key motivation is that this will allow Zig to drop its dependencies on the LLVM libraries, instead using a separate LLVM compilation to compile the bitcode file. This is nice because it simplifies the build process and drops the Zig compiler binary size by a full order of magnitude - see https://github.com/ziglang/zig/issues/16270 for more deatils on that. It also allows us to implement incremental compilation on the bitcode file itself to drop compile times a little, which isn't really possible to do through the LLVM API since it doesn't implement certain operations.

    In terms of speed, there's no reason to expect this will worsen our build times; in fact, we expect it will be faster. As with any common C++ API, LLVM's IRBuilder comes with a lot of overhead from how LLVM is written. What we're going to do here is essentially the same work that IRBuilder is doing, but in our own code, for which we will be focusing on performance.

    You can find more details on this at https://github.com/ziglang/zig/issues/13265.

    > ...but that doesn't mean LLVM was easy to develop.

    To be clear, we aren't saying it will be easy to reach LLVM's optimization capabilities. That's a very long-term plan, and one which will unfold over a number of years. The ability to use LLVM is probably never going away, because there might always be some things it handles better than Zig's own code generation. However, trying to get there seems a worthy goal; at the very least, we can get our self-hosted codegen backends to a point where they perform relatively well in Debug mode without sacrificing debuggability.

    6 projects | news.ycombinator.com | 27 Jan 2024
    Thanks for the detailed reply.

    > You can find more details on this at https://github.com/ziglang/zig/issues/13265.

    Thanks for the link, my thoughts mirror those of certik in the thread, which Andrew answered well.

    > at the very least, we can get our self-hosted codegen backends to a point where they perform relatively well in Debug mode without sacrificing debuggability

    Perhaps a useful point of comparison: the lightweight qbe C compiler achieved compile times of around a quarter that of GCC and Clang, with the generated code taking very roughly 170% as long to execute as the code from GCC or Clang. qbe has roughly 0.1% the lines of code as those 'big' compilers. [0] This should presumably be possible for Zig too, and could be a big win for Zig developers.

    Closing the performance gap with LLVM though would presumably be extremely challenging and, respectfully, I can't see the Zig project achieving this. Compiler optimisation seems to be a game of diminishing returns. Even if this were achieved, optimised compilation would surely be much slower than unoptimised.

    [0] https://archive.fosdem.org/2022/schedule/event/lg_qbe/attach... (Relevant discussion: https://news.ycombinator.com/item?id=11555527 )

  • Passing nothing is surprisingly difficult
    2 projects | news.ycombinator.com | 16 Jan 2024
  • Speed up your code: don't pass structs bigger than 16 bytes on AMD64
    3 projects | news.ycombinator.com | 4 Jan 2024
    > I think this is the same in the still experimental Carbon

    Apparently, it's not (anymore?):


    3 projects | news.ycombinator.com | 4 Jan 2024
    Pass by value / pass by ref is quite a bit of mental overhead as it effectively affects your ABI/API. Zig tries to not force this so as long as you "pass by value", the compiler can actually decide to pass it by reference. It does expose this kind of footgun though https://github.com/ziglang/zig/issues/5973#issuecomment-1330...
  • Zig cookbook: collection of simple Zig programs that demonstrate good practices
    6 projects | news.ycombinator.com | 1 Jan 2024
    Hmm, there's a distinct change of opinion by andrewrk from the linked issue (2022) to now

    https://github.com/ziglang/zig/issues/12064 (July 2022):

    > Hope you don't mind I'm going to reopen this issue because it concisely demonstrates a design flaw with result location semantics and I'm not ready to accept status quo as permanent due to aliasing issues like this.

    Compare to a very closely related issue regarding destructing, which exhibits the same problem

    https://github.com/ziglang/zig/issues/17283 September 2023):

    > This is working as designed. Everybody was aware this behavior would be a consequence of destructuring and there is no plan to change it.


Posts with mentions or reviews of rust. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-02-22.
  • Delving Deeper: Enriching Microservices with Golang with CloudWeGo
    7 projects | dev.to | 22 Feb 2024
    Built for the modern development landscape by embracing both Golang and Rust, CloudWeGo delivers advanced features and excellent performance metrics. As proof of its performance, benchmark tests have shown that Kitex surpasses gRPC by over 4 times in terms of QPS and latency, with a throughput increased by 51% - 70% in terms of QPS (Queries Per Second) and latency.
  • Fast memory vulnerabilities, written in 100% safe Rust
    9 projects | news.ycombinator.com | 20 Feb 2024

    “Similarly, the reason why niko's approach is not yet implemented is simply that getting the type system to a point where we even can implement this is Hard. Fixing this bug is blocked on replacing the existing trait solver(s): #107374. A clean fix for this issue (and the ability to even consider using proof objects), will then also be blocked blocked on coinductive trait goals and explicit well formed bounds. We should then be able to add implications to the trait solver.

    So I guess the status is that we're slowly getting there but it is very hard, especially as we have to be incredibly careful to not break backwards compatibility.”

    9 projects | news.ycombinator.com | 20 Feb 2024
    Because Rust doesn't have a specification, we can argue back and forth forever about whether something is part of the "language design". The point is that we know how to solve the problem by desugaring [1] in a way that everyone basically expects to happen already. It's not going to break a significant amount of code: even the bigger sledgehammer of banning contravariance on function types was measured to not have much of an impact.

    As far as I can tell, the main reason to argue "language design" vs. "compiler bug" is to imply that language design issues threaten to bring down the entire foundation of the language. It doesn't work like that. Rust's type system isn't like a mathematical proof, where either the theorem is true or it's false and one mistake in the proof could invalidate the whole thing. It's a tool to help programmers avoid memory safety issues, and it's proven to be extremely good at that in practice. If there are problems with Rust's type system, they're identified and patched.

    [1]: https://github.com/rust-lang/rust/issues/25860#issuecomment-...

    9 projects | news.ycombinator.com | 20 Feb 2024
    I believe it really is a flaw in the language, it's impossible for any compiler to check contravariance properly in this edge case. I don't think anything in this link is incorrect: https://counterexamples.org/nearly-universal.html?highlight=... (and it seems the rustc types team endorses this analysis)

    I am not at all familiar with Miri. Does Miri consider a slightly different dialect of Rust where implicit constraints like this become explicit but inferred? Sort of like this proposal from the GH issue: https://github.com/rust-lang/rust/issues/25860#issuecomment-... but the "where" clause is inferred at compile time. If so I wouldn't call that a "fix" so much as a partial mitigation, useful for static analysis but not actually a solution to the problem in rustc. I believe that inference problem is undecidable in general and that rustc would need to do something else.

    9 projects | news.ycombinator.com | 20 Feb 2024
    Seems to rely on at least one known compiler bug (admittedly one open since 2015) https://github.com/rust-lang/rust/issues/25860
  • json-responder 1.1: dynamic path resolution
    3 projects | dev.to | 12 Feb 2024
    hyper-based HTTP server generating JSON responses. Written in Rust.
  • Rust GraphQL APIs for NodeJS Developers: Introduction
    7 projects | dev.to | 8 Feb 2024
    In my usual NodeJS tech stack, which includes GraphQL, NestJS, SQL (predominantly PostgreSQL with MikroORM), I encountered these limitations. To overcome them, I've developed a new stack utilizing Rust, which still offers some ease of development:
  • On Avoiding Register Spills in Vectorized Code with Many Constants
    2 projects | news.ycombinator.com | 5 Feb 2024
    Compilers also may even spill data to stack from memory, even when the original location is still available, as can be seen in this issue: https://github.com/llvm/llvm-project/issues/53348

    I vaguely remember that spilling like this could allow high-end CPUs to use something similar to register renaming, i.e. stack locations like [rsp + 96] could be stay in a physical registers during function execution (high-end CPUs often have more physical registers, than logical ones), but could find good references whether such optimization exists in practice or not.

    Unfortunately, I think more often than note it causes performance regressions and in some cases it may even cause unnecessary stack spilling of sensitive data: https://github.com/rust-lang/rust/issues/88930#issuecomment-...

  • New Linux glibc flaw lets attackers get root on major distros
    7 projects | news.ycombinator.com | 4 Feb 2024

    So the answer is: Not necessarily. I agree though that the memory safety features in Rust would help reduce the risk. On the other hand, one could also write safer C by abstracting away buffer management. The world is not black and white.

    7 projects | news.ycombinator.com | 4 Feb 2024
    Mind you that there is a runtime overhead.

    If we look at access beyond on a slice's boundary:


    This bounds check is what enables Rust code to fail with a panic vs continuing (which is what triggers a lot of bugs).

    Post about the impact on performance: https://blog.readyset.io/bounds-checks/

What are some alternatives?

When comparing zig and rust you can also consider the following projects:

Nim - Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).

Odin - Odin Programming Language

carbon-lang - Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)

v - Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation. https://vlang.io

go - The Go programming language

ssr-proxy-js - A Server-Side Rendering Proxy focused on customization and flexibility!

rust - Rust for the xtensa architecture. Built in targets for the ESP32 and ESP8266

TinyGo - Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.

crystal - The Crystal Programming Language

Elixir - Elixir is a dynamic, functional language for building scalable and maintainable applications