Get the top HN stories in your inbox every day.
AndyKelley
ksec
Even the about section on Github is "A C compiler written in Zig". This goes against the guideline of Editorialise the headline.
underdeserver
Yep. @dang, per HN guidelines the title should be updated to "A C compiler written in Zig"
wyldfire
Is it intended/desired for Zig to use it in lieu of libclang at some point?
TUSF
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.
fuzztester
thanks for clarifying.
I was wondering why it was under a different github site.
Jarred
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()}`);
import {sqlite3_libversion as version} from "sqlite3.h" with {lib: "sqlite3"};
console.log(`SQLite 3 version: ${version()}`);
WalterBright
With D it is:
import sqlite3;
I've been sometimes pressured to instead use various more complicated syntaxes, but have held the line :-)
WhereIsTheTruth
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;
import c = sqlite3, miniz;grahamjameson
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")
mananaysiempre
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
grahamjameson
[dead]
WalterBright
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
Daunk
D is so underrated. Keep up the good work Walter.
throwaway2037
I am pretty sure that most of the language design is done by Andrei Alexandrescu now.
brabel
Not at all. Walter is the "boss", Andrei left as a leader in May 2019: https://www.youtube.com/watch?v=cpTAtiboIDs&t=3049s
pjmlp
Andrei Alexandrescu is back focusing on C++ at NVIDIA.
nequo
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?
fuzztester
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.
F3nd0
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.
WJW
It doesn't relate to Zig at all, but Walter Bright is the creator of D and tremendously proud of it.
nequo
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.
brabel
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.
WalterBright
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!
wyldfire
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.
o11c
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)
wucke13
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"; }'WhereIsTheTruth
I was about to say this, and DMD compiles C code insanely FAST!
binary132
I would 100% be a D user if it had full C++ typesystem fluency.
WalterBright
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?
binary132
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.
flohofwoe
...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).
fuzztester
Interesting, good to know.
livrem
Is this part of the long-term plan for zig to get rid of the dependency on clang/llvm?
AndyKelley
No. Or rather, only the preprocessor.
Laremere
Yes.
brabel
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.
Laremere
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.
samatman
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...
slowmovintarget
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.
anonymoushn
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.
slowmovintarget
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.
3836293648
That's just wrapping clang. They're working on replacing it
Laremere
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.
6keZbCECT2uB
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.
girvo
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.
fuzztester
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.
Y_Y
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.
MaxBarraclough
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'.
samatman
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.
sirwhinesalot
Very nice, honestly the tooling around Zig is even more impressive than the language itself.
Validark
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.
fuzztester
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.
geodel
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.
lambdaone
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.
samatman
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.
ozgrakkurt
Really want to get into it when reading these posts. Feels like rust killed my casual programming taste in last years.
drannex
Battling the compiler for casual programming is dark souls level dedication, killed my interest to until I started working more in Zig and D.
squarefoot
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.
Drygord
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.
throwawaymaths
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.
geon
On embedded systems you probably shouldn’t allocate at all.
janice1999
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?
hellcow
Zig has a documentation generator that uses specially formatted comments, similar to godoc or JSDoc.
fefe23
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?
defen
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.
jedisct1
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.
ilayn
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.
geon
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?
undefined
gliptic
Zig doesn't (and never will) have operator overloading, so using any user-defined numeric types is awkward. It also already has vector types.
the__alchemist
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?
ilayn
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?
geon
What do you mean with ” float64 is just two float32.”?
Q6T46nT668w6i3m
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.
thegeekpirate
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)
ilayn
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.
flohofwoe
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?
ilayn
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...
flohofwoe
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.
the__alchemist
This is simple to add; struct with two fields, and a handful of methods + operator overloads.
ilayn
Why did not I think of that, shame on me.
dist1ll
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>
defen
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.cGet the top HN stories in your inbox every day.
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!