Systems ideas that sound good but almost never work

Original Article ↗ Hacker News Discussion ↗

Many engineers are pushing back against “let’s just…” systems ideas—like domain-specific languages, smart control loops, aggressive caching, and retrofitted APIs—arguing they’re far harder to make reliable than they first appear. Commenters trade examples where these approaches succeeded (e.g. small, focused DSLs, carefully tuned anomaly detection, or industrial-grade schedulers) but note that most failures stem from underestimating cognitive load, operational complexity, and organizational constraints. A recurring theme is that these techniques can work well when they are core, well-funded design choices, but tend to become brittle, over-engineered liabilities when added casually for supposed quick wins.

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.