In this line a radix sort selects a function to read the next 8 or 16 bits of the input words.
I sort of like that Zig is lazy here, because in C++ a bunch of stuff that works in Zig just doesn't work. Zig is an awesome language, but frankly, I think compiler laziness like this is pretty odd for a statically-typed systems language and not the behavior one would intuitively expect.
This likely means that when conducting large-scale refactors in a Zig codebase, as the amount of potentially broken code increases, the count of hair strands remaining in one’s scalp decreases. This is correct, but to me, the elephant in the room here though is that this makes it much easier to introduce broken technical debt into a codebase. > It's also not nearly as bad as a dynamically typed language: you might have broken code you won't realize until you try to use it, but you'll always realize at compile-time. They’re not perfect, but I think I prefer that instead of relying on laziness. When working at the low level, I like the immediate clarity and compile-time feedback that preprocessor-like checks bring.
I don’t know if I consider this a nice thing when thinking about it from a systems language lens. A nice thing you get in return tho is for separate platforms you can disable code just in the language itself it doesn't need to be a preprocessor or or handled magically in the build system.
0 kommentar(er)
