zigenesis VS zig

Compare zigenesis vs zig and see what are their differences.


Build ANY project in ANY Language with Zig. (by bettertools)


General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software. (by ziglang)
Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
zigenesis zig
1 802
9 29,047
- 2.0%
10.0 9.9
over 1 year ago 5 days ago
Zig Zig
- MIT License
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 zigenesis. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-12-07.


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-28.
  • MicroZig: Unified abstraction layer and HAL for Zig on several microcontrollers
    5 projects | news.ycombinator.com | 28 Feb 2024
    ESP32 and STM32 support is very welcome!

    I have been following https://github.com/ziglang/zig/issues/5467 for a while and progress seemed to have slowed significantly

  • Asynchronous Clean-Up (in Rust)
    5 projects | news.ycombinator.com | 25 Feb 2024
    I have never used it directly, take what I say with a grain of salt.

    As far as I know at least part of the idea was to eliminate the function coloring problem by letting the compiler do some nifty compile-time deductions. This had some issues (I don't know if this is still planned, it seems like the kind of thing that should not work in practice). Additionally, there were all sorts of hard technical issues with LLVM, debugging, etc.

    I recommend checking the issue tracker, eg. https://github.com/ziglang/zig/issues/6025

    I personally don't understand the domain well enough at all, but honestly, I feel like (if possible) Zig should try to double down on its allocator approach.

    Instead of trying to use some compile-time deduction magic explicitly pass around an "async runtime/executor" struct which you explicitly have to interact with. Why not?

  • 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?):


What are some alternatives?

When comparing zigenesis and zig 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

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

rust - Empowering everyone to build reliable and efficient software.

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

regex - An implementation of regular expressions for Rust. This implementation uses finite automata and guarantees linear time matching on all inputs.

llvm-project - The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.

Beef - Beef Programming Language