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

231–240 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#231

Post by einpoklum »

stathibus wrote: post #88
iTokio wrote: post #26

Earlier quoted context omitted.

Reading the source code is very helpful if you are an experimented programmer that already grasped the basics of the language. It helps you to see what are the idioms, what does optimized production code look like. Compare C++ and Go std lib and it’s easy to constate the difference in language goals that they have.

Reading the c++ stdlib source code is never a good idea.

It's not a fun experience to be sure, but:

1. It's useful when you want to check the exact under-the-hood behavior, to figure out side-effects or corner-case semantics.

2. After a good number of years, that code becomes less scary and more icky. Some of it remains kind of scary though...

3. Reading that code teaches you a lot about considerations you may be ignoring, especially your implicit platform-dependent assumptions.

4. Nitpick: There isn't any single C++ standard library source code, it's at least 3 popular ones (GCC's libstdc++, LLVM's libc++, and Microsoft's)

Re: Failing to Learn Zig via Advent of Code

#232

Post by Comevius »

pjmlp wrote: post #202
Comevius wrote: post #191

Earlier quoted context omitted.

Zig is warts-free C, but you can use them together. You can gradually refactor your C codebase, Zig can even transpile C. Zig is also a standalone C toolchain, compiling and cross-compiling C is a breeze with it, and it has it's own libc implementation.

It doesn't fix C flaws like use after free, hardly warts-free.

That's not a C flaw, you can use an allocator that prevents use-after-free.

https://github.com/bwickman97/ffmalloc

The point of C and Zig is that they are low level and you can do whatever, like not use an allocator, or write an allocator.

Re: Failing to Learn Zig via Advent of Code

#233

Post by spc476 »

dundarious wrote: post #222
yjftsjthsd-h wrote: post #181

Earlier quoted context omitted.

> 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?

Zig's "fancy" (I don't think they're that fancy) type features that IMO make it a great C alternative are: - non-null pointers, and distinct types for single-item pointers and multi-item pointers (multi-item pointers are rarely used except indirectly via slices, so unchecked pointer arithmetic errors are largely banished) - builtin tagged unions (AKA algebraic data types) with very pleasant to use switch logic -- it…

So it sounds like Zig makes a distinction between pointers and arrays. Am I reading that right?

Re: Failing to Learn Zig via Advent of Code

#234

Post by pjmlp »

Comevius wrote: post #232
pjmlp wrote: post #202

Earlier quoted context omitted.

It doesn't fix C flaws like use after free, hardly warts-free.

That's not a C flaw, you can use an allocator that prevents use-after-free. https://github.com/bwickman97/ffmalloc The point of C and Zig is that they are low level and you can do whatever, like not use an allocator, or write an allocator.

Just like C memory debuggers for the last 30 years, so what is the benefit?

Re: Failing to Learn Zig via Advent of Code

#235

Post by thayne »

AnIdiotOnTheNet wrote: post #19

As a seasoned Zig programmer, this is good information, though painful to read. A lot of the problems seem to be from a fundamental misunderstanding of Zig's philosophy and very basic things about how the language works. Possibly Zig needs more emphasis on those things in its documentation. I also have to wonder about a fundamental misalignment of thinking when someone says downloading and replacing a single .exe is…

The biggest thing that stands out to me from the complaints is the lack of documentation, which is probably part of the misunderstanding of the philosophy.

Re: Failing to Learn Zig via Advent of Code

#236

Post by dundarious »

spc476 wrote: post #233
dundarious wrote: post #222

Earlier quoted context omitted.

Zig's "fancy" (I don't think they're that fancy) type features that IMO make it a great C alternative are: - non-null pointers, and distinct types for single-item pointers and multi-item pointers (multi-item pointers are rarely used except indirectly via slices, so unchecked pointer arithmetic errors are largely banished) - builtin tagged unions (AKA algebraic data types) with very pleasant to use switch logic -- it…

So it sounds like Zig makes a distinction between pointers and arrays. Am I reading that right?

Yes, arrays are another distinction:

- an array [3]u8

- a single item non-nullable pointer *u8

- a single item nullable pointer ?*u8

- a multi-item non-nullable pointer [*]u8

- a multi-item nullable pointer ?[*]u8

- a slice []u8

Typically your API is just made up of slices and non-nullable single item pointers. Arrays are just the typical backing store for a slice, that you might define in main or for small scratch buffers. Here's a typical example of an OS read (where the fd has been set to non-blocking already):

    fn readUpTo32Bytes(fd: std.os.fd_t) ![]u8 {
        var array: [32]u8 = undefined;
        var data = array[0..]; // slice of entire array
        data.len = std.os.read(fd, data) catch |err| switch (err) {
            error.WouldBlock => 0,
            else => return err,
        };
        handle(data);
    }

    fn handle(data: []const u8) void { ... }
If you don't need to handle EAGAIN/error.WouldBlock, then just do `data.len = try std.os.read(fd, data);`

I didn't explain the `!` in the `![]u8` return type, but it's basically saying "an error or a []u8", where it's compile time known what the full set of errors is (in this case every error std.os.read can return, minus WouldBlock).

Re: Failing to Learn Zig via Advent of Code

#238

Post by templix »

Shadonototra wrote: post #106

I don't think it is that hard to learn I'm not a professional programmer, this is all a hobby for me and i managed to pick and write an entire game with it maybe you are just bad as a programmer (nothing wrong with that) you have to learn how to learn, not everybody can do that (and it's fine) that being said, zig is a language in the making, some areas are rough, but that's to be expected

> maybe you are just bad as a programmer (nothing wrong with that)

This was actually my impression after reading the post. A bad programmer making a lot of ill-informed complaints. Zig is an unfinished low-level language. Not suitable for bad programmers.

Re: Failing to Learn Zig via Advent of Code

#239

Post by rslabbert »

stephc_int13 wrote: post #60

I disagree from this part: "I also think it's partially wrong. No one in the history of the world has ever been confused or upset by a + b calling a function." It depends. If this is simple math on vectors I think it can be OK but it should probably be a built-in feature of the language as this is common, solved and we all implement it the same way (for short vectors at least) But the + operator has been abused in th…

Interestingly since you can't pass an allocator to an operator call, there is some extra guarantee around whether a hypothetical overloaded operator can allocate. If you implement it for a vector type which doesn't contain an allocator reference, then you're sure that any operators won't allocate.

Re: Failing to Learn Zig via Advent of Code

#240

Post by kazinator »

brabel wrote: post #14

Nice to see a "brain dump" as someone who learned many languages and can easily relate with most of the issues the author faced. But I take issue with this: // Obviously good and easy to read return a*(1.0-t) + b*t; // Obviously bad and hard to read return add(mul(a, 1.0 - t), mul(b, t)); Sorry, but the first one is not obviously good, it's just what you're used to (the second one is indeed bad). Here's what I would…

It has been proposed to me (just yesterday!) by a collaborator to ad a linear interpolation function to TXR Lisp, so that would look like:

  (lerp t a b)  ;; possibly, modulo argument order.
Post reply on HN