Hacker Newsnew | past | comments | ask | show | jobs | submit | stratts's commentslogin

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.


Exaclty. Play Store takes a cut from what it is selling, so they should be more strict what can be sold, not lock the whole platform.


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).


I guess formal verification tools? That is the peak that even rust is trying to reach with creusot and friends. Ada has support for it using Spark subset [which can use why3 or have you write the proofs in coq] Frama-C exists for C. Astree exists for C++ but i dont think lone developers can access it. But it is used in Boeing.


Comparable to Modula-2 and Object Pascal, hence why those languages ought to do better.

Otherwise it is like getting Modula-2 from 1978, but with C like syntax, because curly bracket must be.


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


It is pretty easy to interface stuff like QuickJS C API. I had a POC here from last year: https://github.com/eknkc/zquickjs

Even this is pretty usable, handling value conversions and such thanks to comptime. (Take a look at the tests here: https://github.com/eknkc/zquickjs/blob/master/src/root.zig)


It's also worth pointing out that the Zig std library covers a lot more than the rust one. No need for things like rustix, rand, hashbrown, and a few others I always have to add whenever I do rust stuff.


You add hashbrown as an explicit dependency? The standard library HashMap is a re-export of hashbrown. Doesn’t it work for you?


Can’t speak for the op but there’s a number of high performance interfaces that avoid redundant computations that are only available directly from hashbrown.


huh, does it? I always add it so I can make non-deterministic hashmaps in rust. oh and you need one more one for the hashing function I think.

But I did not know hashmap re-exported hashbrown, thanks.


Yep, they’re the same since Rust 1.36 (Jul 2019) - https://blog.rust-lang.org/2019/07/04/Rust-1.36.0/


https://doc.rust-lang.org/std/?search=hashbrown

looks like there's no way to access it, outside of hashmap.

Though maybe you just need the third party hasher and you can call with_hasher.

IDK man there's a lot going on with rust.


Yes that’s exactly it. If speed is a priority and the input is trusted, change the hasher to something faster like ahash. The ahash crate makes this easy.


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;


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.


Would you have any tutorial on how to do this? I am unable to get zig .11 to work with the latest raylib without binding libs. I am not sure what all changes I need to make to build.zig


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");
    ...


Thank you. It worked perfectly for me. I was doing most of these but I was messing up the include path. your code samples helped me fix the issues in my build file. Have a great day!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: