zig
v
Our great sponsors
zig | v | |
---|---|---|
456 | 150 | |
16,826 | 30,067 | |
15.0% | 2.1% | |
10.0 | 10.0 | |
6 days ago | 6 days ago | |
Zig | V | |
MIT License | MIT License |
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.
zig
-
Will Bun JavaScript Take Node's Crown
It really isn't that much different though. After skimming through the source code of Zig, you can see that well over 90% of the code is OS independent.
Not only that, it looks like they do have windows support and it's just failing atm. It also looks like they have cleanly separated all OS functionality from the logic. This is where it looks like the majority of the OS dependent code lives[0], and the implementation for this is 1000 lines of code. So clearly, it looks like it shouldn't take more than a few hours to get even a programming language up and running when porting it.
Further, it looks like they're using the cpp stdlib to assist with some OS dependent functions[1]. They're clearly using at least:
* std filesystem
* std future
* std iostream
* std mutex
* std thread
* std atomic
And more. So if you're being smart about things, which it looks like the developers most certainly are, then you don't need to reinvent 90% of the OS dependent code and can instead use the stdlib that already exists to automagically get that functionality.
[0]: https://github.com/ziglang/zig/blob/master/src/stage1/os.hpp
[1]: https://github.com/ziglang/zig/blob/a9c4dc84f487c4764c578743...
Zig, the programming language Bun is written on, is currently having some Windows headaches of its own: https://github.com/ziglang/zig/issues/12420
I wonder how much of Bun's immaturity is due to Zig's own immaturity.
-
Announcing: MiniRust
Take https://github.com/ziglang/zig/issues/12251 as an example. Several people from the Rust and Haskell community slacked off on twitter about how awful of a language design this is. However, when you think about what the language actually compiles to it makes perfect sense, and is pretty straightforward.
Rust has the goal of putting as much smartness between what you type and what gets produces, which is a perfectly fine goal, but without a specification for the input semantics it's a pretty wobbly thing, especially for a systems programming language. A lot of bit packing code is simply not writable in rust today without immediately invoking UB, that works for now but might break with every bugfix release.
-
The pervasive effects of C's malloc() and free() on C APIs
> This is unavoidable in any language that (supports dynamic memory allocation and) moves dynamic memory allocation into a library.
Not necessarily. The Zig[1] standard library forces callers to provide at runtime an allocator to each data structure or function that allocates. Freeing is then handled either by running deinit() on the datastructure returned (a standard convention), or, if the function returns a pointer, using the same allocator you passed in to free the returned buffer. C's problem here is it doesn't have namespaces or member functions, so there's a mix of conventions for what the freeing function should be called.
C++ allows this as well for standard library containers, although I've rarely seen it used.
> Also, say a DLL function returns a char pointer containing a string. How would you know whether to call free or delete on it? Or, maybe, the equivalent of free in Frob, the language that DLL happens to be written in?
I have to concede this one. I can't see a way out of this other than documentation.
[1]: https://ziglang.org/
-
Original source of `(seed * 9301 and 49297) % 233280` random algorithm?
On modern hardware, you should instead use a count-leading-zeroes instruction to directly generate the exponent bits from a uniform bit pattern. This is what is done in the Zig standard library:
-
Bound Functions
Issue for it being removed
-
WebAssembly with Zig, Part 1
A simpler language exists, named Zig. Zig is a newish language that still hasn't hit a 1.0 milestone release quite yet, it's currently at 0.9.1. But Zig is, in my eyes, a very good language. It's plain, it's simple, and you can read through the documentation pretty easily. It lends itself to classic C, and borrows ideas from other languages in a few places.
-
Why is GitHub so important?
it's more than just file sharing. you can view the history of each git commit, different branches of the same codebase, an issues tab to manage bugs, pull requests for the merging of code from one branch to another and plenty more
-
Why no function overloading?
I can't seem to find any rationale for Zig not supporting function overloading, only mentions from Andrew that Zig does not and probably never will have it. Meanwhile that's one of the worst flaws of C, and one very easily correctable. Have there been any hard counter-arguments given?
-
What is missing in the zig ecosystem?
Out of curiosity, when's the last time you looked into it? The deflate implementation got completely rewritten ~6 months ago: https://github.com/ziglang/zig/pull/10552
v
-
Programs built with the V compiler no longer leak memory by default.
v does escape analysis by invoking date +%s and reading reading the first digit, putting variables on the heap if odd and leaving them on the stack if even
-
Which other programming language best complements Python - Rust, Go, or something else?
Vlang also exists. It's not fake or "vaporware" (another ludicrous smear), and has more than a hundred releases that produces working programs (download and see).
-
Vlang Has Over 30,000 Stars On GitHub!
With more than 100 releases, clearly Vlang is not "vaporware" nor would any sane person think such a thing in the last 3 years. Vlang has also shook and shocked various detractors, probably more than they would ever admit, by doing vastly better than they expected. Vlang didn't fade away into the night, like they hoped it would, but instead kept continually growing and improving. And this is not just reflected in GitHub stars (which some may try to dismiss), but can be seen by comparing other statistics such as:
-
Vlang Now Has Over 30,000 Stars On GitHub!
Among Vlang's GitHub milestones:
-
Capy – Cross-platform library for making true native GUIs in Zig
By the way, Vlang has that level of C interop as well (https://github.com/vlang/v/blob/master/doc/docs.md), plus an outright C2V transpiler.
-
Array of tuples (newbie question)
It appears we are starting to diverge from the original question, to multiple other questions, so that maybe they would be better as a separate questions. Also, V users usually hang out more on discord (https://discord.com/invite/vlang) or on Vlang GitHub discussions (https://github.com/vlang/v/discussions).
- Some Thoughts on Zig
-
Carbon - an experimental C++ successor language
Vlang, a Go alternative language, has had: generics, map, filter, and more for quite a long time (https://github.com/vlang/v/blob/master/doc/docs.md).
What are some alternatives?
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
go - The Go programming language
rust - Rust for the xtensa architecture. Built in targets for the ESP32 and ESP8266
rust - Empowering everyone to build reliable and efficient software.
TinyGo - Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.
crystal - The Crystal Programming Language
llvm-project - The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at http://reviews.llvm.org.
regex - An implementation of regular expressions for Rust. This implementation uses finite automata and guarantees linear time matching on all inputs.
zig-range - A range function to loop over an index without an extra variable.