Davide De Rosa

TL;DR Yes, I rewrote Partout from Swift to Zig with AI.

Moving on While I don’t usually leave my projects incomplete, especially with the finish line in sight (“Architecture” was supposed to be the very last topic), I’m going to end this series a little earlier than planned.

It’s been a while since the announcement of the last post, but I finally found the time to kickstart the last part of this series.

In the previous post, I threw in a few ideas about how to integrate Swift logic with non-Swift code.

We are at a stage where Partout, our cross-platform Swift library: Builds as a static library Emits a Swift module interface for use in other Swift code Comes with a few vendored dependencies as dynamic libraries (OpenSSL, WireGuard) Uses C for low-level…

Since the last article, I’ve made significant progress about improving the build system of Passepartout/Partout and the layout of the outputs.

Our goals Before heading back to the Partout code, let’s focus on our ultimate goals: Build as Swift module on Apple platforms Build as dynamic library on other platforms (.so on Linux/Android, .dll on Windows) Adding that: Step 1 is natural with SwiftPM,…

There is a reason why it took me two months since the last post, and ironically it’s the very subject of this writing.

While I have nothing against “vibe coding” per se, I think it harms software-making in the way too many casual relationships do to the ability to make long-term bonds.

While writing C in a Swift context makes no difference at all, it takes a few tricks to reduce the friction in Swift code that embeds C routines.