I don't know if I would describe Zig as ergonomic per se. It has some nice features, but the main focus is on completely explicit control over low-level details. In its design Zig always chooses explicitness and programmer control over ergonomics. If a language feature requires a lot of compiler magic then it's probably never going to be added.

▲

josephg a day ago | parent [-]

Yeah I think of Zig as a modern version of C. And Rust and (I think) D like modern versions of C++. Well. Given D's marriage to the GC, maybe its more like Go or C#.

I know its petty - I still can't get past how idiotic and frustrating it is that Zig treats unused variables as a compiler error. Its the worst of all worlds:

- Its inconvenient (I have to explicitly suppress them in my code with _ = foo)

- Once I've suppressed them, I don't get any compiler warnings any more - so ironically, it takes more effort to find and fix them before committing. I end up accidentally committing code with unused variables more than in Rust or C.

- And it totally breaks my flow. I like to explore with my hands and run my code as I go. I clean up my code after my tests pass so I can be sure I don't introduce new bugs while refactoring.

Zig's handling of unused variables seems like an unforgivably bad design choice to me. Its been raised by the community plenty of times. Why hasn't it been fixed? I can understand if Andrew Kelly doesn't program the same way I do. We all have our idiosyncrasies. But does he seriously not have any smart people around him who he trusts who can talk him out of this design?

It seems like a huge pity to me. It otherwise seems like a lovely language.

▲

WalterBright an hour ago | parent | next [-]

D will complain about unreachable code. I'm not a big fan of that, as it makes it a pain for me when doing a binary search looking for the source of a problem.

▲

WalterBright 2 hours ago | parent | prev | next [-]

D's use of GC is more like a friend than a marriage.

▲

kristoff_it a day ago | parent | prev [-]

> Zig's handling of unused variables seems like an unforgivably bad design choice to me. Its been raised by the community plenty of times. Why hasn't it been fixed?

Because yours is just an opinion. It's perfectly legitimate to not like unused variable errors, but its factually wrong to say that no one wants it. You're just yucking somebody else's yum.

> But does he seriously not have any smart people around him who he trusts who can talk him out of this design?

He does, most of them also like unused variable errors. For what it's worth, I do too.

▲

defen a day ago | parent | next [-]

The unused variables thing seems like it's downstream of "no warnings, only errors". That is, once you're committed to errors-only, then unused variables are either an error, or not. And if those are your only two choices, then errors sound better.

However, I've written a decent amount of Zig code and that's probably my biggest complaint. Zig has put a ton of effort into making an ultra-fast developer experience with very low iteration times, and it's amazing. But then when I'm refactoring some code or trying to figure stuff out by, for example, commenting out some lines of code, I might get a bunch of unused variable errors. And so I spend more time fixing those than I do even compiling the code itself!

One thing I've seen suggested is using the linter to automatically insert `_ = foo` for unused variables, but I don't love that either because then what even is the point of the error in the first place?

But like I said that's all downstream of the no-warnings policy. And I totally understand the failure mode of warnings - I've worked on plenty of large projects that had 4,000 warnings and everyone ignored them and the actually useful ones would be invisible. Is there some middle ground where, I don't know, Debug builds can have warnings, but Release builds don't?

	▲	WalterBright an hour ago \| parent \| next [-]
		D started out as a language with no warnings, for the reasons you pointed out. Unfortunately, warnings have crept in from the edges.
	▲	josephg 19 hours ago \| parent \| prev [-]
		I’d go further and say that zig already respects / trusts developers enough to manage their own memory. Philosophically it’s already not a language for sloppy teams who would ignore 4000 compiler warnings if given half a chance. Zig is a language that demands a lot of rigour of the programmer. It offers a lot of trust. Far more so than Go or even Rust. It’s in light of that philosophy that it seems so weird. The compiler trusts me to manually manage my memory, but it’ll scold me like a naughty child if I ignore an unused variable for 5 minutes? Pick a lane. I’d love to hear some arguments in support of this choice. The closest I’ve heard is “it doesn’t bother me, personally” - which isn’t a very strong argument. I’m a little tempted to fork the compiler just to fix this. Can’t be that hard, right?

▲

josephg a day ago | parent | prev [-]

In that case, can you help me understand the logic behind it?

The more time I spend thinking about it, the more convinced I am that its strictly worse. What am I missing? Why do you like it?

	▲	a day ago \| parent [-]
		[deleted]