Rethinking Database Programming

Overall reception

• Many find the new functional query language aesthetically pleasing and conceptually exciting, especially fans of functional programming and Elm-like design.
• Others see it as turning concise SQL into more verbose, less readable code, and doubt it delivers enough benefit over raw SQL or existing tools.
• Several comment that yet another “SQL replacement” is unlikely to gain broad adoption given SQL’s maturity and ecosystem.

SQL vs. Functional Query Language

• Supporters argue SQL is awkward, old, string-based, and hard to compose or statically analyze; they want pipelines, map/filter-style composition, and end-to-end type checking.
• Defenders of SQL emphasize its mathematical basis (relational algebra), maturity, powerful features (CTEs, window functions), and ubiquity, including non-programmer accessibility.
• Some note SQL’s divergence from pure relational theory (bag semantics, NULLs), but still see it as the right tool for data storage and querying.

ORMs, Schema Management, and Expressiveness

• There is debate whether this is “just an ORM in disguise.” From a user’s point of view, many say it behaves ORM-like despite marketing claims.
• Critics of ORM-style schema-in-code argue such layers lag behind DB features (partitioning, compression, advanced constraints) and ultimately force a return to SQL.
• Others prefer approaches that treat SQL as the source of truth and generate typed bindings from it.

Type Safety and Frontend–Backend Integration

• Proponents highlight end-to-end type safety from DB through backend to frontend, including sum types and reusable pipelines, as a major value-add.
• Skeptics counter that SQL itself is strongly typed (except in engines like SQLite) and that type safety across tiers can also be achieved via code generation and “describe” mechanisms.

Database Ownership, Architecture, and Longevity

• Some are wary of a language “owning” the database, especially with custom encodings (e.g., for sum types) that complicate interoperability and long-term data access.
• Several stress that databases and SQL schemas often outlive any particular application or language; they prefer the database to be the stable center, not a compiler target.
• There is skepticism that binding data representation tightly to one closed, niche language is wise for long-lived systems.

Licensing, Funding Model, and Trust

• The closed-source, subscription-based license draws significant concern. A quoted clause suggests users may lose access to data when subscriptions lapse, which many see as unacceptable for critical systems.
• Past experience with similar projects led multiple commenters to worry about “bus factor” and long-term maintenance; reliance on a single small team is seen as risky.
• Some welcome experimentation with new funding models for sustainable development but still would not adopt this in professional or even personal projects due to risk.

Alternatives and Prior Art

• Commenters point out prior efforts with similar ideas: LINQ, Haskell libraries like Selda, Datalog-based systems, SQL code generators (e.g., sqlc, Ormin), and other “database programming languages.”
• Experienced practitioners argue that decades of attempts at DB-integrated languages and ORMs have largely failed to beat “just use SQL + a driver,” especially for performance and transparency.

Usability, Documentation, and Open Questions

• People want to see complex, multi-table join examples and how groupings/aggregations are expressed, noting that simple examples are unconvincing.
• Some are intrigued by features like enforced row-level security and algebraic data types but find the syntax hard to read at a glance.
• Documentation is described as thin (e.g., keywords mentioned but not fully explained), making it hard to evaluate the system deeply.
• It remains unclear how well the language exposes full PostgreSQL/SQLite capabilities and how migrations and schema evolution (especially for advanced types) are handled in practice.