zig VS regex

Compare zig vs regex and see what are their differences.


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


An implementation of regular expressions for Rust. This implementation uses finite automata and guarantees linear time matching on all inputs. (by rust-lang)
Our great sponsors
  • Onboard AI - ChatGPT with full context of any GitHub repo.
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern API for authentication & user identity.
zig regex
800 91
28,854 3,266
4.0% 1.9%
9.9 9.2
2 days ago 10 days ago
Zig Rust
MIT License Apache License 2.0
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 regex. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-01-24.

What are some alternatives?

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

re2 - modern regular expression syntax everywhere with a painless upgrade path [Moved to: https://github.com/SonOfLilit/kleenexp]

node-re2 - node.js bindings for RE2: fast, safe alternative to backtracking regular expression engines.

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