zig VS v

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.

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.

> 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/

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:

https://github.com/ziglang/zig/pull/10428

Issue for it being removed

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.

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

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?

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 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

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).

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:

Among Vlang's GitHub milestones:

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.

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).

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).