191–200 of 290 posts
I remain confused about how Zig makes it to the front page of Hacker News so often. As far as I know, no one is using it in production after 7 years of development. Are people just really excited about this project? Are the people behind it just really good at marketing? Honest question: why do we all keep talking about Zig?
But they are boring; nerds like shiny new objects.
Earlier quoted context omitted.
Some CPUs don't have a MUL or (like some 32-bit RISC architectures) DIV instruction, and on these, the C compile has to fall back to a function call.
You sure the compiler doesn't inline it? That an operator might take more than one opcode I think is uncontroversial
https://godbolt.org/z/ccYPaz1Pj
For this example (AVR), this is the int multiply function __mulhi3:
00: 00 24 eor r0, r0
02: 55 27 eor r21, r21
04: 00 c0 rjmp .+0
06: 08 0e add r0, r24
08: 59 1f adc r21, r25
0a: 88 0f add r24, r24
0c: 99 1f adc r25, r25
0e: 00 97 sbiw r24, 0x00
10: 01 f0 breq .+0
12: 76 95 lsr r23
14: 67 95 ror r22
16: 00 f0 brcs .+0
18: 71 05 cpc r23, r1
1a: 01 f4 brne .+0
1c: 80 2d mov r24, r0
1e: 95 2f mov r25, r21
20: 08 95 retI wrote a similar article but focused on how Zig design enable better optimizations than C. https://zig.news/gwenzek/zig-great-design-for-great-optimiza...
I remain confused about how Zig makes it to the front page of Hacker News so often. As far as I know, no one is using it in production after 7 years of development. Are people just really excited about this project? Are the people behind it just really good at marketing? Honest question: why do we all keep talking about Zig?
We do embedded development for medical devices, and zig fits perfectly because we can use static allocators and have all the features of the language.
It works very well, we write firmware for STM32 serie of chips.
We can compile the same code to WASM and run it into a simulator, it works great for us.
Earlier quoted context omitted.
I think that "namespacing" basic types such as u32 is completely unecessary. In what world would an u32_MYLIB would be different than an u32_SOMELIB? Basic types are common enough.
The preprocessor doesn’t know that u32 defined in foo.h is the same type as u32 defined in bar.h. So you’ll get an error when importing both.
Earlier quoted context omitted.
Yep that seems comptime possible but a little heavy handed with string work, no? With everyone writing their own parsers and language tools... In any case, if something practical is done here I'd be interested. Aesthetically I prefer the "vectors and matrices are first class types" (and maybe complex numbers could be too), but I guess Andrew isn't so sympathetic to these types being part of the standard language :/
There's a proposal for complex numbers: https://github.com/ziglang/zig/issues/16278 Vectors are already first-class types via @Vector, aren't they?
Earlier quoted context omitted.
Some CPUs don't have a MUL or (like some 32-bit RISC architectures) DIV instruction, and on these, the C compile has to fall back to a function call.
You sure the compiler doesn't inline it? That an operator might take more than one opcode I think is uncontroversial
Earlier quoted context omitted.
It's true and false at the same time. The operations C gives you map 1-to-1 with assembly. Given some C code you can quite accurately predict which loads/stores will be elided by the compiler and what the resulting assembly will be. I can't name another language for which this is true. I get that you're hinting at the insane level of undefined behaviour enforcement by compilers, but I don't think it matters all that…
> The operations C gives you map 1-to-1 It does not. Implicit casting, inlining, volatile, args passed via registers vs stack etc can significantly change what you expect to be generated.
Earlier quoted context omitted.
The preprocessor doesn’t know that u32 defined in foo.h is the same type as u32 defined in bar.h. So you’ll get an error when importing both.
If C made this change, it could also make it legal to redefine u32 etc as appropriate integer types any number of times without erring.
Tangentially... I'm grateful that these new batches of systems languages have chosen to use the u8, i32, etc, style integer types. Rather than the uint8_t and int32_t style. First thing I do in any of my low level embedded C projects is put in the various uNN/iNN types.
Having spent a lot of time porting 32bit system code to 64bit, I developed a dislike for these explicit types. It's a slippery slope to hard code your bitness with people making assumptions where size_t or pointers fit. Now maybe if you're already 64bit that's fine (it's unlikely that we'll ever need 128bit, and code is unlikely to grow down), but for anything starting smaller it's a pain.
Zig, like Rust, has two kinds of "primitive" numeric types, the kind which are an explicit size in bits (u8, i16, f64 and so on) and then the word size ones (isize, usize), which are whatever size is suitable for your target machine.
C gets this all muddled because it has named primitive numeric types but their meaning is imprecise, and then it uses a typedef to assign one of these (but you don't know which one) as the native word size. So maybe long is the same as your size_t, and C will just assume you know what you're doing when you write a long where you need a size_t - thus making your code non-portable.