Minor - people are scandalized by this stuff but the emotion seems very disproportionate to the trigger, and it's not uncommon for the scandalized to shrug and then use Zig anyway.

• zig fmt is heavily pushed but generates ugly code (without mastery of trailing commas)
• build.zig is pushed and I already have a build system (#204)
• no variable shadowing (#3320, #14913)
• const variables must be used (#335)
• var variables must be mutated (#224)
• no multiline comments (#161)
• andrewk was mean to me >:( and has bad opinions >:( (https://mastodon.social/@andrewrk)

  My review: it's much easier to dislike what he has to say on the microblogging platform, which is just what's natural for microblogging: the low barrier to expression lets one say things as soon as the thought occurs, and the 'micro' of 'microblog' means not including lots of caveats or indicators of the intensity of what's being said (for example, I'm not smart, I'm sweaty is not a heartfelt confession that he lacks intelligence). In technical forums his behavior is generally professional, a good example of how to maintain a project with minimal drama. At his worst he's curt in a way that can easily offend (#22079)

• Zig code can't be syntax-highlighted on some website - https://highlightjs.org/ just needs to die. Use prism.js instead.

Github - there's a great deal of strife on Github but I'm not sure how much newcomers to Zig care.

• (sort issues by negative reactions)

Major - easy-to-understand reasons to just not use Zig at all.

• not being "memory safe" (#230)
• depending on LLVM (#16270)
• having different semantics based on compilation mode, Debug vs. ReleaseSafe vs. ReleaseFast (#19664)
• Zig doesn't have a big company behind it so it won't be successful
• Zig doesn't have a blessed concurrency model or async in the language, after an unsound attempt was removed with the 0.11.0 release (Aug 2023)
• ref/value passing optimization can introduce aliasing in code that looks like it can't alias (#5973, discord discussion)
• dangling pointer errors - pointers to the stack past the stack's lifetime - are very easy to make, and very commonly observed, and are not checked UB. These errors also tend to work fine in Debug builds, only biting in Release modes. Worst of all, troubleshooting is quite hard due to the limited debugger support and the difficulty of using C memory checkers like libasan.

Maybe - I think these scandals are too narrowly felt to really count.

• u0 is a zero-length type and zero-length types would doom the language and be remembered as a "billion-dollar mistake"

Social gripes

• "What's up, my Ziggers?" - this fan name is an object of some hate and suspicion, particularly as to the sentiments of the people that use it. To block this fan name, Zig communities pretend to have a fan name of 'Ziguanas', which at least relates to real mascot characters on ziglang.org. Fan names though are a symptom of heavy-handed marketing and not a normal feature of technical communities. Zig is a programming language used by Zig programmers, it's not a social class or an identity group.
• z-names: zigistry, zulid, zoridor, doczy, unitz, zigtris, zigualizer, zilite. This tendency unfortunately is programming-wide and somewhat justifiable.
• 'zigthonic', by analogy from 'pythonic'. The general term is idiomatic. Which of these two Zig functions is more idiomatically written? Which one better adheres to the idioms of professional Zig programming? There is no reason to have a branded synonym of 'idiomatic' for every programming language, especially not one that includes the 'th' from 'python'.

Warts - a nice thing about the Python community is that it was very early on agreed that Python has warts and these can be discussed without the discusser being seen as an enemy attacking the success of Python, arousing defensive mobs of righteous Python programmers. Zig, so far, lacks any such agreement.

• std has unreasonably long names: std.StringArrayHashMapUnmanaged, std.StringArrayHashWIthAllocator. In this case these are transitional names towards unmanaged-only std.StringArrayHashMap. In general, Zig encourages appropriate aliasing slightly better than many languages do, as even 'importing std' is an aliasing operation: const std = @import("std");.
• defer allows you to write to terminal stack locations, doing no useful work while appearing to do useful work.
• Zig has an unusually large amount of noise in an operation like getting the absolute difference of two unsigned integers @abs(@as(i32, @bitCast(a)) - @as(i32, @bitCast(b))), which encourages worse but shorter expressions like @max(a, b) - @min(a, b), or if (a > b) (a - b) else (b - a).

Fetishes - all of the alternative titles that occurred to me for this section were more pejorative.

• Zig is, like Go, a language for stupid people, because that's what it means for a language to not impose its own high cognitive load on the programmer. On the contrary, consider:
  • Math with Roman numerals has a higher cognitive load than math with Arabic numerals. The Arabic numerals are just a better and more convenient notation. This might allow more people to do simple math. Was it a barrier to the development of mathematics? Put another way, would mathematics advance faster if mathematicians used worse notations?
  • Writingwithoutspacesalsohasahighercognitiveloadthanwritingwithspaces. The Romans did this too. Would you feel more smug about your mental capabilities if someone saw you reading a book like this? When you would only look like you're pointlessly inconveniencing yourself?
  • Do Olympic sprinters run around with worse than normal shoes? Do sprinters deliberately wear awkward clothing, to increase the athletic impressiveness of being able to run at all? No, the impressive feat is in what's done, and not how it's done. To impress, write an impressive program. You'll likely find that this is easier to do when your tools don't hinder you.