Aro – Zig's new C compiler | Hacker News Reader

Aro – Zig's new C compiler

github.com

221 pointswhatever3123 comments

I don't think it's accurate to call it "Zig's". This is an independent project started by Veikka Tuominen, a Zig core team member, but it's not owned or managed by ZSF in any way. It's Veikka's project. Don't take that away from him!

Even the about section on Github is "A C compiler written in Zig". This goes against the guideline of Editorialise the headline.

Yep. @dang, per HN guidelines the title should be updated to "A C compiler written in Zig"

Is it intended/desired for Zig to use it in lieu of libclang at some point?

Yes. In fact, Aro is already in the main Zig compiler's repo, although currently I don't think it actually does any compilation of C (unless you explicitly disable LLVM) and is mostly used for Zig's "translate-c" functionality, last I checked.

thanks for clarifying.

I was wondering why it was under a different github site.

One of the features missing in bun:ffi is inferring types for symbols from header files. This would let you import C libraries in JavaScript/TypeScript directly, without having to configure bindings.

We embed TinyCC for FFI, but TinyCC doesn't expose a way to read the types for exported symbols.

Currently, it looks like this:

      import { dlopen, FFIType, suffix } from "bun:ffi";

      // `suffix` is either "dylib", "so", or "dll" depending on the platform
      // you don't have to use "suffix", it's just there for convenience
      const path = `libsqlite3.${suffix}`;

      const {
        symbols: {
          sqlite3_libversion, // the function to call
        },
      } = dlopen(
        path, // a library name or file path
        {
          sqlite3_libversion: {
            // no arguments, returns a string
            args: [],
            returns: FFIType.cstring,
          },
        },
      );
      console.log(`SQLite 3 version: ${sqlite3_libversion()}`);

It would be nicer if it was something like this:

      import {sqlite3_libversion as version} from "sqlite3.h" with {lib: "sqlite3"};
      console.log(`SQLite 3 version: ${version()}`);

Would love to use Aro to do this in the future

With D it is:

    import sqlite3;

This causes sqlite3.h to be read, lexed, parsed, and semantically analyzed to convert (where possible) C symbols to D symbols, and makes them available to the importer.

I've been sometimes pressured to instead use various more complicated syntaxes, but have held the line :-)

What i like to use is to isolate the imports from C, since they usually come with other definitions wich might clash (already defined error thingy):

    import c = sqlite3;

On that topic, i wish it was possible to group named imports, perhaps this way:

    import c = sqlite3, miniz;

Perhaps a middle-of-the-road approach would be to use inline C like LuaJIT's FFI does? For instance:

  new_clib("/system/lib64/liblog.so", "log")
  ffi.cdef[[int __android_log_print(int priority, const char *tag, const char *msg);]]
  ffi.log.__android_log_print(5, "TEST_TAG", "Hello from FFI")

I can't say I'm familiar with Bun, but I've used a similar syntax to the example you provided of the current Bun syntax when working with Frida (https://frida.re). I agree it leaves something to be desired and indeed it would be cool if Aro could do this in the future.

LuaJIT spends about 2000 lines[1] on its C parser which even includes a limited expression evaluator, though not a preprocessor. My experience suggests explicit memory management could add half again that (LuaJIT’s piggybacks on its GC), and writing one is something like a month of work even if you know exactly what you’re doing (I didn’t), but in any case it’s not a monumental task.

[1] https://repo.or.cz/luajit-2.0.git/blob/HEAD:/src/lj_cparse.c

The dlang D compiler includes a full C compiler, so you can mix and match C and D code. You can import C code from D, and D code from C.

    dmd hello.c
    ./hello
    hello world

This helps enormously in binding to existing C libraries.

D is so underrated. Keep up the good work Walter.

I am pretty sure that most of the language design is done by Andrei Alexandrescu now.

Not at all. Walter is the "boss", Andrei left as a leader in May 2019: https://www.youtube.com/watch?v=cpTAtiboIDs&t=3049s

Andrei Alexandrescu is back focusing on C++ at NVIDIA.

How exactly does this relate to the post, Aro, other than this also being a C compiler? Could you draw a comparison for those who came here for Zig and not D?

What conclusion should we draw about Aro based on what you’re saying?

Jeez!

The post title is "Aro, Zig's new C compiler", not just about Aro or Zig. In fact, just by virtue of being about Aro, it is also about C compilers - as the title clearly says, whether you (pedantically) like it or not. And D is a language that is used as a better C too, apart from other things. In fact, lang C -> lang D, says something significant to this discussion, right?

>Could you draw a comparison for those who came here for Zig and not D?

Sigh.

More pedantic talk.

Shall we start drawing Venn diagrams to clarify things?

Is it not possible that there can be different groups of people, some of whom are interested in Zig, others in Zig and Aro, others in C compilers generally, and others in D with some of those groups overlapping? That's what Venn diagrams are meant to show.

And just by virtue of being about C compilers, it is also about C, thereby making all talk about programming languages on-topic? I see your point about other C compilers being related, but following this line of thought, most any topic could be generalised to whatever you want.

Generally speaking, the more you stray from the most concrete topic at hand (in this case Aro and only Aro), the more it becomes appropriate to explain and elaborate on the relation between that and whatever you've decided to talk about instead. In my view, anyway.

your logic in the first sentence of your first paragraph is quite faulty.

how did you jump from C to all programming languages, in the context of that statement? I did not say anything of the kind.

I can't waste my time explaining things multiple times to different people who don't get it, when others have got it.

maybe check my answers to the other people in this subthread, if you are that interested, for what is such a trivially obvious matter.

good luck.

> how did you jump from C to all programming languages, in the context of that statement? I did not say anything of the kind.

Simply by taking further steps in the same direction. The submission is about Aro, and therefore comments about Aro are on-topic. By your own stated logic, Aro is a C compiler, and therefore comments about other C compilers are also on-topic. One could then go on to say that C compilers in turn pertain to C, and C in turn is a programming language, therefore rendering all comments about programming on-topic under a submission about Aro.

Granted, the example is a bit of a hyperbole, and I doubt anyone would really jump that far. But I find your assertion that a submission about a program (in this instance Aro) renders comments about all other programs of the same kind (in this instance C compilers for other languages) on-topic to be much in the same vein.

> I can't waste my time explaining things multiple times to different people who don't get it, when others have got it.

> maybe check my answers to the other people in this subthread, if you are that interested, for what is such a trivially obvious matter.

I have, of course, read your other comments, but haven’t found anything that would help me understand or accept your argument (assuming that is what I'm supposed to ‘get’). I suppose it's not so ‘trivially obvious’ to me. Don't feel obliged to elaborate any further if you feel that's a waste of your time, though. Good luck!

Seems like multiple instances of either unintentionally poor logic, intentionally fake logic, or just weasel words, on your part, in your above comment that I am replying to.

Here is one, i will not go into others:

>>how did you jump from C to all programming languages, in the context of that statement? I did not say anything of the kind.

>Simply by taking further steps in the same direction.

but i did not ask you to take further steps in the same direction, so that you could twist my words.

i limited myself to C and closely related topics, like D, C++, Walter, and Andrei - related languages and people involved with them.

don't try to twist my words, as you appear to have done above.

yes, once i find people talking fake or not understanding, it is a waste of my time, so i will not engage further with you.

> but i did not ask you to take further steps in the same direction, so that you could twist my words.

I took them to paint an example, so that my argument could be better understood. The example was clearly presented as my own; I have twisted no words of yours from what I can see, and I most certainly wasn't trying to.

> i limited myself to C and closely related topics […]

Yes, while the submission is about Aro, not C, hence the disagreement.

> […] so i will not engage further with you.

Thank you, I suppose.

It doesn't relate to Zig at all, but Walter Bright is the creator of D and tremendously proud of it.

I know that he is but this is incredibly off-topic. Aro deserves the attention it is getting, without the discussion getting hijacked by another project.

D would deserve attention too, in a separate post, or here if it was explained how it relates to Aro.

His post does seem self-promotional I admit but Walter usually shows up in any threads about compilers and usually shares interesting comparisons and contrasts to how his language and compiler handled the issue.

For me, I appreciate the perspective and opinions of someone else in the industry with proven results. D is a major language, you can't deny that.

Maybe this post he should have went into a little more detail but I do not think he posted this with ill intent.

If anything I'm sure he would love to continue a dialog about the design decisions that led him to implement the same feature - and maybe this was his way of starting the conversation.

Given that he is a 15 year member of our community, and has earned 70k karma, we should give him the benefit of the doubt.

> he should have went into a little more detail

If there's interest, I can give more detail.

Walter's comment could be read more charitably and could show his interest in Zig and similar choices that are made.

The last sentence, or, indeed, the whole comment, can be read like "We did this for D, and it works well. [go for it]".

I don't think D is casting any shadow on Zig. Both languages play in the same field, D is older but I feel like we hear about Zig way more these days.

His comment is likely to interest people interested in Zig or PLs in general.

The comment as is might lack some finesse but I don't think it deserves this level of aggressiveness.

I have profound respect for Walter and all his work, same for Andrei; but his comment was off-topic.

>I know that he is but this is incredibly off-topic.

no, it is not. in the fine tradition of hn, let me reply by saying, "that's like, just your opinion, man". which is not worth more than any other people's opinion on this site. maybe worth less.

e.g.:

>D would deserve attention too if ...

so now you are telling everyone what deserves attention?

then what have you done to deserve attention yourself (to your comments, that is)?

walter has done plenty. he created the D language, and still maintains it, along with others, like, you know, Andrei, for one. Google who that is.

Google about Walter to know what other stuff he has done before, like you know, the Zortech C++ compiler.

Let me just say, your comments have not been the most constructive I’ve read.

Sure, I will let you say it :)

Let me say that I think the same about this comment of yours upthread:

>>D would deserve attention too, in a separate post, or here if it was explained how it relates to Aro.

In case you cannot or don't want to google for some reason, here are the Wikipedia articles about D, Walter and Andrei, and important related topics (all on Wikipedia, which implies notability) that I suggested you look up, above:

https://en.m.wikipedia.org/wiki/Walter_Bright

https://en.m.wikipedia.org/wiki/Zortech_C%2B%2B

https://en.m.wikipedia.org/wiki/Empire_(1977_video_game)

https://en.m.wikipedia.org/wiki/D_(programming_language)

https://en.m.wikipedia.org/wiki/Andrei_Alexandrescu

https://en.m.wikipedia.org/wiki/Modern_C%2B%2B_Design

https://en.m.wikipedia.org/wiki/C%2B%2B

Edit: spelling

Sorry, but what does this have to do with Aro?

Sigh.

See here for one way to get it, i.e. someone else's comment on the topic:

https://news.ycombinator.com/item?id=41026310

If that doesn't help, start reading from the start of this subthread that starts with Walter Bright's comment about D, and pay attention throughout, otherwise don't waste your time commenting.

If even that doesn't help, nothing will; sorry, I don't have the time to explain things more than that, for a trivial matter like this.

> sorry, I don't have the time to explain things more than that, for a trivial matter like this.

Au contraire! You're contributed more to this sideshow than anybody: context I was fully aware of when I asked my rhetorical question.

Oh, and you probably know this in the abstract, but your patronizing tone really isn't doing your case any favors here.

>> sorry, I don't have the time to explain things more than that, for a trivial matter like this.

>Au contraire! You're contributed more to this sideshow than anybody: context I was fully aware of when I asked my rhetorical question.

>Au contraire!

Merde! Mon Dieu! Gesundheit! (Hey, Duo, you buggy bro! that's DE, not FR) :)

I can talk fancy French too, with the help of my French mistress, aka Google Translate(ss) :) :

ton discours fantaisiste ne me dérange pas, mon garçon

original in English, by me:

your fancy talk does not faze me, boy

https://translate.google.com/?sl=en&tl=fr&text=your%20fancy%...

>sideshow

if it's a sideshow, why did you participate in it? you are a serious guy, right?

me, I am a dumbass, and just having fun.

>context I was fully aware of when I asked my rhetorical question.

I don't believe it. you are trying to CYA.

but anyway, rhetorical questioners should expect to get any kind of answers, including unexpected ones.

see ya. ciao.

wow, those last two words of mine, they kind of rhyme.

I should take up a career as a poet, since it's already a vocation, after I've spent some of my millions taking a vacation.

signed,

- funster.ai

in Westminster, bye bye.

# everything has to be AI nowadays, otherwise people don't pay attention. that's the usual convention. it's a source of dissension.

He's right, what he's saying is just so obvious it's annoying it has to be said in reply to low effort posts like yours

thanks. you are one of the few people among the commenters who got what I was saying in this thread, I mean. I am sure tons of other sensible people here understood it but did not comment, because it was not worth their time to comment on something so obvious, as you said above, in reply to nequo above.

Is it possible to do what Zig does and cross compile to any OS/arch, from any OS/arch?

Last I tried, I found some compiler options and commands to do it, but they were badly explained, I tried for hours and it just didn't work at all, so I gave up.

The dmd D compiler can cross-compile to any of the targets that it supports. I use it all the time to develop on other platforms.

I am currently adding AArch64 support to DMD's code generator. dmd doesn't run on my Raspberry Pi (yet!), so I use sshfs to access the Pi's filesystem from Ubuntu, compile programs on Ubuntu, transfer the .o file to the Pi, link it on the Pi, and run it on the Pi.

I'm sorry you're having trouble with this, so I recommend posting on the D forums, and people are there to help!

https://forum.dlang.org/

The grandparent post refers to the fact that Zig ships with C, C++ library source that it lazily cross-builds (at least for linux, I don't recall how it solves this problem for macOS or windows). And possibly it uses lld too? Since Zig ships with these, it makes the whole cross-build experience much smoother and less dependent on whether your host OS distribution includes packages for your desired target OS/architecture.

Exactly. Zig tooling includes a linker, and that's also cross-platform. Zig can generate actual runnable executables that run anywhere from a single machine.

As far as I can tell, D's DMD can cross compile but not link. I probably missed that before (actually, I think I was trying with LDC, I found the page where they document the process while searching for it just now: https://wiki.dlang.org/Cross-compiling_with_LDC if you try those options, nothing works, at least from MacOS).

I just tried and this only works with the -c option (compile, but not link):

    dmd -os=linux -c source/app.d

Without `-c`:

``` Error: linker exited with status 1 cc app.o -o app -m64 -Xlinker -no_compact_unwind -L/Users/me/dlang/dmd-2.109.1/osx/bin/../lib -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic -lpthread -lm (dmd-2.109.1) ```

I am sure Walter knows how to compile on one machine, then go to another machine and do the linking or whatever is needed. I know nothing about those, but with Zig I need not know anything other than which flag to use to cross compile. It's a huge difference. D should do that, otherwise it's just not competitive for people like me (I am just an average joe programmer who knows how to write code but has very little interest in learning how linkers work).

> I am sure Walter knows how to compile on one machine, then go to another machine and do the linking or whatever is needed.

Historically, you would or at least could get your compiler and linker from different vendors -- assembler, disassembler and other tools too. So it's normal/common for C compilers like gcc, clang, dmd to not be distributed like Zig is.

But I would dare say that the way Zig is doing it is a great model for others.

> go to another machine and do the linking

BTW - if you use something like debian/ubuntu for development, they have compilers+linkers+binutils for several different architectures available to make cross-building without Zig at least a little bit easier.

FYI, Zig is in the process of dropping dependence on lld on Linux and Windows; macOS uses Zig's own linker since roughly 2021 as far as I recall. Tracking issue for reference: https://github.com/ziglang/zig/issues/8726

A cross-linker would be required for that to work. If you use a cross-linker with D, it should work.

Given Zig has one, it might actually be possible to delegate to that then?

It would be awesome to have a post explaining how to do that :)

The older “cross compiling Go with Zig” post might give a good start if you want to figure it out

I had a look at the post. It only shows how to tell the Go compiler how to use Zig as the C Compiler. In our case, what we need is to tell Zig to link the object files created by D.

I've had a look and saw that Zig is still implementing the `ld` command, but there's already a `ld.ldd` command which might work if you know what magical options to use. I've tried to link my D object file but it can't find a whole lot of generated symbols, and a quick search online does not tell me where do I get those symbols from. That's always what happens when I try to do stuff with D that's not well documented.

I tried this (used the dmd -v option to get the linker command):

    zig ld.lld -L/Users/me/dlang/dmd-2.109.1/osx/bin/../lib  app.o

Output:

```

ld.lld: error: undefined symbol: _d_assert_msg >>> referenced by myd/source/app.d >>> app.o:(_D4core8internal5newaa__T6makeAATAyaTiZQoFNaNeHQoiZSQByQBwQBq7AAShell) >>> referenced by myd/source/app.d >>> app.o:(_D3std6format5write__T14formattedWriteTSQBm5stdio4File17LockingTextWriterTaTS3app__T9StringMapTiZQnZQDaFNfKQCqMxAaQBmZk) >>> referenced by myd/source/app.d >>> app.o:(_D3std6format5write__T14formattedWriteTSQBm5stdio4File17LockingTextWriterTaTS3app__T9StringMapTiZQnZQDaFNfKQCqMxAaQBmZk) >>> referenced 27 more times

ld.lld: error: undefined symbol: _aaLen >>> referenced by myd/source/app.d >>> app.o:(_D4core8internal5newaa__T6makeAATAyaTiZQoFNaNeHQoiZSQByQBwQBq7AAShell) >>> referenced by myd/source/app.d >>> app.o:(_D3std6format8internal5write__T15formatValueImplTSQBw5stdio4File17LockingTextWriterTHiHAyaiTaZQClFNfKQCaQuMKxSQEeQEd4spec__T10FormatSpecTaZQpZv) >>> referenced by myd/source/app.d >>> app.o:(_D3std6format8internal5write__T15formatValueImplTSQBw5stdio4File17LockingTextWriterTHAyaiTaZQCjFNfKQByQsMKxSQEcQEb4spec__T10FormatSpecTaZQpZv)

ld.lld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors)

```

Do you know how to get past that?

I have to confess to mostly just lurking Zig with interest, but not _actually_ knowing what I'm talking about. I do know their linker game has improved a _lot_ since that old Go article, so it's quite likely that Zig can do what you want. You might want to try their IRC or Discord.

Looks like the D runtime library isn't being linked in.

Generally, the hard part isn't the cross compiler (nor, these days, the cross binutils), but the cross libraries. There are at least 3 ways (/usr/lib/$ARCH, /usr/$ARCH/lib, /$CHROOT/usr/lib/) to set up the libraries, all incompatible with each other.

Zig is notable for putting a lot of work into hard-coding basic C libraries, though of course you still need a scattering of other C libraries for most real-world programs.

(for a sufficiently advanced language ecosystem, the language's own libraries should be easy enough)

The nixpkgs have a rather elegant way to deal with that. Let's presume you need a libpng for an armv7 platform, such as an old RaspberryPi. Then Nix allows you to

- get a suitable cross compiler toolchain

- pick whether you want dynamic or static linking (most likely static when the target system does not come with /nix/store)

- compile all prerequisites for the library such as transitive dependencies

- compile the library with the cross compiler for the selected target arch

All in one command line call, that does not require you to 'apt-get install' any of the tools manually:

  nix-build '<nixpkgs>' -A pkgsStatic.libpng --arg crossSystem '{ config = "armv7a-unknown-linux-gnueabihf"; }'

You can combine zig and nix with <https://github.com/Cloudef/zig2nix> (shameless plug)

I was about to say this, and DMD compiles C code insanely FAST!

I would 100% be a D user if it had full C++ typesystem fluency.

D has a lot of compatibility with C++'s type system. But not with everything - for example, D does not have a `volatile` type. What is missing that you're interested in?

I know, and that’s a major selling point for D in my book; iirc it’s what led me to explore D in the first place. Hardly any languages have good C++ interoperability. I was following Calypso with great interest for a while, but sadly it looks like the author lost momentum, so it never got exception handling for MSVC.

What I need to work reliably from C++ are 1. instantiation of imported templates, ideally including CRTP, and 2. handling in D of exceptions thrown from C++, because if I use a C++ library that throws, I need to be able to handle the exception.

So far I’ve found languages that can import template classes and functions from C++ (usually by extending LLVM/Clang), but no languages that have good, reliable cross-platform C++ exception handling.

...I mean Zig has those features too since the beginning with `zig cc`, translate-c and @cImport (currently via an embedded Clang), but the post is about an indepdent C compiler written in Zig (but which will most likely replace Clang as the embedded C frontend once Clang/LLVM isn't compiled into the Zig compiler anymore).

Interesting, good to know.

Is this part of the long-term plan for zig to get rid of the dependency on clang/llvm?

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

No. Or rather, only the preprocessor.

Yes.

Does Zig already compile without LLVM, even if not by default?

Also, do you know when the changes Andrew mentioned in his "Data Oriented Design" are going to be released in the zig compiler?

I would expect that when both of the above are done, compiling Zig will be really, really fast compared to anything we currently have.

The Zig compiler has used Data Oriented Design for a long time, so any recent version has that, yes. The most substantial part of running the compiler right now is LLVM, hence the focus to provide an alternative. The other big focus right now is incremental compilation, which will make recompilations very fast.

The talk I am referring to is from 2024 and shows some metrics improving by 30% or more. And Andrew said that's not yet shipped:

https://www.youtube.com/watch?v=IroPQ150F6c

So, are you sure about that??

EDIT: ok, the talk was uploaded just last week, but someone in the comments clarified that:

> The original talk is from 2021.. Thank you for reuploading.

I feel stupid now :/

Recently Andrew posted that the compiler can compile itself without LLVM in under 10 seconds: https://mastodon.social/@andrewrk/112752924367683101

Don’t

It's the major area of focus right now. You can track the issues with this tag/link if you'd like:

https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen...

I'm not all that familiar with the Zig tool chain.

Am I understanding correctly that this is a regular C compiler used as a component of the Zig compiler chain allowing compilation of C files alongside Zig? Or does Zig generate C and therefore need a C compiler under the hood?

Looking at the documentation suggests it is the former, not the latter.

It says it's a C frontend for `zig translate-c` which translates C code to Zig code. `zig translate-c` is not required for most Zig projects or even for most Zig projects that interop with C.

Thank you.

I also started reading through the Zig overview [1] and near the end of that document it says this: "Not only can Zig compile C code, but there is a very good reason to use Zig as a C compiler: Zig ships with libc."

From the doc, IIUC, compilation of header files and other C code allows Zig to do direct interop with no intermediaries. Seems useful.

[1] https://ziglang.org/learn/overview/

That's just wrapping clang. They're working on replacing it

translate-c is not required for compiling pure Zig code. However, the plan is to remove the "@cImport" built in. So if your project is importing a c header, in the future you'll add build step translating it from c to Zig, and then you import it into your Zig code as a module.

How does this work with things which are expressible only in C? For example, Pascal strings with flexible array members?

I guess since you said header, you keep everything opaque and create a header for that which gets translated to Zig.

It's super exciting. c2nim is one of the things that makes using Nim in _super_ odd places (like professional embedded firmware development) feasible, and translate-c brings Zig that much closer to what I'd love from it! Embedded Zig is going to be rad, once we get there.

what is the reason for this change? zig less than newbie here. I've only just recently started reading the zig overview, although I have been reading hn posts about zig with interest for some time.

Primary reason is that it removes a dependency on libclang, and as such is required to remove the LLVM dependency.

It would be interesting to see how well it optimizes compared to the established players. The fact that it handles C23 and common GNU extensions is already impressive.

I agree it does seem very impressive. My first thought was that they must be using LLVM for the backend, but it looks like no, it's fully 'self-contained'.

Eliminating the dependency on LLVM is a major focus for the language team, and a big part of why Aro exists.

Note that it's the dependency which is being eliminated: it will remain possible to use LLVM as a back end, and to compile Zig and C together without using Aro to translate the C into Zig. If I'm understanding the roadmap correctly, the C headers needed to link a C library with Zig code will be translated into Zig, but doing so with the actual .c files will be optional.

Very nice, honestly the tooling around Zig is even more impressive than the language itself.

The language itself is the reason the tooling exists though, because it attracts a certain kind of developer that probably would not have done the same kind of work for other languages.

what kind of developer is that? interested to know.

I have a lot of prior C usage background, including for nontrivial stuff, including a product, although it has been a while since I used it.

and I am checking out zig as one of my next languages to learn in the C-like / systems programming area.

I think it is logistics, infrastructure oriented vs language feature oriented. Looking at current PL landscape Go, Zig appears to be infrastructure oriented languages where features are just enough to keep infrastructure super fast. Whereas most other languages like Rust, Kotlin and so many more feature oriented if compiler gets fast, runtimes get better its nice but they'd rather work on long list of modern language features.

To be honest PL market feels similar to consumer market where gadgets with myriad smart features sell more than plain but solid machines.

makes sense. not too different from the market for operating systems or enterprise software. both suffer from the same malady. we need a remedy. :)

Zig is amazing. What started as a one-man project is becoming a mature software ecosystem capable of standing on its own as a peer with the major languages.

I'm all-in on Zig, I think it's the bee's knees.

I needed a regex library for another project, and dashed off an acceptable one in a week flat https://github.com/mnemnion/mvzr

The fun part about this is that it can compile, and match, during both comptime and runtime. Will it replace PCRE? No. But nor is it intended to.

Really want to get into it when reading these posts. Feels like rust killed my casual programming taste in last years.

Battling the compiler for casual programming is dark souls level dedication, killed my interest to until I started working more in Zig and D.

It appears to me it could become the low level language of choice for small embedded systems in contexts where Lua or MicroPython couldn't fit the bill performance-wise and one wants something higher level than C. Ditto for Nim and Crystal.

It’s constraints on memory management basically will never allow that to happen.

It lures people in with “use any allocator you want”! Which only appears as freedom of choice when reality it’s locking the user into the same paradigm of memory management that has given C a bad name to begin with.

1/3 of the problem with c memory management is null unsafely, not a problem in zig. 1/3 more is conflating arrays with single item pointers. Also not a problem with zig. The only memory management "issue" with zig is lack of temporal memory safety.

On embedded systems you probably shouldn’t allocate at all.

Why is zig amazing? Could you elaborate a bit

This is a pretty good high level overview:

https://ziglang.org/learn/overview/

I've read it, but didn't catch anything amazing

There's doesn't appear to a whole lot of comments or documentation in the code. Is this normal for Zig projects? Does it have an equivalent of Sphinx to build docs from code?

https://zig.guide/build-system/generating-documentation/

Zig has a documentation generator that uses specially formatted comments, similar to godoc or JSDoc.

Wait, so you still need zig, and zig still needs LLVM. If you have LLVM, you have clang.

What is the value proposition of this compiler, then?

The Zig self-hosted x86 backend is nearly complete (and is already capable of building the Zig compiler itself). So it's part of the path toward not needing LLVM or clang at all.

clang (just the C frontend, not talking about the backend, not clang++) is an old code base. It's become very complicated to understand, maintain and extend.

Zig helps a lot, but in comparison, Aro is small, and simple to understand and maintain.

I hope Zig adds complex numbers before it is too late. It's a pity that they did not steal array syntax and slices from Fortran/Numpy.

Why would complex numbers in particular deserve to be a native type?

What about quaternions, or vectors and matrices of sizes 2-4 at least?

Is there any real advantage over just using a struct?

Would MultiArrayList help with performance for complex numbers and vectors?

Zig doesn't (and never will) have operator overloading, so using any user-defined numeric types is awkward. It also already has vector types.

This is IMO the canonical use case of operator overloads. Are you proposing adding complex numbers to the standard lib to circumvent that restriction, vice addressing it?

Why should complex numbers need justification to be native type? If you need to do serious computation, you need them. If you say Zig is not for number crunching which, say, Java explicitly decided then fine otherwise searching for a reason for complex number tells me that you don't do any numerical programming which is fine but asking for justification makes no sense. Why is any other thing in the language justified? float64 is just two float32. Why stop at float64 why not float128 float256?

What do you mean with ” float64 is just two float32.”?

I don’t think it’s more complicated than people want an abstraction for the complex number instructions you find on processors like the TMS320 series or Qualcomm Hexagon.

Odin makes them (and more!) absolutely lovely to work with:

complex32/64/128, quaternion64/128/256

https://odin-lang.org/docs/overview/#array-programming

https://odin-lang.org/docs/overview/#matrix-type

Probably helps it's the language JangaFX uses for their products used by essentially every major video game, movie, and TV show out there (https://jangafx.com/#headline-603-384)

True, but column-major by default and 1-indexed unfortunately. Still quite nice that they are addressing these challenges head-on early stage unlike other new langs. I guess they had their share the pain like the rest of us.

I'm curious, what use cases do you have for complex numbers that couldn't be provided in a 3rd party library or maybe even the stdlib?

You are essentially necromancing the ISO C99 discussion that happened already. Here is an answer that, after 25 years, is still wrong https://learn.microsoft.com/en-us/cpp/c-runtime-library/comp...

That doesn't tell me much about the usage scenario of complex numbers that would justify adding native support in programming languages. As a sibling comment said, builtin vector and matrix types (up to 4 dimensions) would probably be more useful.

I'll paste the same comment here as I did in the sibling; Why should complex numbers need justification? If you need to do serious computation, you need them. If you say Zig is not for number crunching which Java explicitly decided then fine otherwise searching for a reason for complex number tells me that you don't do any numerical programming which is fine but asking for justification makes no sense. Why is any other thing in the language justified?

This is simple to add; struct with two fields, and a handful of methods + operator overloads.

Why did not I think of that, shame on me.

It seems like I can't include standard header files, so it can't compile a common hello world. I guess that'd be useful to mention on the README, or maybe I'm doing something wrong?

    main.c:1:10: fatal error: 'stdio.h' not found
    #include <stdio.h>

It'd be nice if header inclusion, and -l options work. This would allow benchmarking Aro against some other compilers on a wide range of C files. Usually sqlite3.c is my first go-to for stress-testing C compilers.

System header search paths are only implemented on Linux currently. You should be able to parse sqlite3.c on Linux with

   arocc -fsyntax-only -Wno-unknown-attributes sqlite3.c

I'm primarily interested in full compilation performance, but thanks for the tip!

Very little of the backend appears to be implemented currently.

The ReadMe is quite lacking …

- why create a competing front end to Zig?

- what problems is it solving?

- what’s different than the official Zig frontend?

Etc

A lot of the work happening in Zig includes experiments which may or may not end up kept long term. What this would solve: compile C without requiring LLVM. The plan in the community is to have LLVM as an optional dependency, and not required by default.

Reply on news.ycombinator.com