Please don't use js in medical devices.

attempt at humor:Okay so, would you rather your beloved great aunt's pacemaker fail because the software in it was written in C, and there's a use-after-free memory error, or because the software in it was written in JavaScript, and because someone used `==` instead of `===` a boolean that should have been `false` is `true`?

As a professional C programmer, the answer seems to be no; they are not good enough.

They are absolutely good at reviewing C code. To catch stupid bugs and such. Great for pair programming type use.

This is a good advice. That said, I don't think you should care about people that comments on articles without reading them.

> they do it using either a parallel functional language or a parallel library in modern C++.

IMO this is a weakness not a strength. The approach of Fleury (low level C, no lib), makes his articles a lot more valuable for understanding fundamentals.

This is exactly what the article is trying to debunk.

I can't wait for the SD25 videos!

Thanks, same! :)

Great work on the self-hosted (no llvm) compiler and linker !

Is there somebody that can explain to me the value of incremental compilation?

How is this different than CMake caching, for example?

My understanding is that Zig's incremental compilation will work on a much more granular level (i.e. functions, etc), so, for example, change one function and only that function (and its dependencies) will get recompiled/relinked (there's some linker trickery involved to avoid needing to relink everything IIUC).

More details here: https://ziggit.dev/t/how-zig-incremental-compilation-is-impl...

Why would the function's dependencies need recompilation? I guess the dependees may require it, if they inlined it, or if the signature changed.

I'm probably not describing it fully accurately. See the link for the proper explanation.

Thanks for sharing !

This is great. It really showcases zig's dedication to quality, IMO.

I wish they took the time to communicate the intricacies of their toolchain.

Some things I think are remarkable:

Contrary to Rust, zig allows to cross-compile to MacOS. I think this implies that zig needed to build a custom linker!

Regarding libc:

- On Linux libc is not required because zig is using syscalls directly

- On MacOS libc is required because of the lack of stable abi

- On Windows libc is not required because zig links to windows kernel dll.

To my understanding, this implies that a compiled zig program will work across all linux distributions!

For C integration, I'm not knowledgeable enough to fully appreciate the work being done. but the fact that the cross-compiling also works out-of-box is mind-blowing to me.

This is great. It really showcases zig's dedication to quality, IMO. I wish they took the time to communicate the intricacies of their toolchain.

Some things I think are remarkable:

Contrary to Rust, zig allows to cross-compile to MacOS. I think this implies that zig needed to build a custom linker!

Regarding libc:

- On Linux libc is not required because zig is using syscalls directly - On MacOS libc is required because of the lack of stable abi - On Windows libc is not required because zig links to windows kernel dll.

To my understanding, this implies that a compiled zig program will work across all linux distributions!

For C integration, I'm not knowledgeable enough to fully appreciate the work being done. but the fact that the cross-compiling also works out-of-box is mind-blowing to me.

I don't know why my comment was duplicated. My appology.

Is there a video of the talk somewhere ?

I prefer recording over slides.

Unfortunately no, I've only done it as a private event within a company so far.