The code example will work even if `u` is only known at runtime. That's because the inner switch is not matching on `u`, it's matching on `ab`, which is known at compile time due to the use of `inline`.
That may be confusing, but basically `inline` is generating different code for the branches .a and .b, so in those cases the value of `ab` is known at compile time. So, the inner switch is running at compile time too. In the .a branch it just turns into a call to handle_a(), and in the .b branch it turns into a call to handle_b().
Agreed. Zig's approach re-uses the existing machinery of the language far more than C++ templates do. Another example of this is that Zig has almost no restrictions on what kinds of values can be `comptime` parameters. In C++, "non-type template parameters" are restricted to a small subset of types (integers, enums, and a few others). Rust's "const generics" are even more restrictive: only integers for now.
In Zig I can pass an entire struct instance full of config values as a single comptime parameter and thread it anywhere in my program. The big difference here is that when you treat compile-time programming as a "special" thing that is supported completely differently in the language, you need to add these features in a painfully piecemeal way. Whereas if it's just re-using the machinery already in place in your language, these restrictions don't exist and your users don't need to look up what values can be comptime values...they're just another kind of thing I pass to functions, so "of course" I can pass a struct instance.
You know, I used to think that design was a nuanced grappling of complex tradeoffs, but you convinced me: those you disagree with are just "brain-dead" "idiots". I think there is a relevant quote by Charles Bukowski about confidence, but it escapes me...
Zig and Go both let you silence the error with `_ = myvar`. It can still be annoying, but it avoids the recursive problem you mentioned. Language design is hard, and it's best to not just assume that people are "idiotic" for not thinking the way you do. Turn the volume down a bit, and maybe find a synonym for "literally" for the sake of variety.
I'm running NixOS + KDE on the AMD framework and surprisingly it worked perfectly out of the box. All I had to do was disable secure boot to get it running, and after install I had to configure the global scale in display settings to 200% so it looked right. No weird hacks needed at all -- the 23.05 installer just worked, including wifi, which apparently isn't true for Windows 11.
The author lost corporate funding recently and is asking for donations. I just started giving 20/mo. I don't care about kernel drama; I just want a good COW filesystem for Linux and this guy is doing a thankless service.
Think about longevity. Whether I'm writing, drawing, making music, or anything else important to my life, will I still be able to view/edit that data in 20 years? Granted, even with offline-friendly software I may need to port it to new platforms and make sure I back up the data, but at least I have a chance. The data I still have from 20 years ago is far more precious to me than I thought it would be back then. Data that can only be accessed through an external party is ephemeral and it will inevitably disappear one day.
Richard is a great contrarian thinker. I remember him from GET LAMP, a documentary about text adventures, and his take on the power of text in games was really memorable: https://www.youtube.com/watch?v=Zctp972y_Eg
I think we will need new standards here, because terminal emulators currently don't have any semantic information about what TUI programs are rendering. Browsers have the benefit of HTML to know this is a button, and that is a paragraph. A terminal is an unstructured grid of characters. The best we can hope for is for terminal emulators to use heuristics or AI to make sense of what TUI programs are rendering.
It doesn't detract from that at all, chief. What a weird thing to say. Particularly in the case of Nim -- it doesn't "throw away" C or C++, it compiles to them!
I believe cyclic imports are coming. And Nim does supports wasm...you can target it with `--cpu:wasm32`. You most likely want to pair that with emscripten as in https://github.com/treeform/nim_emscripten_tutorial
> the big tragedy it's that is focused on freight transport
I don't see the tragedy in that. Tracks in the US are privately owned and freight makes them more money than passenger rail. Don't think we'd gain anything by artifically changing that. Even in Europe planes are usually faster and cheaper than rail when traveling between countries.
That may be confusing, but basically `inline` is generating different code for the branches .a and .b, so in those cases the value of `ab` is known at compile time. So, the inner switch is running at compile time too. In the .a branch it just turns into a call to handle_a(), and in the .b branch it turns into a call to handle_b().