This has to be some terrible joke. It took 5 days since my video's takedown until I found a way to talk to a human, only for them to drop all accountability.
@TeamYouTube I genuinely no longer feel safe posting on your platform. Do you employ anyone who doesn't follow a script?
@MrWedders I recall some fun times around the 7 era where I would use some repair thing to try and fix my network connection, and it would helpfully inform me "problem detected: you don't have an internet connection", and just sorta leave it at that
@onfiv@typesanitizer@Wire_Daemon As of Zig 0.12.0, comptime call memoization has no meaningful impact on language semantics; it's just an optimization. The reference to memoization in the 0.13 language reference (which you linked in a child comment) is just outdated; thanks for pointing that out! 4/4
@onfiv@typesanitizer@Wire_Daemon "Captures" in this context are values which are defined outside of the type but referenced within it. In the above example, `x` isn't referenced by the `struct` (since there's nothing in the struct declaration!), so the set of captures is always empty, making the types equal. /3
@mitchellh I'll go one further: avoid `else =>` in all switches. It's essentially never a good idea. I fixed some quite nasty bitrot in the compiler recently which was caused by someone optimistically assuming a (256-variant) enum would never change and writing `else => {}`.
@pixqc@archived_videos The slow devloop criticism is valid -- our solution to it is making the compiler speedy! We're getting very close to incremental compilation, meaning the compiler only rebuilds code that changed, turning multiple-second compilations into "updates" on the order of milliseconds.
@owickstrom (I don't personally use ZLS because it chokes on some big files in the compiler itself which is what I'm typically working on, but if you're interested in having a language server that post will probably help you)
@eriklangille This code has a bug! @ alignCast is unsafe; it asserts that the pointer is more aligned than it necessarily is. The correct thing is to use a `*align(1) T`, so the compiler knows the address is not guaranteed to have any alignment. By the way, this is `std.mem.bytesToValue` :^)
@eriklangille Note that it's 8 *words*, not bytes! So, typical (e.g. x86_64) processors have 64-byte cache lines, not 8-byte. Analogously, Apple silicon has 128-bit cache lines.
@nilvoid32@ThePrimeagen The Zig compiler, OTOH, doesn't link to libc, so it has to compile all of the stdlib code to do the printing. It'll also be building the panic and segfault handlers by default, which brings in DWARF parsing! This is a strictly minimal Hello World: https://t.co/G64qLzeKbx [2/2]
@nilvoid32@ThePrimeagen It's worth noting that the Zig compiler is doing quite a bit more work because it's compiling everything, e.g. the actual printing logic, from scratch. C compilers have the advantage of having libc precompiled, so they only have to compile one trivial call. [1/2]
@nilvoid32@ThePrimeagen Assuming you're on x86_64, you can try using our self-hosted code generation backend and linker by passing the options `-fno-llvm -fno-lld` to your `zig build-exe` command. With these, I can compile a Hello World in 0.3s, compared to 1.4s with LLVM. [2/2]
@nilvoid32@ThePrimeagen The reason, in short, is LLVM. When you run your build command, you'll see for most of the duration of the build, it says "LLVM Emit Object". That basically means the time is out of our hands at that point -- we're completely in LLVM code. [1/2]
@felipec@J03daSchm0@ThePrimeagen If you seriously think "Zig's debug binary is less efficient than Clang's release binary" is a reasonable argument, or indeed think that considering any debug binary's performance is helpful, then I'm certainly done here lmfao