Very weird comparison.

GPL was made in response to restrictive commercial licensing. Yes is uses the same legal document (a license): but is made in response!

So is propriety seizes to exist, then it's not a problem GPL also seizes to exist.

Also: it's quite obvious to me that IP-law nowadays too much. It may have been a good idea at first, but now it's a monster (and people seem to die because of it: Aaron Swartz and Suchir Balaji come to mind).

I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different.

Zig OTOH is clearly, to me at least (opinion alert), a "better C". It even compiles C!

I expect LLMs to be really good at converting C to Zig.

> There is also the issue of will people actually code by then.

LLMs don't take responsibility. So even if code is generated, a human will have to assess it. I think assessing Zig is easier than assessing C, which gives this language a selling point that holds out in the AI assisted programming future.

I've been coding in Zig for nearly 2 months straight now.

Or should I say, I've not written a single line of Zig because I've been managing AI's coding in Zig.

Turns out Zig is a fantastic language to "centaur" on. (Reference is to "centaur chess" and which is also sort of becoming a term indicating close code design cooperation with an LLM.)

All of that C code that the LLM trained on ends up helping it work out algorithms in Zig, except that Zig has waaaay more safety guarantees and checks. And is often faster compiled code than the equivalent C, which is astonishing.

> I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different.

The same can be said about Zig's comptime. It's entirely unlike anything C, C++ or Rust has to offer.

> I expect LLMs to be really good at converting C to Zig.

While it's possible to translate C to Zig code - and you don't need an LLM for that, it's a Zig compiler/build-system feature - the result will be quite different from a project that's developed in Zig from the ground up since the translation output wouldn't make use of Zig's unique features (and Zig isn't really unique as 'C translation target', C can also be translated to unsafe Rust, or even to Javascript - see early Emscripten versions).

Also, the 'C compatibility' of Zig is implemented via a separate compiler frontend, Rust toolchains could do exactly the same thing by integrating the Clang frontend into the Rust compiler.

Using the same language for compile-time and run-time programming is compelling, but doing it properly requires using the same approaches that dependently typed languages use. Comptime is a bit half baked.

It's not just about writing imperative code that runs at compile time, the actual interesting comptime feature in Zig is that "types are comptime values", e.g. you can inspect types and build new types with regular (comptime) code. This is very different from the template/trait systems in C++ and Rust. What Zig's comptime system is missing is the ability to build functions bodies at comptime (e.g. some sort of comptime AST builder).

"You can inspect types and build new types at compile time" is a key affordance of dependently typed languages.

Zig's comptime is an addition. You don't have to use it. And some C-macros may translate quite cleanly to it.

OTOH going from C++ (OO) to Rust (not OO, borrow checker) is a big leap.

Not all C++ is OOP, and Rust does support OOP as per CS literature, so much so that I have had no issues rewriting Raytracing Weekend tutorial from C++ into Rust, while keeping the same OOP architecture from the tutorial.

And that's OpenAI's biz model? :)

Nice one!

I'm on a similar stack: http4k + Jdbi, nicely glued up :)

No coroutines so cute little stacktraces

Here I'm using coroutines + context-parameters. I find much more convenient when I explicitly handle db transactions with context-parameters. Also, using arrow's Raise context adds typed error handling, without too dsl usage.

Any place I can see an example of that? (just a gist or pastebin entry of some a non-critical code copy-pasta would suffice)

I prefer bit more type-safety. JVM/Kotlin/Jdbi + PG for me.

No more ORMs, not even query builders, ... When it comes to Postgres I want to write the sql myself! There is so much value.

Supabase helps when building a webapp. But Postgres is the powerhouse.

Super cool project.

I expect a lot of C code may be quite mechanically translated to Zig (by help of LLMs). Unlike C->Rust or C->C++, where there's more of a paradigm shift.

There's solid reason for the translation here; the Zig core team is aiming to eliminate duplicated code and C functions, and avoid the need to track libc from multiple sources. In the future, LLMs could serve as part of this, but they are currently quite terrible at Zig (as far as I understand it, it's not a lack of Zig code samples, it's an imbalance of OLD Zig to NEW Zig, as Zig changes quite frequently).

You would need to consider if it is even worth it translating your C code. If the paradigm is identical and the entire purpose would be "haha it is now one language," surely you could just compile and link the C code with libzigc... In my opinion, it's not worth translating code if the benefit of "hey look one language" requires the cost of "let's pray the LLM didn't hallucinate or make a mistake while translating the code."

> they are currently quite terrible at Zig

hard disagree (example elsewhere)

absorb or create?

i understand it as: absorbing is in the intestine, generating D happens in the skin when exposed to the sun

Correct, what I meant was absorbing UV light, that then as you state creates D.

And you got Bitwig :)