It's an unwillingness to implement documentation generation twice. Why do it in the c++ compiler when the goal is to become self-hosted?

I think there's a good answer to this which is, "because people really, really need documentation." So I am kicking around ideas of how this can be done without too much duplicate effort.

It's currently my main UI font: https://imgur.com/cTLq6Oo.png

Pairs nicely with Fantasque Sans Mono (though if there was a more Comic Sans/Neue-like typeface, I'd set that as my terminal/editor font in a heartbeat).

debug and safe modes in zig disallow overflows entirely unless you specifically use the wrapping operator to clearly specify your intent. These checks are removed in speed-optimized builds.

In other words, the compiler will enforce that `a + b` does not overflow through all your testing and wherever you explicitly say such checks are required, but turns them into nops for you when you desire speed. You can let the compiler know that you explicitly want wrapping overflow (and not some undefined kind) using the wrapping operator `a +% b`.

Please check your facts: https://ziglang.org/documentation/master/#Integer-Overflow

They got rid of the % operator for error propagation for one.

The latter. Zig actually kinda does define this behavior as "`a + b` shall not overflow" and inserts checks in debug and safe builds for it. To get overflow, which zig defines as wrapping overflow, you use a different operator and no check is inserted "`a +% b`". For speed optimized builds, unless you've explicitly told the compiler to insert checks in that scope, it will turn the checks into nops.

So, while it is technically correct to say that it has undefined behavior for overflow, the practical reality is quite different.

If a language allows you:

- to map cleanly with what compilers know to optimize best

- fine control over stack and heap allocation

- has intrinsics / assembly escape hatch

- allows you to specify that pointers don't alias (restrict in C, or default in Fortran)

- gives you prefetching primitives

You will be able to reach hand-tuned Assembly-like performance (and not just C-like performance).

Case in-point, I tuned my own matrix multiplication algorithms in Nim to carefully control register allocations, L1, L2 and L3 cache usage, and vector intrinsics to reach the speed of assembly tuned OpenBLAS and Intel MKL-DNN (no assembly at all):

bench: https://github.com/numforge/laser/blob/c7ddceb0/benchmarks/g...

code: https://github.com/numforge/laser/tree/c7ddceb0/laser/primit...

And matrix multiplication has decades of research and now dedicated hardware (tensor cores, EPU, TPU, NPU, ...) as this is a key algorithm for most numerical workloads.

> A language can't be "faster than C".

Why not? For instance, with current hardware, the good use of SIMD is critical. If you can't write vectorized code in (standard) C while you can do it in another Language, that would be a "faster" language. Same for other language features that enable faster code: Compile-time computations, better memory model with different pointer aliasing semantic, ...

You can dispute Zig, but in practice there is FORTRAN that is faster for many math procedures.

Nim and d both have comparable interop, and nim even works with c++.

To be fair, Zig's C interoperability appears to be inspired or borrowed from Swift's little known secret called the ClangImporter.

After a few minutes of trial and error (mostly around convincing Zig's type checker that various things are indeed enum members, and fixing cases where the C version outright ignores return values), I was able to produce a working example:

    // curl-test.zig
    // Direct hand-translation from curl's simple.c example
    usingnamespace @cImport({
        @cInclude("stdio.h");
        @cInclude("curl/curl.h");
    });
    
    pub fn main() anyerror!void {
        var curl = curl_easy_init();
        var res: CURLcode = undefined;
    
        if(curl != null) {
            _ = curl_easy_setopt(curl, CURLoption.CURLOPT_URL,
                                 c"https://example.com");
            _ = curl_easy_setopt(curl, CURLoption.CURLOPT_FOLLOWLOCATION, c_long(1));
    
            res = curl_easy_perform(curl);
        
            if(res != CURLcode.CURLE_OK) {
                _ = fprintf(stderr, c"curl_easy_perform() failed: %s\n",
                            curl_easy_strerror(res));
            }
        
            curl_easy_cleanup(curl);
        }
    }

Buildable with "zig build-exe curl-test.zig --library c --library curl" (I have to add "-isystem /usr/include --library-path /usr/lib64" to the end of that on Slackware64 14.2; YMMV). Should produce a runnable "curl-test" (or "curl-test.exe") binary executable in the current dir.

I didn't try Crystal, but Nim is definitely on par with C.

Actually you can use just plain (stack) objects and ptr object and you have no GC involved.

Pass the flag -d:useMalloc (or just call your preferred allocator) and you have the full C experience and speed.

To be fair, C++ has no ABI, de facto or otherwise. The best way to write C++ that can be called by other languages is with extern "C"

I don't know about Crystal but Nim GC is optional and even on a per-type basis:

Use plain object and you are on the stack Use ptr object and you can use any allocator you want (Nim's default, malloc/free or jemalloc, mimalloc, ...) Use ref object and your reference will be managed by the GC.

In terms of GC, you the default is deferred reference counting (no ref counting if object is created and destroyed at the end of the scope). It accepts real-time and max-pause tunings parameters, to allow it to stay beyond those 60FPS / 144 FPS requirements

You can also choose java-like mark-and-sweep, the Boehm GC, the go GC, or no GC and get a warning everytime you try to use a type that uses the GC.

To be fair, Crystal's release was the same day as Nim!

But yes, now it is Zig's time! I'm happy for all of them.

Seems to be fine on Firefox (both with the mousewheel and arrow keys).