It has stringly typed macros. It's not comparable to Zig's comptime, even if it calls it comptime:

    fn main() {
        comptime {
            var N = 20;
            var fib: long[20];
            fib[0] = (long)0;
            fib[1] = (long)1;
            for var i=2; i<N; i+=1 {
                fib[i] = fib[i-1] + fib[i-2];
            }

            printf("// Generated Fibonacci Sequence\n");
            printf("var fibs: int[%d] = [", N);
            for var i=0; i<N; i+=1 {
                printf("%ld", fib[i]);
                if (i < N-1) printf(", ");
            }
            printf("];\n");
        }

        print "Compile-time generated Fibonacci sequence:\n";
        for i in 0..20 {
            print f"fib[{i}] = {fibs[i]}\n";
        }
    }

It just literally outputs characters, not even tokens like rust's macros, into the compiler's view of the current source file. It has no access to type information, as Zig's does, and can't really be used for any sort of reflection as far as I can tell.

The Zig equivalent of the above comptime block just be:

    const fibs = comptime blk: {
        var f: [20]u64 = undefined;
        f[0] = 0;
        f[1] = 1;
        for (2..f.len) |i| {
            f[i] = f[i-1] + f[i-2];
        }
        break :blk f; 
    };

Notice that there's no code generation step, the value is passed seamlessly from compile time to runtime code.

I wonder, how can a programming language have the productivity of a high-level language ("write like a high-level language"), if it has manual memory management? This just doesn't add up in my view.

I'm writing my own programming language that tries "Write like a high-level language, run like C.", but it does not have manual memory management. It has reference counting with lightweight borrowing for performance sensitive parts: https://github.com/thomasmueller/bau-lang

C is literally a high level language.

Seriously, in the discussion happening in this thread C is clearly not a high-level language in context.

I get your statement and even agree with it in certain contexts. But in a discussion where high-level languages are presumed (in context) to not have memory management, looping constructs are defined over a semantics inferred range of some given types, overloading of functions (maybe even operators), algebraic datatypes, and other functional language mixins: C most certainly IS NOT a high level language.

This is pedantic to the point of being derailing and in some ways seemed geared to end the discussion occurring by sticking a bar in the conversations spokes.

glad you bring up context in this note. i find C high level too but u are right, in a comparisson you can still say its really low level.

C was coined originally as high level because the alternatives were things like assembler. a term rooted in comparisson more than anything.

Thanks, my parent’s comment is almost a thought-terminating cliche in this kind of discussion. However, Chisnall’s now classic ‘C is not a low level language’ article is one of my favorite papers on language theory and potential hardware design. A discussion about the shortcomings of viewing C as a low level language can/could be profitable, deep, and interesting; but context is king.

It has autofree and drop traits.

Nim is a high-level language as well and compiles to C.

Odin and Jai are others.

Vlang compiles to human readable C too, like Nim, not Odin and Jai. Here's a post to read on V's rational for doing so[1]. Incredibly, some vocal competitors mocked V's developers for its decision, then years later, have been quietly trying to copy or "steal" other ideals without giving credit (that they previously made fun of).

V's approach is to have various backends, in addition to native (to be focused on from 0.6); C, JavaScript, WASM, etc...

[1] https://github.com/vlang/v/discussions/7849

Does Odin compile to C? I thought it only uses LLVM as a backend

No, Odin does not compile to C. It is a standalone programming language that compiles directly to machine code. It primarily uses LLVM as its backend for compiling to machine code, like you said.

Same question but for Jai.

Jai does not compile to C. It has a bytecode representation that is used primarily for compile time execution of code, a native backend used mostly for iteration speed and debug builds, and a LLVM target for optimized release builds.

chicken scheme compiles to c as well. it's a pretty convenient compilation target, you get to use all the compilers and tool chains out there and you don't add a dependency on llvm

I love CHICKEN Scheme! Nice to see it mentioned. Though I think it's worth pointing out it compiles to something pretty far from handwritten C, to my understanding. I think this is true of both performance and semantics; for example you can return a pointer to a stack allocated struct from a foreign lambda (this is because chicken's generated C code here doesn't really "return", I think. Not an expert).

Of course you can always drop to manually written C yourself and it's still a fantastic language to interop with C. And CHICKEN 6 (still pre-release) improves upon that! E.g structs and Unions can be returned/passed directly by/to foreign functions, and the new CRUNCH extension/subset is supposed to compile to something quite a bit closer to handwritten C; there are even people experimenting with it on embedded devices.

Chicken indeed interoperates with C quite easily and productively. You're right that the generated C code is mostly incomprehensible to humans, but compiles without difficulty.

The Chicken C API has functions/macros that return values and those that don't return. The former include the fabulous embedded API (crunch is an altogether different beast) which I've used in "mixed language" programming to good effect. In such cases Scheme is rather like the essential "glue" that enables the parts written in other languages to work as a whole.

Of course becoming proficient in Scheme programming takes time and effort. I believe it's true that some brains have an affinity for Lispy languages while others don't. Fortunately, there are many ways to write programs to accomplish a given task.

> this is because chicken's generated C code here doesn't really "return", I think. Not an expert.

not an expert either, but you're right about that, it uses cps transformations so that functions never return. there's a nice write up here: https://wiki.call-cc.org/chicken-compilation-process#a-guide...

I am working on mine as well. I think it is very sane to have some activity in this field. I hope we will have high level easy to write code that is fully optimized with very little effort.

There are going to be lots of languages competing with Rust and Zig. It's a popular, underserved market. They'll all have their unique angle.

I has been served for several decades, however since the late-90's many decided reducing to only C and C++ was the way going forward, now the world is rediscovering it doesn't have to be like that.

Uhm, no? There is barely enough space for Rust, which happens to have a unique feature/value proposition that raises it above the vast majority of its competitors. If you're fine with UB or memory unsafe code, then you go with C simply because its deeply entrenched.

In that sense Zen-C changed too many things at once for no good reason. If it was just C with defer, there would have been an opportunity to include defer in the next release of the C standard.