mojo VS zig

https://github.com/modularml/mojo/blob/main/LICENSE Is this not it?

Interesting, but the intent seems similar to Chris Lattner's new Mojo language which arguably has similar characteristics and is further along in its development.

https://docs.modular.com/mojo/

Mojo is a programming language that combines the performance and control inherent in systems languages like C++ and Rust with the flexibility and simplicity of use typical of dynamic languages like Python. Because of its combination of performance, extensibility, and usability, its design makes it possible to construct high-performance systems, which makes it a good option for AI development.

If you take a look at the optimized Mojo code doing the matrix multiply [1], it takes an expert to understand. It’s not just some simple for-loops in Mojo they’re comparing against.

[1] https://github.com/modularml/mojo/blob/5ce18c47a27c0c4123de1...

Mojo truly unlocks a world of possibilities in high-performance computing.

For a concrete example of Liquid Haskell, see how Gabriella Gonzalez safely removed bound checks of high-performance protocol parsing, in "Scrap your Bounds Checks with Liquid Haskell" [1].

With Liquid Haskell, the bound checks are moved from runtime to compile time, semi-automatically handled by SMT-solvers. With static types, programmers can write correct programs faster, and the programs also run faster.

As an aside, speeding up programs with static analysis (constrained dynamism) are also present in Mojo (a variant of Python) or Swift [2].

[1]: https://github.com/Gabriella439/slides/blob/main/liquidhaske... "Scrap your Bounds Checks with Liquid Haskell"

[2]: https://github.com/modularml/mojo/discussions/466 "Mojo and Dynamism"

It's "Zig" not "Zag". https://ziglang.org/ Zig is under heavy development, but there's a single page https://ziglang.org/documentation/0.12.0/ that is a reasonably comprehensive source of truth about the current state of the language.

There is an issue proposing this approach: https://github.com/ziglang/zig/issues/4284

https://github.com/ziglang/zig/issues/224

e.g.:

> > When debugging/prototyping, it's useful to comment out a line without having to refactor, e.g.

When writing code in a scripting language, sometimes you need that extra bit of performance (or maybe an async feature from Zig).

NodeJS is by no means a slow runtime, it wouldn’t be so popular if it was. But compared to Bun, it’s slow. Bun was built from the ground up with speed in mind, using both JavascriptCore and Zig. The Bun team spent an enormous amount of time and energy trying to make Bun fast, including lots of profiling, benchmarking, and optimizations.

ntdll.dll!RtlUserThreadStart()

There are valid reasons to use APIs from NTDLL. Where I disagree with zig#1840 is the idea that it is always better to use NTDLL versions of API. Every other software ecosystem uses the standard Win32 APIs and diverging from that without a good reason seems like a good way to have unexpected behavior. One concrete example is most users and programmers expect Windows to redirect some file system paths when running on WOW64. But this is implemented in Kernel32, not ntdll.

https://github.com/ziglang/zig/issues/11894