Systems ideas that sound good but almost never work

Original Article ↗ Hacker News Discussion ↗

Domain-Specific Languages (DSLs)

  • Major split: some report DSLs “never” working well; others cite many successes.
  • Success patterns: small, tightly scoped, well-documented DSLs; embedded DSLs in a host language (Lisp, Ruby, Kotlin, C#) with IDE support, autocomplete, and fast feedback.
  • Good for: letting domain experts encode rules (forms, ASIC configs, planners, reporting) without learning a full language; expressing behavior in domain terms.
  • Failure patterns: trying to “replace” an existing language (e.g., SQL) with a heavier DSL; large, growing DSLs that leak underlying complexity and become unmaintainable.
  • Disagreement over definitions: when is it a DSL vs “just an API” vs “a data format”; some insist syntax change is essential, others emphasize semantics and domain vocabulary.
  • Examples praised or criticized: regex widely cited as successful; HCL, XUL, E4X, and complex format strings cited as scaling poorly.

ORMs, SQL, and Abstractions

  • Many argue abstracting away SQL via DSLs/ORMs is costly: you must still understand relational design, indices, and query plans.
  • Complaints: hard to express complex queries or tune performance; debugging by printing generated SQL and round-tripping to a DB tool.
  • Counterpoint: ORMs can reduce boilerplate mapping and be productive once you already understand SQL and the DB.

Control Loops, Autoscaling, and Hybrid Parallelism

  • Control loops (autoscaling, load-based throttling) are standard but easy to get wrong: runaway feedback, conflicting loops, “poisoned” signals, and cascading throttling are common failure modes.
  • Some see Kubernetes and ELBs as proof control loops work; others say they work only after large, expert investments.
  • Hybrid parallelism (multiple hardware types or layers of parallelism) is powerful in HPC but often adds prohibitive complexity in typical systems work.

APIs and “Let’s Just…” Ideas

  • “Let’s just add an API” is criticized as underestimating work: design, authz/authn, rate limiting, caching, correctness, error messages, versioning, and documentation.
  • Organizational issues (politics, unclear ownership, timelines) often sink API projects more than raw technology.
  • Similar caution applies to “let’s just sync the data,” cross-platform rewrites, P2P caches, anomaly detection, and event sourcing: all can work, but only with deep design and sustained investment.

Overall Tone

  • Broad agreement that these ideas are not inherently bad; they’re deceptively hard and frequently overused as premature optimization or resume-driven engineering.
  • Some see the article as overly pessimistic; others view it as a necessary warning against “let’s just” thinking.