I don't think you can draw the conclusion that source length and binary size are correlated. For example, in Rust:

    #[derive(Copy, Clone)]
    enum Expr {
        Int(i32),
        Add(i32, i32),
        Neg(i32),
    }
    
    fn eval(expr: Expr) -> i32 {
        match expr {
            Expr::Int(x) => x,
            Expr::Add(a, b) => a + b,
            Expr::Neg(x) => -x,
        }
    }

    #include <stdint.h>
    
    typedef enum {
        EXPR_INT,
        EXPR_ADD,
        EXPR_NEG,
    } ExprTag;
    
    typedef struct {
        ExprTag tag;
        union {
            struct {
                int32_t value;
            } Int;
    
            struct {
                int32_t left;
                int32_t right;
            } Add;
    
            struct {
                int32_t value;
            } Neg;
        };
    } Expr;
    
    int32_t eval(Expr expr) {
        switch (expr.tag) {
            case EXPR_INT:
                return expr.Int.value;
    
            case EXPR_ADD:
                return expr.Add.left + expr.Add.right;
    
            case EXPR_NEG:
                return -expr.Neg.value;
        }
    
        __builtin_unreachable();
    }

Fair point, I phrased that too broadly, and you are right about the loose correlation.

What I was gesturing at, badly, was more that Zig’s low-abstraction / explicit-by-default syntax tends to have you write more boilerplate-y code in general that are more annoying to write and maintain, while not buying you enough over a language with better tooling and ecosystem and compiler optimization like Rust.

Why? Python is terse but has large binaries because of the runtime overhead. C++ is fairly verbose but can make useful binaries in double digit kib.

I have found LLMs struggle with Rust's constraints - they are optimized to produce code that passes the tests, not necessarily good code. So instead of working out lifetimes and borrowing, it will be happy to copy a buffer many times without thought. This means I have to still go through line by line to review and often rewrite either by hand or with another LLM iteration.

There may be some prompting that can help with this but I suspect there is a fundamental tension between writing working code vs good code in LLMs. Go is popular for being simple, making it easy to jump in and write something fast and stable - minimizing the gap between working and good code probably helps out the LLMs a lot.

I don’t feel the verbosity with Rust. Haven’t written it in a while but now in the LLM era I’m looking forward to saying “sort out the lifetime errors for me”.

Agree. But just because it feels the same doesn’t mean it compiles the same.

That can often depend on how you write it.

> Rust is (mostly) safer and more succinct than Zig while being dramatically less ergonomic

This is just your opinion.