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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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!
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
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):
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.
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:
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?
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.
>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 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:
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.
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.
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.
> 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.
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).
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.
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!
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.
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.
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.
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.
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()}`);
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.
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 :-)
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 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?
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.
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?
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.
129 comments
[ 2.7 ms ] story [ 189 ms ] threadNote 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.
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.
To be honest PL market feels similar to consumer market where gadgets with myriad smart features sell more than plain but solid machines.
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.
https://ziglang.org/learn/overview/
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.
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.
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/
I guess since you said header, you keep everything opaque and create a header for that which gets translated to Zig.
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.
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/
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):
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).
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.
It would be awesome to have a post explaining how to do that :)
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):
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?
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)
- 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:
What conclusion should we draw about Aro based on what you’re saying?
D would deserve attention too, in a separate post, or here if it was explained how it relates to Aro.
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.
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.
If there's interest, I can give more detail.
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 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
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.
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.
>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.
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.
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.
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.
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!
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.
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.
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.
https://github.com/ziglang/zig/issues/16270
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.
https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen...
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 :/
I was wondering why it was under a different github site.
What is the value proposition of this compiler, then?
Zig helps a lot, but in comparison, Aro is small, and simple to understand and maintain.
- why create a competing front end to Zig?
- what problems is it solving?
- what’s different than the official Zig frontend?
Etc
We embed TinyCC for FFI, but TinyCC doesn't expose a way to read the types for exported symbols.
Currently, it looks like this:
It would be nicer if it was something like this: Would love to use Aro to do this in the future[1] https://repo.or.cz/luajit-2.0.git/blob/HEAD:/src/lj_cparse.c
I've been sometimes pressured to instead use various more complicated syntaxes, but have held the line :-)
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?
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)