Automate the mundane part of your day, with live actionable messages for your GitHub & Jira tasks. Learn more →
Zig Alternatives
Similar projects and alternatives to zig
-
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).
-
-
Zigi
Workflow assistant built for devs & their teams. Automate the mundane part of your day, with live actionable messages for your GitHub & Jira tasks.
-
-
-
-
-
InfluxDB
Build time-series-based applications quickly and at scale.. InfluxDB is the Time Series Data Platform where developers build real-time applications for analytics, IoT and cloud-native services in less time with less code.
-
TinyGo
Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.
-
tigerbeetle
A distributed financial accounting database designed for mission critical safety and performance. [Moved to: https://github.com/tigerbeetledb/tigerbeetle] (by coilhq)
-
oil
Oil is a new Unix shell. It's our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
-
-
-
bun
Incredibly fast JavaScript runtime, bundler, transpiler and package manager – all in one.
-
-
Rust-for-Linux
Adding support for the Rust language to the Linux kernel. (by Rust-for-Linux)
-
-
rust
Rust for the xtensa architecture. Built in targets for the ESP32 and ESP8266 (by esp-rs)
-
-
-
Scout APM
Truly a developer’s best friend. Scout APM is great for developers who want to find and fix performance issues in their applications. With Scout, we'll take care of the bugs so you can focus on building great things 🚀.
NOTE:
The number of mentions on this list indicates mentions on common posts plus user suggested alternatives.
Hence, a higher number means a better zig alternative or higher similarity.
zig reviews and mentions
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 2022-11-22.
-
Why is Go's Garbage Collection so criticized?
[2] https://github.com/ziglang/zig/blob/master/lib/std/heap/arena_allocator.zig
-
What about Zig don't you like?
async cancellation is awkward
-
0.10.0 has been released
See for example https://github.com/ziglang/zig/issues/13111
-
Zig Is Self-Hosted Now, What's Next?
Here's a pretty substantial bug from just a week ago: https://github.com/ziglang/zig/issues/13211
If bugs are your concern, then this upcoming release is good news for you. Total number of open bug reports is 1,124. However if we remove bugs labeled "stage1" - that is - bugs that are no longer applicable because this release changes the default compiler to the self-hosted one - then the number drops to 514. It would be a fair characterization to say that this release cuts the number of known bugs in half. We have those stage1 bug reports still open because I mandated that every one must have test coverage before being closed, even though they are already fixed in master branch.
That said, I would humbly ask for you to trust my leadership on finding the balance on how much effort to spend on bug fixing versus how much to spend on progress. I think you underestimate how much is going to change before Zig tags 1.0. There are still a few experimental and exploratory changes planned, and when software specifications change, bugs are inevitably introduced. Spending the time to iron out 100% of the bugs found from fuzz testing, on a feature that ends up replaced with a different one that also needs to get debugged, is a waste of time, and a disservice to the wider user base of the project. We're better off finding the "sweet spot" for a swift journey, arriving at our destination early, and then busting out the hardcore QA.
I see https://github.com/ziglang/zig/issues/13211 mentioned elsewhere in this thread. I want to point out that getting the C ABI correct when using LLVM is a notoriously perilous process, as any other compiler dev reading HN today can attest, and this regression which lasted for a total of 6 days in master branch without ever gracing a tagged release, is a symptom of the fact that we actually addressed this C ABI problem at its core, added more test coverage, added an abstraction in the LLVM code generation, and fixed the C ABI for several targets.
And finally, I agree that fuzz testing should be integrated into Zig's unit testing system. That would be a nice enhancement.
The bug that's currently blocking me from any work using master is https://github.com/ziglang/zig/issues/12325
That's not really a bug related to unfinished features that might get replaced anyways, but simply one involving recursive structs with pointers between, i.e. linked lists.
Not detecting issues like these feels less like a "these parts are unfinished hence here be dragons" thing and more like a fundamental culture problem.
I'm fine with cutting myself every now and then with a sharp tool and cutting edge technology, but that can also be done while having a ever growing and mature core that promises at least some stability. The only alternative seems to be to pull a Hickey and work on it for two years without releasing anything.
We do have a good number of known miscompilations, I can substantiate for the parent poster with a simple link: https://github.com/ziglang/zig/labels/miscompilation
It's also true that the self-hosted compiler has caused new bugs to pop up, which in turn made us write new behavior tests. To me that's to be expected with every project aimed at rewriting an existing system.
It's also true that proper testing infrastructure is critical, and we do have it, although the requirement of more than 8gb of ram has not played in our favor in the past. We plan to revamp our CI systems once we are done with this release.
That said, it's a v0 language. If you choose to use it, you know you're coming with us on a ride. The choice of how much to prioritize correctness vs progress is influenced by many things that are going on in the project and there is no one clear strategy that trumps all others.
Quoting j-pb from another comment:
> A language that (does or doesn't) compile your code in 0.1 seconds to a broken binary is worse than piping your code into dev/null.
Eh, yes, but also no. Obviously a compiler needs to work correctly to be useful, but our priority right now is to move the project forward using our best judgment, not ensure that it has maximal utility to early adopters. I do agree with the sentiment that the compiler needs to be reliable, it's just that Zig is v0 for a reason.
In concrete terms I think that once we're done with an initial adjustment phase, you will find that the compiler will have a steady increase in stability over time. That's how it was with the bootstrap compiler before we started the self-hosted work.
Also, quoting dist1 from up the comment tree:
Zig has thousands of tests, but the problem space of a programming language is pretty big, making fuzzing and other similar techniques worth the effort in the long run. The discussion wasn't about the existence of basic tests.
-
Languages That Don't Dogfood 🤔
Zig
-
A note from our sponsor - Zigi
www.zigi.ai | 28 Nov 2022
Stats
Basic zig repo stats
543
18,583
10.0
6 days ago
ziglang/zig is an open source project licensed under MIT License which is an OSI approved license.
Static code analysis for 29 languages.
Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.
www.sonarqube.org