zig VS llvm-project

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

Did you consider LLVM? (https://llvm.org/)

The beauty behind Zig is that it supports many cross-platform targets by using shims from LLVM, and almost any platform that LLVM supports, Zig will support. Let's try to write some Zig code now to add two signed integer numbers.

BOLT is a tool originally created by Facebook engineers, now it's part of mainline LLVM. https://github.com/llvm/llvm-project/tree/main/bolt

Yep, this is why a lot of people will target something like LLVM (https://llvm.org/) or another language (like transpiling to C) so they can leverage those systems to handle platform targeting.

One illustration of this came in 2015 when Stallman decided he would rather prevent the Gnu Compiler Collection from supporting modern IDE features like symbol completion, than allow GCC front ends to be paired with free-but-not-copyleft backends like LLVM and Clang: "Since LLVM and Clang are not copylefted, they invite nonfree extensions. They are a gaping hole in the defensive wall around our city." Allowing full access to GCC's internals would have obvious technical benefits, and as far as I know Stallman advanced no technical argument against the proposal. Disallowing it put the project at a significant disadvantage at a time when its influence was already waning. The message was clear: GCC exists to serve FSF, not the other way around.

Google recently unveiled Carbon, an experimental language that is intended to match the performance of the C++ language while supporting LLVM(Low Level Vitual Machine) and being able to interoperate with existing C++ code bases. This is a big deal because C++ is by far the most widely used language for developing HIGH performance low level systems.

I wonder whether this project is based on the work in our M68k backend:

> https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...

You may want to look at LLVM. It’s what’s being used as a compilation foundation to build modern languages like Rust, Zig, …

Solved for now