[throwawaymaths]

Zig borrows some ideas from go. Probably defer is the big one, but if you watch "the road to zig 1.0" you will understand that zig is not really a go derivate. Most things in zig are directly addressing issues in c.

If you squint zig's error return fusion looks a bit like go's tuple error return but it actually is more "first-classing certain c conventions" than "adopting a go pattern". Same goes for slices.

[AndyKelley]

Go's defer is incredibly flawed:

1. It only allows function calls instead of any expression.

2. It allocates memory dynamically and attaches the function call expression to the function, rather than the current scope exit. This has surprising and harmful consequences if you use it inside a loop.

So, I wouldn't say that zig's defer is borrowed from Go.

[throwawaymaths]

Not in implementation but surely in spirit. Didn't you mention in road 1.0 that the idea came from go?

Edit: ok rewatched it and I didn't see that come up, i was just misremembering

[FoodWThrow]

Most of C's issues were directly addressed in Go as well. Only, Go did away with manual memory management.

C never had the philosophy of keeping things simple through the years. If it did, we would not have time traveling UBs to begin with. The lauded simplicity and explicitness comes directly from Go, where the philosophy was crystalized and preserved very early on.

You might say it is semantics, to call improving upon C being a derivative of Go (with manual memory management). You would be partially correct, it is semantics, but one that holds up very well if you look at how languages developed over the decades.

[throwawaymaths]

> The lauded simplicity and explicitness comes directly from Go

I have two words for you: json marshalling