That's cool. I imagine I could also maintain a MinGW package that can be downloaded through the Zig package manager and statically linked without involving the zig libc? (Such that the user doesn't need to install anything but zig)
That's a good way to sell moving over to the zig build system, and eventually zig the language itself in some real-world scenarios imo.
This is very exciting for zig projects linking C libraries. Though I'm curious about the following case:
Let's say I'm building a C program targeting Windows with MinGW & only using Zig as a cross compiler. Is there a way to still statically link MinGW's libc implementation or does this mean that's going away and I can only statically link ziglibc even if it looks like MinGW from the outside?
I will be even more impressed with linux syscall stability if your implication is that (some) people need to recompile their software for each major update on all other UNIXes.
I'm only thinking in terms of Linux distributions since I never needed to deploy software on other UNIXes (excluding macOS, but Apple constantly forces changes anyway).
Do other UNIXes have any problems similar to glibc ABI problems that Linux users experience, or do they stabilise the libc ABI similar to how Linux keeps syscalls stable?
That doesn't give you independence from the libc, does it? By extension you lose distro-independence too (not sure if Detour supports musl-based ones, need to run tests).
Agree that IPC will be more secure and stable though.
I imagine Detour is mostly targeting closed source projects trying to run on as many distros as possible.
That's only true if you're making CRUD software and easily replaceable by any random programmer. For anything more serious LLMs are only useful as a better search engine.
Keep in mind there _may_ be a negative feedback loop there.
If you're building your software in a way that won't be able to perform better with superior disk/db/network performance, then it isn't worthwhile to ever upgrade to a more performant disk/db/network.
If it is possible, make sure your software will actually be faster on a faster disk rather than just testing on a slow disk and thinking "well we're I/O bound anyway, so no need to improve perf".