dmd VS zig

>For me the biggest gap in programming languages is a rust like language with a garbage collector, instead of a borrow checker.

I cannot agree more that's the much needed sweet spot/Goldilock/etc. Personally I have been advocating this approach for some times. Apparently the language is already widely available and currently has stable and wide compiler support including the venerable GNU compiler suite (GDC). It also one of the fastest, if not the fastest programming in existence for both compilation and execution [1].

It has been beating Fortran in its number crunching territory, no small feat given the Fortran pedigree with many languages still depending on Fortran based infrastructure for their number crunching capabilities including Matlab, Julia, Rust, Go, C, C++, etc.

[1] D website:

https://dlang.org/

[2] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen:

http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

> you've written an an ARM disassembler

Here's my AArch64 disassembler work in progress:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/ba...

I add to it in tandem with writing the code generator. It helps flush out bugs in both by doing this. I.e. generate the instruction, the disassemble it and compare with what I thought it should be.

It's quite a bit more complicated than the corresponding x86 disassembler:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/ba...

Here's the pipeline spitting out the same error as on my macbook did.

https://github.com/dlang/dmd/actions/runs/8023469412/job/219...

Here is, I think, an interesting example of the kind of thing TFA is talking about. In case you’re not already familiar, there’s an issue that game devs sometimes struggle with, where, in C/C++, an Array of Structs (AoS) has a nicer syntactic representation in the language and is easier to work with/avoid leaks, but a Struct of Arrays (SoA) has a more compact layout in memory and better performance.

Zig has a library to that allows you to have an AoS that is laid out in memory like a SoA: https://zig.news/kristoff/struct-of-arrays-soa-in-zig-easy-i... . If you read the implementation (https://github.com/ziglang/zig/blob/master/lib/std/multi_arr...) the SoA is an elaborately specialized type, parameterized on a struct type that it introspects at compile time.

It’s neat because one might reach for macros for this sort of the thing (and I’d expect the implementation to be quite complex, if it’s even possible) but the details of Zig’s comptime—you can inspect the fields of the type parameter struct, and the result SoA can be flexible in the number and type of its own fields—mean that you don’t need a macro system, and the Zig implementation is actually simpler than a macro approach probably would be.

(sorry for the slow reply!)

Two points here:

Linked lists are useful in unsafe code. Most recent use case I had for them was in an event loop with coroutines. It's not possible to implement such thing in memory safe languages. For example if you use Rust, you have to use unsafe [1].

@fieldParentPtr does not yet have safety but it is a planned upcoming change to the language, with a fairly straightforward implementation [2].

[1]: https://github.com/search?q=repo%3Atokio-rs%2Ftokio%20unsafe...

[2]: https://github.com/ziglang/zig/issues/2414

Generally I also find Zig's documentation pretty lacking, instead I try looking for the relevant issues/prs. In this case I found comments on this issues [1] which seem to still hold true. That same issue also links to the relevant LLVM/Clang issue [2], and the same restriction is also being proposed for Rust [3]. This is were I first learned about it and prompted me to investigate whether Zig also suffers from the same issue.

[1]: https://github.com/ziglang/zig/issues/694#issuecomment-15674...

One thing I'm super excited about here is that Zig can now cross-compile CGO to macOS [0], granted you link the appropriate macOS frameworks and SDK [1].

[0]: https://github.com/ziglang/zig/issues/20689, https://github.com/ziglang/zig/issues/21721

[1]: https://github.com/tpoechtrager/osxcross

> Chose boring technology. I genuinely find myself picking libraries that have been around for a while partly because that way it’s much more likely that LLMs will be able to use them.

This is an appeal against innovation.

> I’ll finish this rant with a related observation: I keep seeing people say “if I have to review every line of code an LLM writes, it would have been faster to write it myself!”

> Those people are loudly declaring that they have under-invested in the crucial skills of reading, understanding and reviewing code written by other people. I suggest getting some more practice in. Reviewing code written for you by LLMs is a great way to do that.

As someone who has spent [an incredible amount of time reviewing other people's code](https://github.com/ziglang/zig/pulls?q=is%3Apr+is%3Aclosed), my perspective is that reviewing code is fundamentally slower than writing it oneself. The purpose of reviewing code is mentorship, investing in the community, and building trust, so that those reviewees can become autonomous and eventually help out with reviewing.

You get none of that from reviewing code generated by an LLM.

But the situation for Rust-C++ interop is also worse than for Rust-C interop. Why else would Google spend maybe $1 million on improving it in 2024? https://www.theregister.com/2024/02/05/google_rust_donation/ Many years after Rust got support in Mozilla for usage with Firefox written in C++.

>My sibling is also correct, language decisions were made in order to keep FFI zero overhead.

Yet overhead is only one piece of the puzzle for FFI and interop with C, or for that matter, C++.

How does Rust compare with a language with less advanced and more simple semantics and requirements of invariants, like Zig?

https://ziglang.org/

>Incrementally improve your C/C++/Zig codebase.