If you still MUST build X11 for some reason, then you NEED their special build system as well! That's right: X11 has it's own build system, it's not Gnu configure & make, it's not cmake or any of the more common once like meson or ninja, it's called IMake & years ago the last time I had to build Xorg myself it couldn't readily use anything else meaning X11 is tied toward IMake's build system (which, to my knowledge, is as ancient as X11 & no other software uses it anymore). So, another crufty old piece of software requires yet another crufty old build system. :| Update: it seems X11 has since switched to Gnu autoconf & make - I can't confirm whether that actually works now because last time I tried it didn't. Supposedly they at least they plan of using meson in the future.
Thanks very interesting (for a non-Zig guy). I loved the way you deconstruct the can of worms called `libc` family. Regarding building and running Bash on Windows. My guess is that usually the biggest issue with this task would be to implement `fork()` in the sane way. Cygwin failed to do this efficiently (at least in the past). And as of latest fork-on-Win32 implementations, I heard of the only one project achieving success here - it's called Midipix. So I'd say that a nicer way on Windows would be to get the Midipix running and link to it instead:). My 2€c.
What would even be the requirements for Fork on Windows? Duplicating the address space, loaded modules, and memory contents is straightforward enough, but then you need to deal with Handles. File handles, Window handles, literally every handle. At the very minimum, calling DuplicateHandle (which increases the reference count) on every single handle from that the process. I'm not even sure if handles will work if you try to use them from another process.
@@Dwedit: I seemingly wrote a comment, but I cannot find it here anymore. So I will try to recreate the idea. I am no expert in this area, but I saw a few interesting threads in some discusion on Hacker News like 6y ago. You can still find it by googling these four keywords: midipix sfu interix ycombinator
This is another comment from the "please, please, please make an efficient implementation of my bad software habit" crowd. Dude... fork() is an insanity by principle. It does, of course, have useful applications... in cases in which absolutely nothing depends on the correct performance of your software, so if you are into prime number search, then fork() is your friend. In all other cases... just don't. I am serious. DO NOT USE fork(), EVER! :-)
@@lepidoptera9337 : I agree at least partially. There are even M$ paper called "A fork() in the road" that seconds you. And here I stress not on creating new software that will use fork(), but rather more on running / interfacing an old software that _still_ uses fork() in their model / interfaces.
Neat story at the beginning, but if you need to have a shim that requires root privileges in the first place just make naitive packages? There are projects that help you package for all major distros. Flatpak is cool and all but using flatpak for this is just making problems for yourself.
39:50 how about you try to build a linux kernel? Now why did I ask this? Was I trolling? NO! I was trying to indirectly point out that the problem rarely is compiler or library support but rather build & configuration systems' support - or in other words: if you guys are serious of wanting to use zig cc to build more already existing C software, then consider writing how to integrate it nicely with build & configure systems. A few common examples: -Gnu autoconf & automake -meson -ninja -CMake -use as Linux distros default compiler (RedHat/Fedora, Debian/Ubuntu, Arch, Gentoo... all have ways of specifying a different default C compiler with different options at each individual package but also globally at the system configuration level - documentation of these exist online, they just need someone writing how to's for zig cc or any other compiler) -& yes, linux kernel is at last relevant because it also does use a cutom configure system.
I am very impressed! I do however have one concern, which is the ABI on platforms like Windows and MacOS. From what I remember, their system call interfaces are undocumented and unstable, so programs are _heavily_ encouraged to use the platform provided libcs. If I recall correctly, Go ran into some trouble when trying to bypass the libc on a particular platform and use the system calls directly, even if they weren't trying for a full libc themselves. On Linux, the system call interface does seem to be stable allowing for this kind of thing to work, but that seems to be the exception rather than the rule. At least on Linux though, love it! It feels a little like cheating that you can just use the standard library's malloc, but since Zig already didn't use libc's malloc, you could get away with it. I'm curious if I can setup Nix to use zig cc and ziglibc as compilers, and then see how much of nixpkgs can actually be built like that.
No idea about Mac, but on Windows you can use the raw Win32 API (which is stable) to implement the libc. You don’t have to use the raw syscalls, or the the syscall wrappers from NtDll, since they are generally unstable as you stated. For example the WriteFile() function belongs to Kernel32.dll (i.e. not a libc) and it could be used to implement fwrite().
The zig standard library already uses system calls directly, without going through libc where possible, to implement its basic features across operating systems. All that code is already written. The point is to implement a libc in terms of zig's std, to provide a libc (owned by the zig project) for programs that need it.
@@doublex85 My point is that while that's perfectly fine on Linux, Mac and Windows are another story where their syscall interface is undocumented and unstable. The only officially supported way to communicate with the kernel is through the provided libc. My question was how Zig plans to resolve this issue. As I mentioned in my original comment, Go's standard library also invoked the syscalls directly, and then had programs break suddenly when one of the platforms made a backwards incompatible change to their syscall interface without warning. They have since switched to invoking the system's libc on non-Linux systems to avoid this issue in the future.
@@lepidoptera9337eh? Not sure what you're getting at but sanitizing libc would definitely be helpful towards that goal. It's clearly a feature that would come with a lot of caveats, like you'd have to run on compliant enough hardware, that's able to set rounding modes etc. as required, but the math.h functions are definitely one of the bigger barriers to FP determinism. There's also the bigger caveat that you couldn't call into any libraries or services that don't share your blessed libc, but that's also going to be true for e.g. mallloc/free so you'd better already be thinking hard about that...
ZIG! But how Assembly efficient really is? I think Bun(JavaScript) uses Zig on the backend, that's why Bun is so fast, finally, speed is here, as computers should run
Dont be silly bro, node is c++ and deno is rust - are those fast languages? Yes. Is zig? Yes. Is Javascript? No. They’re all slow. I encourage you to go run a few benchmarks, there’s still no clear winner outside of deno / bun being objectively better than node simply by not having all the baggage of npm.
@@pookiepats The benches are in, long ago: the creator of Bun gave stats on Twitter/X and speed up JS 10x or more. Rus is slow, C++ used to be fast. You need to update your stats. The other app are slow, 'coz they don't use Zig
@@homelessrobot no. ai- driven development. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-eaedq1Jl2fc.html its obviously not ready yet, but its coming. and thats because C is everywhere. EDIT: (clarif: c wont be replaced anytime soon bc its everywhere) including cuda or opencl. so youre not getting rid of C otherwise. EDIT: (clarif: youre not getting rid of C if its not with ai-driven development)
@@aaaowski7048 yes, well, none of this is actually to the end of getting rid of c. its to the end of taking responsibility for as much as possible within the zig project itself, in zig. If zig is 'trying to get rid' of anything, its more something like c++, not c. To the point about AI driven development; this is orthogonal to the general utility of something like c, or zig, or c++. You may get more done with ai driven development, but you don't have more control. I don't see how AI driven development has anything much at all to do with it.
25:26 - Roll your own libc. That's always a Good Idea. Another pro is that you don't have to rely on sh!tty existing libc code. You touched on this a little by talking about goal alignment/prog-specific config, but some of the libc implementations have really garbage, bloated code in them, and you avoid that outright. C Compiler writers are pretty horrible to begin with, and they really muck up libc... My only hope is that ziglibc doesn't make the same mistakes, which would erase my above pro.
What in the world makes you think that your personal libc is better than the average libc? That is an argument from delusions of grandeur about yourself. ;-)
Zig has promise but stop with the C replacement talk (i.e. the title). It’s unnecessarily corny marketing y’all don’t need - ya ain’t replacing C, C is still improving - just my opinion but if I had a flagship app like Tigerbeetle as a notch on my languages belt I would not bother with ridiculous antics that will likely never come true or are decades away.
