The post is for the second edition of The Art of 64-Bit Assembly, a very large book from No Starch that teaches x86-64 assembly through Windows and MASM. The sales copy leans hard on an anti-LLM pitch about understanding vtables, ABI details, and instruction-level behavior. That framing hijacked a lot of attention, but the more useful read is simpler: this is a platform-specific deep dive from an author with a long track record of teaching low-level programming, and people familiar with his older books mostly still trust him for that job.
The strongest consensus was that assembly is still worth learning, just for narrower reasons than it once was. People pointed to compiler backends, runtimes, garbage collectors, interrupt handlers, coroutines, JITs, system interfaces,
SIMD kernels, and hard real-time work. Nobody treated assembly as the default route to performance across a whole codebase. The practical line was that compilers usually win on broad optimization, but humans still matter in tiny hot loops, exact timing cases, special instructions, and places where language or compiler abstractions simply do not expose the machine well enough.
The other recurring point was scope. Several readers pushed back on the title because the book is really x86-64 on Windows with MASM, not a general book about 64-bit assembly across platforms. Defenders said that is normal for any serious assembly text. You have to choose an ABI, object format, calling convention, debugger, and assembler, then trust readers to transfer the mental model elsewhere. Even critics of MASM admitted the bigger issue is not syntax tribalism but whether you want a book centered on one ecosystem. For Windows developers, MASM remains viable and in some respects pleasant. For Linux-first readers, the likely gap is less “how do I learn assembly” and more “where is the equivalent treatment for
GAS,
NASM, or
FASM on Linux?”
The LLM talk landed in a narrower place than the marketing copy suggested. Few people bought the idea that models make books like this obsolete. The more convincing claims were operational: LLMs can help translate assembler between syntaxes, act as a fast manual, or drive reverse-engineering tools, but they are shaky when correctness and cycle-level behavior matter. For code that exists because it must be exact, “usually right” is not enough. That left the enduring value of a book like this in the same place as before: not just emitting instructions, but teaching the ABI contracts, toolchain behavior, and machine model that let you know when code is actually correct.