Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Failing to Learn Zig via Advent of Code

forrestthewoods.com

Post reply on HN
Print view View original

181–190 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#181

Post by yjftsjthsd-h »

socialdemocrat wrote: post #109

Zig is a very low level language. I think the fancy type system can trip up people into thinking they are working with a high-level language. Zig is basically C with a fancy type system, so you should not expect things like special String types, overloading of index based access etc. I think the author was thinking that Zig was very close to Rust or C++, when in reality it is much closer to C. I had to keep reminding…

> Zig is basically C with a fancy type system, so you should not expect things like special String types,

If I can't have nice strings, what should I be expecting from a fancy type system?

Re: Failing to Learn Zig via Advent of Code

#182

Post by rak1507 »

user-the-name wrote: post #44
rak1507 wrote: post #16

Earlier quoted context omitted.

I think there's a compromise between being recognisable as a mathematical formula and removing operator precedence which is what APL and other array languages do. (a×1-t)+b×t is how you'd write it in APL, no operator precedence but still more familiar.

That absolutely breaks the law of least astonishment. It's worse to look familiar but have hidden differences than to just look completely different.

Yeah maybe, but in my opinion it's better than the alternative (having loads of operator precedence rules that can change subtly between languages and never really being sure of anything).

Re: Failing to Learn Zig via Advent of Code

#183

Post by Comevius »

jolux wrote: post #152

To me the biggest difference between Rust and Zig in practical terms is that Zig does not offer statically safe resource management like Rust does, and as far as I know they have no intentions of doing so in the future because they think it’s less important than all this stuff about control flow. There are a lot of interesting ideas in the language but my disagreement with them on this issue is so fundamental that I…

There is nothing fundamental about ownership-based resource management, memory-safety can be achieved in other ways. Zig is C, it's not meant to abstract away memory management. You can do whatever in Zig, write a specialized allocator that's verified to be correct, even for a microcontroller with 2 KiB memory. Zig is a machine-oriented language, which means no hidden control flow, no hidden allocation. You can write a garbage collector or a compiler like Rust has too if that's what you need.

Re: Failing to Learn Zig via Advent of Code

#184

Post by pjmlp »

jolux wrote: post #152

To me the biggest difference between Rust and Zig in practical terms is that Zig does not offer statically safe resource management like Rust does, and as far as I know they have no intentions of doing so in the future because they think it’s less important than all this stuff about control flow. There are a lot of interesting ideas in the language but my disagreement with them on this issue is so fundamental that I…

In terms of safety in systems programming, Zig is hardly better than something like Modula-2 or Object Pascal.

It just happens to have a better syntax for the C crowd.

Re: Failing to Learn Zig via Advent of Code

#185

Post by pjmlp »

Comevius wrote: post #183
jolux wrote: post #152

To me the biggest difference between Rust and Zig in practical terms is that Zig does not offer statically safe resource management like Rust does, and as far as I know they have no intentions of doing so in the future because they think it’s less important than all this stuff about control flow. There are a lot of interesting ideas in the language but my disagreement with them on this issue is so fundamental that I…

There is nothing fundamental about ownership-based resource management, memory-safety can be achieved in other ways. Zig is C, it's not meant to abstract away memory management. You can do whatever in Zig, write a specialized allocator that's verified to be correct, even for a microcontroller with 2 KiB memory. Zig is a machine-oriented language, which means no hidden control flow, no hidden allocation. You can write…

Thing is, if Zig is C, why bother at all, we already have C for it.

Re: Failing to Learn Zig via Advent of Code

#186

Post by pjmlp »

mst wrote: post #172
messe wrote: post #135

Earlier quoted context omitted.

One example would be an architecture on which hardware floating point is not implemented, and has to be emulated in software. This isn't uncommon in embedded, many ARM Cortex-M cores are like this AFAIK.

When I was writing arm26 (i.e. arm2) assembly for the Archimedes everybody passed around a block of ASM that did division since the processor had a whole 16 instructions and integer division wasn't one of them. Things are less primitive these days but the memory still brings a smile to my face.

MIPS was also like that, if I remember correctly, division and multiplication were assembler macros.

Re: Failing to Learn Zig via Advent of Code

#188

Post by elteto »

dagmx wrote: post #146
klyrs wrote: post #127

Earlier quoted context omitted.

Quite the opposite. The very broad-brush overview is that zig aims to replace C and rust aims to replace C++... but among other issues with that analogy, that can't happen unless zig and rust have a dead-simple integration story.

I've only ever really seen it in Zig communities that Rust is closer to C++ In Rust communities, it's often pitched as alternates to both, but closer to C. I suppose it's all relative, but the comparison of rust to c++ seems external

I think it is a C++ replacement that is _closer_ to C. It has generics, traits, RAII, etc, which are C++, not C, features but the way that Rust implements them _feels_ closer to C. I don't know if this quite makes sense but as an external observer this is my impression.

Re: Failing to Learn Zig via Advent of Code

#189

Post by meheleventyone »

cbdumas wrote: post #143
defen wrote: post #136

The author is not excited about "No hidden control flow", but as a code reader it's really nice. It means that the only context you need in order to understand the control flow of a given line of code is that line itself. You don't need to check for overloaded operators, exceptions, virtual functions, etc. It's this property of Zig that I think makes "read the stdlib source" actually a viable strategy for learning ho…

What did you think of the example in the article about vector math? Seems like that's an area where operator overloading actually makes the code more readable. Maybe it depends on the problem domain you're working in.

It’s a bit of a non-issue really. Once you’ve worked with the non-overloaded version for a while you quickly get used to it. The overloaded version is also superficially simple but loses information. For example, multiply versus multiplyScalar versus applyQuaternion on a vector which might all be represented by overloads of the multiply operator.

Re: Failing to Learn Zig via Advent of Code

#190

Post by mst »

pjmlp wrote: post #186
mst wrote: post #172

Earlier quoted context omitted.

When I was writing arm26 (i.e. arm2) assembly for the Archimedes everybody passed around a block of ASM that did division since the processor had a whole 16 instructions and integer division wasn't one of them. Things are less primitive these days but the memory still brings a smile to my face.

MIPS was also like that, if I remember correctly, division and multiplication were assembler macros.

Reading about MIPS was where I first encountered the concept of a branch delay slot and I am -so- glad I've never had to write assembler for a processor with that feature.
Post reply on HN