Project ideas from Hacker News discussions.

Borrow-checking without type-checking

📝 Discussion Summary (Click to expand)

Theme 1 – Preference for static vs. dynamic typing

“The goal is that most of your code can have the assurances of static typing, but you can still opt in to dynamically‑typed glue code…” – jamii
“Dynamic typing is neat, I actually prefer it to static typing.” – Pay08

Theme 2 – Terminology and conceptual framing of typing

“Technically, in a type theory context, there’s no such thing as ‘dynamic typing’. Types are a static, syntactic property of programs.” – antonvs
“Dynamic typing is no typing.” – choeger

Theme 3 – Specific language‑semantics question

“Can someone help confirm whether I understand correctly the semantics difference between the final‑line eval of x^ vs x*?” – drabbiticus


🚀 Project Ideas

Generating project ideas…

Typed REPL Glue for Static Languages

Summary

  • Provides a compiler extension that lets developers write mostly statically‑typed code while allowing isolated dynamic sections for REPL, hot‑reloading, and runtime code generation, eliminating the need for a separate dynamically‑typed language.
  • Core value: static guarantees with zero runtime cost for the static parts, plus flexible dynamic glue where needed.

Details

Key Value
Target Audience Static‑typed language developers who need REPL, live code reload, or runtime code generation (e.g., Rust, Haskell, TypeScript developers).
Core Feature Opt‑in dynamic execution blocks that are type‑checked separately and incur no overhead for the surrounding static code.
Tech Stack Rust (compiler front‑end), LLVM, WebAssembly for the REPL, TypeScript for UI.
Difficulty Medium
Monetization Revenue-ready: Subscription SaaS for hosted REPL and CI integration.

Notes

  • HN commenters such as jamii explicitly want “most of your code can have the assurances of static typing, but you can still opt in to dynamically‑typed glue code”.
  • Enables practical utility for live‑coding tools, educational REPLs, and rapid prototyping without sacrificing safety.

Type‑Safe Runtime Code Generator (TSRG)

Summary

  • A library that lets you define schemas for dynamically generated code snippets and automatically verifies them against a static type system before execution.
  • Core value: eliminates runtime type errors in generated code while preserving the flexibility of dynamic code creation.

Details

Key Value
Target Audience Researchers, DSL creators, and developers who generate code at runtime (e.g., query compilers, template engines).
Core Feature Schema‑driven code generation with compile‑time type checking using a lightweight DSL embedded in the host language.
Tech Stack Python (host), Rust (via PyO3) for type checking, WebAssembly for sandboxed execution.
Difficulty High
Monetization Revenue-ready: Open‑source core with paid hosted execution service and enterprise support.

Notes

  • Quote from pay08: “Have you ever tried making a container of arbitrary types in C++?” – TSRG solves that by safely exposing containers of heterogeneous types.
  • Practical utility for secure plugin systems, adaptive compilers, and educational tools; likely to spark discussion on type‑safe metaprogramming.

Opt‑In Dynamic Typing Layer (ODTL)

Summary

  • A lightweight runtime layer that adds tag‑based dispatch to statically typed languages, allowing selective dynamic method calls while keeping the rest of the code fully typed.
  • Core value: gives developers the flexibility of dynamic typing on demand without compromising overall program safety.

Details

Key Value
Target Audience Power users of statically typed languages (Rust, Go, Swift) who want occasional dynamic behavior (e.g., plugin marketplaces, REPLs).
Core Feature Runtime wrapper that tags values and routes method calls through a static dispatcher, preserving compile‑time guarantees for untagged code.
Tech Stack Go (runtime), WebAssembly for sandboxing, optional C++ bindings.
Difficulty Low
Monetization Hobby

Notes

  • lmm remarked “If C++ was the only static type system I'd experienced, I would also think it was a bad idea.” ODTL directly addresses that frustration by adding safe dynamism.
  • Sparks discussion on type theory terminology (e.g., “untyped” vs “unityped”) and can be extended into a research prototype for language design debates.

Read Later