> Then why do my data structures detect if I go out of bounds?

Because you have iterator debugging and/or assertions turned on and are only using non-primitive data structures (e.g. std::vector, std::array).

Zig does the thing that Rust and Go do where it makes the primary primitive for pointers to chunks of memory (slices) bounds checked. You can opt out with optimization settings, but I think most programs will build in "safe release" mode unless they're very confident in their test coverage.

It's strictly better than C++, because in practice codebases are passing lots of `(data, len)` params around no matter how strongly you emphasize in your style guide to use `std::span`. The path of least resistance in Zig, including the memory allocator interface, bundles in language-level bounds checking.

>I think most programs will build in "safe release" mode

Do you have any citations to support this 'safe release' theory? Like there are not many Zig applications and not many of them document their decisions. One i could find [1] does not mention safe anywhere.

1. https://ghostty.org/docs/install/build

Ghostty is trying to be a speed demon terminal, so I'd expect it to use ReleaseFast.

The current build system docs don't prioritize one build mode over another:

https://ziglang.org/learn/build-system/

> Standard optimization options allow the person running zig build to select between Debug, ReleaseSafe, ReleaseFast, and ReleaseSmall. By default none of the release options are considered the preferable choice by the build script, and the user must make a decision in order to create a release build.

But for more opinionated recommendations, ReleaseSafe is clearly favored:

https://zig.news/kristoff/how-to-release-your-zig-applicatio...

> ReleaseSafe should be considered the main mode to be used for releases: it applies optimizations but still maintains certain safety checks (eg overflow and array out of bound) that are absolutely worth the overhead when releasing software that deals with tricky sources of input (eg, the internet).

https://zighelp.org/chapter-3/

> Users are recommended to develop their software with runtime safety enabled, despite its small speed disadvantage.

If you could somehow collect real-world data, the overwhelming majority of Zig programs aren't released and have likely only made debug builds :P

Personally, I'd rather prefix with `\\` than have to postfix with `\n`. The `\\` is automatically prepended when I enter a newline in my editor after I start a multiline string, much like editors have done for C-style multiline comments for years.

Snippet from my shader compiler tests (the `\` vs `/` in the paths in params and output is intentional, when compiled it will generate escape errors so I'm prodded to make everything `/`):

    test "shader_root_gen" {
        const expected =
            \\// Generated file!
            \\
            \\pub const @"spriteszzz" = opaque {
            \\    pub const @"quadsprite" = @import("src\spriteszzz/quadsprite.glsl");
            \\};
            \\
            \\pub const @"sprites" = opaque {
            \\    pub const @"universalsprite" = @import("src\sprites/universalsprite.glsl");
            \\};
            \\
            \\pub const @"simpleshader" = @import("src/simpleshader.glsl");
            \\
        ;

        const cmdline =
            \\--prefix src -o testfile.zig src\spriteszzz/quadsprite.glsl src\sprites/universalsprite.glsl src/simpleshader.glsl
        ;

        var args_iter = std.mem.tokenizeScalar(u8, cmdline, ' ');
        const params = try Params.parseFromCmdLineArgs(&args_iter);

        var buffer: [expected.len * 2]u8 = undefined;
        var stream = std.io.fixedBufferStream(buffer[0..]);
        try generateSource(stream.writer().any(), params.input_files.items, params.prefix);
        const actual = stream.getWritten();

        try std.testing.expectEqualSlices(u8, expected, actual);
    }

In the most common cases, Zig does exactly what D does here as well. Constant expressions are folded at compile time like any reasonable systems language. It's akin to writing C++ where you slap constexpr on everything. Zig agrees with D that constexpr is silly :)

The one thing is Zig doesn't have D's notion of function purity, so I suspect there are cases where D could either infer that an expression is const where Zig can't, or at the very least D's compiler could do it faster.

Not to dismiss D's contributions to systems programming languages, of course. Clearly a ton of inspiration of being pulled from y'all's work.

People with secure tech careers in hard-to-break-into-industries get those careers by being able to work for little-to-no-pay due to their privileged upbringing.

This isn't sour grapes, I am one of those people. This program is exactly the sort of thing I would have taken advantage of because I could.

Hooking your students up with companies is a good thing, but companies should expect to compensate people for labor, even for a trial period when it's on the scale of an entire month.

This isn't in Lambda School's direct power to solve, but the real issue here is companies are entirely unwilling to properly mentor new cohorts of engineers. You're expected to graduate from college/trade school a rockstar and start your new job landing PRs in time for the daily deploy. It's bad for the profession.

If your company has the bandwidth to create, manage, and mentor not-real-client-work, surely you have the resources to pay interns.

This page did not automatically flip to dark mode on any of the browsers I use--which all are on dark mode--on my macbook, which is also using dark mode.

Nice article :)

Might be worth touching on error callbacks/logging as an error handling strategy.

Sometimes an error is not recoverable in the sense that the calling code can't really do anything about it, but the library should attempt to make progress anyway instead of halting the entire program.

By allowing users to specify an error callback, this means they can log errors, capture stack traces, assert, or whatever.

This isn't that helpful for smaller libraries with smaller-scoped processes, but if it's something like a renderer or interactive audio lib, those often just need to be given a bunch of frame time to do work with the complex input you've prepped and fed to it, and trying to propagate error codes up out of that simulation step would both contort the inner code and not be as helpful as an error callback.

With an error callback you can assert, set breakpoints, or do whatever. But more importantly, by default you can have it just log so when you inevitably in a bug it doesn't prevent everyone else from getting work done while it keeps asserting until you fix your shit.

This will be a less common need than the other standard error reporting mechanisms, but is important to get right if your library has these complex internal preconditions that you want to make visible to the client when violated.

I like doing that too, but the Zig syntax doesn't prevent that kind of arrangement, just makes it a bit wider.

    return if (value >= radix) error.InvalidChar else
           if (comeCondition)  error.OtherError  else
           ...
                               value;

or maybe this, but it seems uglier to me:

    return if      (value >= radix) error.InvalidChar
           else if (comeCondition)  error.OtherError
           ...
           else                     value;

C#'s new interpolation syntax is a counterexample to your point about easy formatting:

https://msdn.microsoft.com/en-us/library/dn961160.aspx#Ancho...

    $"Name = {name}, hours = {hours:hh}"
    var s = $"hello, {name}"
    System.IFormattable s = $"Hello, {name}"
    System.FormattableString s = $"Hello, {name}"
    $"{person.Name, 20} is {person.Age:D3} year {(p.Age == 1 ? "" : "s")} old."

Isn't edn a data/object format, rather than a markup format? It's like a better JSON.