Alarm takes severity and scale. Forecasting double-digit odds of near-term human extinction on national television to a lay audience is more extreme than yelling to unplug rogue AI. For what it’s worth, the latter has already occurred numerous times at containable scales in leading labs, mitigated by the physical realities of computation, notwithstanding the competence of involved personnel. People running into rooms yelling is probably not a hypothetical.

There is no need to count exponentials—it would only be a matter of time. The need to sum multiple factors betrays the finite limits of what is actually sigmoid growth. Reasoning about specific effects is unfortunately subject to counter-evidence and so struggles for traction against abstract handwaving about exponential growth.

There is much uncertainty, certainly not exclusive to AI. The benefit of hyper-vigilance in each case must be weighed against the cost of indulging every similar panic.

Listing particular sets of preferences for which Go is not optimal is not sufficient unless you can show the list to be exhaustive.

Still, these links may be of interest:

TypeScript’s language-service implementation of the “Move to file” refactor: https://github.com/microsoft/TypeScript/blob/main/src/servic...

Documentation for how `typescript-language-server` exposes that refactor as an opt-in code action: https://github.com/typescript-language-server/typescript-lan...

`ast-grep`, an AST-based search and transformation tool that may be closer in spirit to the cli functionality you describe, albeit more general-purpose: https://github.com/ast-grep/ast-grep

In the preface on xx-xxi:

```

This book took three years of development and another year of production. There are many more important topics in computer architecture and SoC design that were omitted from this edition for schedule reasons; we hope to address them in a future volume:

* Multicore

  * Multilevel cache coherency
  * Synchronization
  * Interprocessor communication

  * Superscalar
  * Out-of-order
  * Deeper pipelines

  * Vector
  * Hypervisor
  * Debug
  * Trace

  * Functional coverage metrics
  * Hardware emulation

  * Intellectual property block design and integration
  * AXI interfaces
  * Accelerators
  * Memory controllers
  * Network-on-chip

  * Timing and power optimization
  * Clock gating
  * Clock domain crossings
  * External interfaces

It's definitely processor-centric but I wouldn't say "about RISC-V microprocessors" catches it either. The book is certainly structured around the core, but arguably so too is SoC design, at least at an introductory level. RVSoC uses a real SoC design (CORE-V Wally), and each aspect is covered at a length more or less proportionate to the complexity of its implementation in Wally. Admittedly, Wally's peripherals are fewer and simpler than you might find out in the wild. Wally itself is 80-90% core by lines of RTL (horrible complexity metric I know, sorry).

Another way to look at the book is that it picks up where Digital Design and Computer Architecture (by the same Harris and Harris) leaves off. DDCA is used to teach the E85 course at Harvey Mudd; RVSoC is used to teach E154 (SoC design). DDCA builds up to a simplified RV32I-subset pipelined core. If RVSoC started with peripherals without fully elaborating the core, it would leave both readers of both books and students of both courses with a gap in coverage on core design compared to the depth of the remainder of both books.

Both are very detailed. With RVSoC at 859 pages in print and 1135 after the digital supplement, the core-related chapters are not by any means stealing airtime from the other components of the SoC, you could strip out every core-related page and still have a modestly-sized textbook. While not by any means an encyclopedic reference for SoC design, I found it to be a wonderful bridge from more elaborated microarchitecture into SoC.

I hope they are able to get that future volume out!

(edit: quote formatting)