stratts's comments

GitHub seems to be the worst of both worlds - partially rendered on the server, but then the frontend inexplicably pulls in additional data like... commit messages??

It's a double hit of latency, and for bonus points, the commit messages won't load at all if your browser is slightly out of date

Android already has this strict oversight, in theory, in the form of the Play Store. And yet.

Personally I feel much more safe and secure downloading a random app from F-Droid, than I do from Google, whose supposed watchful eyes have allowed genuine malware to be distributed unimpeded.

My understanding is that the current plans are to implement async in userspace, as part of a broader IO overhaul.

This would involve removing async/await as keywords from the language.

What's the state of the art here?

Most of Zig's safety, or lack thereof, seems inherent to allowing manual memory management, and at least comparable to its "C replacement" peers (Odin, C3, etc).

Package management in Zig is more manual than Rust, involving fetching the package URL using the CLI, then importing the module in your build script. This has its upsides - you can depend on arbitrary archives, so lots of Zig packages of C libraries are just a build script with a dependency on a unmodified tarball release. But obviously it's a little trickier for beginners.

SDL3 has both a native Zig wrapper: https://github.com/Gota7/zig-sdl3

And a more basic repackaging on the C library/API: https://github.com/castholm/SDL

For QuickJS, the only option is the C API: https://github.com/allyourcodebase/quickjs-ng

Zig makes it really easy to use C packages directly like this, though Zig's types are much more strict so you'll inevitably be doing a lot of casting when interacting with the API

Looks nice! Some thoughts:

  const now = ctx.flag("now", bool); // type-safe flag access

This is type-safe, but only at run time. Since your flags are (or could be) known at compile time, it would be nice to have this throw a compile error if the type is invalid.

Or even better - fully lean into comptime and generate a struct so you can use field access without specifying a type:

  const now = ctx.flag.now;

This is what works for me, assuming an clean project created using 'zig init-exe':

At the top of your build.zig, import the raylib build.zig inside raylib's /src folder (exact path will depend where you've cloned raylib)

  const raySdk = @import("raylib/src/build.zig");

Use the imported addRaylib() function to build raylib, then link to the exe and add include path

  var raylib = raySdk.addRaylib(b, target, optimize, .{});
  exe.addIncludePath(.{ .path = "raylib/src" });
  exe.linkLibrary(raylib);

After that, you should be fine to just use @cImport to use raylib within your project

  const ray = @cImport({
    @cInclude("raylib.h");
  });

  pub fn main() void {
    ray.InitWindow(800, 450, "raylib [core] example - basic window");
    ...

You don't even necessarily need bindings to use Raylib in Zig. It uses Zig's build system so you can just clone Raylib's repo, add a couple of lines to build.zig, and it's ready to go with autocompletion and everything.

Both Raylib and Zig include all dependencies too, so I was able to build a single 700kb .exe from Linux, copy that to my Windows machine, and it just worked immediately without any issues. Pretty amazing.