The hunt for the missing data type
Programming languages routinely ship with built-in arrays, lists, and hash maps, yet almost none offer a first-class, general-purpose graph type, even though many real-world problems are naturally graph-shaped. Commenters argue that graphs are both too general and too performance-sensitive: different graph algorithms demand incompatible representations (pointer-based structures, adjacency lists, sparse matrices, relational tables), so any one abstraction would either be inefficient or too limited. The consensus is that graphs are better handled via domain-specific structures, libraries, or database/query tools (from NetworkX to GraphBLAS and Datalog-style relations), while core languages mostly expose only the lower-level building blocks like pointers and collections.
Graphs as a universal model
- Many commenters see most program state as a graph: objects/structs are nodes, fields/pointers are edges, the heap is the object graph.
- Others warn that “everything is a graph” is too abstract to be actionable; like saying “everything is bits” or “everything is numbers.”
Why no built-in graph data type?
- Graphs are more of a high‑level abstraction than a single data structure, akin to “database” rather than “list.”
- Real problems usually need specialized graphs (DAGs, trees, hypergraphs, attributed graphs, graphs with constraints like “no cycles”), so a single core type would either be too weak or too opinionated.
- Many everyday tasks are solvable without making graphs explicit, so demand for a first‑class type is limited.
Representations and performance tradeoffs
- Implementations vary: adjacency lists, matrices, sparse matrices (CSR/CSC), edge lists, pointer/index structures, relational encodings.
- Performance differences can be orders of magnitude; for big/complex graphs, domain‑specific layouts are often mandatory.
- Several people note that “simple, small” graphs are easy to hand-roll from maps and vectors; once scale or complexity matters, generic libraries often aren’t fast enough.
APIs, algorithms, and partial solutions
- Hard to standardize a minimal but useful API: directed vs undirected, multi-edges, labeled nodes/edges, mutations, subgraph operations, etc.
- Some argue even an “80%” simple graph type plus basic algorithms (BFS/DFS, shortest paths, topo sort) would be valuable, especially for small graphs, testing, and pedagogy.
- Others reply that it’s more like a “20% solution” that fails on the interesting 80% of real use cases.
Existing libraries, languages, and alternatives
- Many ecosystems already have graph libraries (Boost Graph, petgraph, NetworkX, FGL/Alga, Erlang/Elixir graph modules, GraphBLAS, SNAP, RedisGraph/FalkorDB, etc.), but they live outside core language runtimes.
- Some advocate using relations/tables or sparse linear algebra as the primary abstraction; others see relational databases as “graph support” for many real-world problems.
Visualization, literals, and tooling
- Textual graph literals (DOT, Mermaid, ad‑hoc syntaxes) and “Excel for graphs”–style tools are proposed as ways to make graphs more accessible.
- Graph drawing for large, non-hierarchical graphs is described as inherently hard; many layouts quickly become visually incomprehensible.