Project ideas from Hacker News discussions.

Time to Move On: Querying Without Nulls and Bags

📝 Discussion Summary (Click to expand)

1. SQL’s entrenched dominance and the high bar for a successor

"It's unfair, but my first thought after reading the abstract was \"oh great, another one\"." (bbkane)

2. Inherent flaws in SQL’s semantics (nulls, bags vs. sets)

"SQL is _insanely bad and complex." (mamcx)
"It again ignore the best solution for nulls: Algebraic types." (mamcx)
"2 identical values can’t exist… then it means that this is second‑class." (mamcx*)

3. Preference for SQL despite its drawbacks, and calls for better relational models

"sql is one of my favourite languages that i deal with on a regular basis." (bawolff)

These three themes capture the main points of the discussion.


🚀 Project Ideas

SQL++ Compiler and Runtime

Summary

  • A superset of SQL that adds bag‑aware semantics, algebraic null handling, and compile‑time safety while emitting standard SQL for seamless interoperability.
  • Provides migration tooling and IDE extensions to lower the barrier for adopting a modern query language.

Details

Key Value
Target Audience Developers building applications on existing RDBMS who want a safer, more expressive query language.
Core Feature Bag‑aware operators, null‑safe algebraic types, and automatic translation to standard SQL.
Tech Stack Rust (compiler backend), PostgreSQL wire protocol, existing DB drivers, VS Code extension.
Difficulty Medium
Monetization Revenue-ready: Tiered SaaS pricing

Notes

  • HN users repeatedly lament the lack of an adopted successor language with a strong ecosystem; SQL++ would supply that missing bridge.
  • The abstract’s frustration about “SQL is good enough but IDE/agent experience is lacking” is directly addressed by the IDE extension and compile‑time checks.

BagAware Query Engine (BQ Engine)

Summary

  • A lightweight library/CLI that treats duplicate rows as first‑class data, exposing counters and enabling both set‑ and bag‑oriented operations out of the box.
  • Eliminates the need for ad‑hoc surrogate keys to disambiguate identical records.

Details

Key Value
Target Audience Data engineers and analysts working with logs, event streams, or tables with many duplicate records.
Core Feature Native bag‑aware SELECT, COUNT‑WITH‑COUNTS, duplicate detection UI, and set‑mode toggles.
Tech Stack Python (core), SQLite (storage), PyO3 for Rust bindings, optional web UI with Flask.
Difficulty Low
Monetization Hobby

Notes

  • Directly responds to mamcx’s complaint that “the language must allow me to deal with this” regarding bags and duplicate rows.
  • Aligns with discussions about needing both sets and bags; BQ Engine lets users switch seamlessly between the two models.

Relational IDE Assistant (RIA)

Summary

  • An AI‑powered development extension that generates type‑safe query code (Rust/Go) from natural‑language specs, validates against schema, and produces LLM‑friendly documentation.
  • Removes the “learn SQL then ask an LLM” friction by providing compile‑time safe queries.

Details

Key Value
Target Audience Developers and data scientists who rely on LLMs to write queries and want typed, safe code.
Core Feature Schema‑aware query generation, compile‑time Rust checks via WASM, VS Code/IntelliJ integration.
Tech Stack Node.js extension, GPT‑4/LLMs, Rust compilation through WASM, PostgreSQL/SQLite backend.
Difficulty High
Monetization Revenue-ready: Per‑user monthly subscription

Notes

  • Echoes reaanb2’s call to “move on from speaking about rows as if they're vertices” and the desire for richer query constructs.
  • Addresses convolvatron’s point that “usable models for both” (sets and bags) can be built when the tooling supports both semantics.

[Project Title]

Summary

  • [A concise, bulleted summary of the project and the problem it solves.]
  • [Mention the core value proposition.]

Details

Key Value
Target Audience [Who is this for?]
Core Feature [Main functionality]
Tech Stack [Suggested technologies]
Difficulty [Low/Medium/High]
Monetization [Very short: "Hobby" OR "Revenue-ready: {pricing model}". Default to "Hobby" if unclear.]

Notes

  • [Why HN commenters would love it (quote users if possible).]
  • [Potential for discussion or practical utility.]

Read Later