this december im doing a "prototype" which means its going to be done in zig and im going to clear sone difficult hurdles i couldn't do last year.... also accepting sponsors, details on page.

also disclaimer, im using heavy amounts of ai assistance (as implied in the preview video)

I mentioned a proof of concept I did that if I had the time to complete/do correctly, it should give you near-rust-level checking on memory safety, plus automatically flags sites where you need to inspect the code. At the point where you are using MIRI, you're already bringing extra stuff into rust, so in practice zig + zig-clr could be the equivalent of the result of "what if you moved borrow checking from rustc into miri"

Happy New Year! 🥳 I'm celebrating the arrival of 2026 in my favorite way: breaking "Hello, World!" again!

For porting Zig 0.14 code to Zig 0.15: what is the correct replacement for `readByte()` on a file/reader, and where is it called from?

const a: u16 = 0;
const b: u32 = 0;
switch (a) {
     @intCast(b) => ..., // теперь работает
}

const Enum = enum(u8) { ... };

const c: Enum = ...;
switch (c) {
    @enumFromInt(0) => ..., // теперь работает
}

const Tot = enum {
    a,
    b,

    pub const c: Tot = .a; 
}

switch (...) {
    .b => ...,
    .c => ...
}

switch (...) {
    .a => |_, tag| {} // теперь можно теги ловить в обычной ветке, не только inline 
}

inline fn pageAllocator() Allocator {
    // In tests we use our testing allocator so we can detect leaks.
    if (builtin.is_test) return std.testing.allocator;

    // On non-macOS we use our standard Zig page allocator.
    if (!builtin.target.os.tag.isDarwin()) return std.heap.page_allocator;

    // On macOS we want to tag our memory so we can assign it to our
    // core terminal usage.
    const mach = @import("../os/mach.zig");
    return mach.taggedPageAllocator(.application_specific_1);
}

hey, not sure if you have heard or not but we've decided to move the next version of Tides from Zig to Jai. Our current release should happen in January I hope, or maybe if I cram it in before the end of the year (mostly a matter of how much polish I want to give it). I can still maintain zflecs, at least for a while (we'll be using flecs in the future as well and I have an interest in keeping tabs on making sure there are no weird language-spanning binding issues 🙂 )

We are still on Zig 0.14.1 though and an older version of zflecs, so I'm not able to actually update zflecs or test PRs anymore, such as this one.

https://github.com/zig-gamedev/zflecs/pull/31

We are using a number of libraries from zig-gamedev so hopefully the Tides repo will remain a useful "how do I actually use zaudio in practice" reference for a good while 🙂

and we have basically come to the realization that Zig isn't great for game development. I mean it's definitely better than C and C++ in various ways, but also not in other ways. At the start it looked like it was going to be more suited for gamedev but it has aligned more with lowlevel/systems programming. So maybe fine for lower level engine programming or libraries, but less so for the more artistic and iterative parts of game development. And now there are two C++ replacement languages that are basically designed for game development - Odin and Jai - and of those Jai speaks more to us. So long term we think it's a choice that will bring us more speed and more joy.