Compiler Explorer and the promise of URLs that last forever

Original Article ↗ Hacker News Discussion ↗

Free vs. paid services and longevity

  • Some argue free third‑party services are inherently fragile because there’s no revenue to sustain them.
  • Others counter that plenty of paid services (including from large companies) are killed with short migration windows, while many free projects and open-source software (e.g., Linux) endure.
  • Conclusion in thread: business model alone doesn’t predict durability; both free and paid services vanish.

Google, goo.gl, and trust

  • Many see shutting down read-only goo.gl as gratuitous: redirects are simple, storage is cheap, and Google previously promised existing links would keep working.
  • Speculated reasons: outdated dependencies, legal risk, internal maintenance burden, or just management wanting to reduce “distractions.”
  • Google’s pattern of sunsetting products is seen as damaging to trust; some are baffled they don’t treat this reputation more seriously.

Compiler Explorer, URL shorteners, and recovery

  • Using goo.gl for long stateful URLs is framed by some as “abusing” a shortener; others say shortening long URLs is the intended use.
  • Critical voices say that if “links last forever” is a core principle, outsourcing to a third-party shortener was self‑defeating; others note they were also trying not to store user data themselves.
  • People encourage cooperation with ArchiveTeam/Internet Archive, which have captured billions of goo.gl links.
  • Discussion recognizes that even Compiler Explorer itself can’t last forever, though current funding and possible foundation plans mitigate that.

Link rot, personal archiving, and tools

  • Many describe disillusionment with bookmarks as URLs rot, leading them to: save PDFs, copy text to files (Markdown/RTF), use reader views, SingleFile, WARC/WebRecorder, Zotero, Pinboard, or self‑hosted archives.
  • Some automate archiving every visited page or send pages to external services for search, FTS, embeddings, or LLM tagging.
  • Caveats: domains can be removed from the Internet Archive; even IA and archive.is are seen as ephemeral; self‑hosted archives lack external verifiability.
  • Various timestamping and hashing schemes (including blockchain/GPG ideas) are debated, with no clear consensus on a robust, practical proof-of-authenticity system.

URLs, URIs, and content addressing

  • Several explain the URL/URI/URN distinctions; others dismiss it as largely pedantic in practice.
  • Content-addressed URIs (e.g., IPFS) are proposed as the only “forever” references, but critics note they don’t guarantee availability—someone must still host the content and maintain name‑to‑hash mappings.

Cool URIs, file extensions, and design

  • The classic “Cool URIs don’t change” guidance is cited.
  • Debate over whether URLs should include .html (clear, maps 1:1 to files) versus extensionless paths (hide implementation, allow multiple representations).
  • Some advocate canonical extensionless URLs with optional format-specific variants; others see extensions as useful and human‑readable.

Ephemerality vs preservation

  • Some suggest URL death may be healthy “garbage collection,” preserving only what people work to keep.
  • Others emphasize historians’ desire for mundane records, warning that we can’t predict what future scholars will value.
  • Multiple comments stress designing systems under the assumption that infrastructure and institutions are not permanent; nothing truly lasts forever.

LLM usage disclaimers

  • Noted trend of authors disclosing that text is human-written but LLM‑assisted (links, grammar).
  • Some welcome transparency, especially for “serious” writing; others see such labels as unnecessary if content quality is clear on its own.