Dada, an experimental new programming language

Project intent and status

• Dada is framed as a “thought-experiment language” inspired by Rust but aiming to feel more like Java/JavaScript, with a required runtime and gradual types.
• It currently “doesn’t really exist” beyond experimental prototypes; much of the site is speculative documentation used to explore design.
• Some find this docs‑first, imaginary‑language approach insightful; others question who the eventual audience is if it overlaps heavily with existing languages.

Ownership, leases, and memory management

• Core idea: leases as a potentially simpler alternative to Rust’s borrow checker and lifetimes.
• Several commenters doubt leases are conceptually easier; they see similar complexity under a different name.
• Debate on avoiding GC: some argue GC can be faster than malloc, is appropriate for high‑level languages, and that GC pauses are manageable; others value deterministic performance, embedded suitability, and Rust‑style stack allocation.
• Reference counting is discussed as a middle ground; some view it as the de facto “easy path” in Rust, others note its performance costs.

Async/await design and print().await

• The mandatory async/await model, including print("...").await, triggers extensive discussion:
  • Supporters: IO is inherently async; making blocking explicit surfaces real behavior and avoids hidden buffering issues.
  • Critics: it adds cognitive load for trivial tasks, complicates debugging/logging, and tightly couples starting vs awaiting tasks.
• Questions arise about how to do synchronous IO, concurrent waits (e.g., Promise.all‑style patterns), and whether async should be explicit at call sites or defaulted.
• Broader dispute over async/await vs green threads and coroutines: some prefer Go‑/Erlang‑style lightweight threads; others like explicit suspension points.

Typing and inference

• Dada is gradually typed: no required upfront types, with a path to Rust‑like performance via annotations.
• Opinions split:
  • Some like optional types for tiny scripts and gradual hardening.
  • Others want fully static types from day one, citing Dart’s move away from optional types.
• Global type inference and strong effect systems are discussed as alternatives; concerns include “spooky action at a distance” and confusing error messages in large codebases.

Comparisons to existing languages

• Dada’s niche is debated against a long list: Rust, Swift, Go, Kotlin, Scala, OCaml/F#, Haskell, Gleam, Crystal, Mojo, ReasonML/ReScript, Dyon, Jakt, etc.
• Multiple people say they “want the opposite” of Dada: Rust’s expressive type system plus a GC and runtime.
• Others feel if you can handle ownership you might as well use Rust; if you can’t, more mature high‑level languages (Swift, JVM languages, BEAM languages) already exist.

Ergonomics, syntax, and learning curve

• Mixed reactions to Rust‑style syntax: some love matches, ownership, and postfix .await; others find fn, implicit returns, and symbolic features harder to read.
• The Hello World needing .await is seen by some as poor pedagogy; others dismiss “zero‑complexity print” as a trivial concern.
• There is debate over significant whitespace, verbosity vs compactness, and whether Dada’s OO classes are a step backward.

Ecosystem, adoption, and meta‑issues

• Several note that, even if Dada (or similar languages) were ideal, lack of ecosystem and adoption would block real‑world use.
• Some praise the explicit artistic/thematic Dada references; others are lukewarm on the name and logo.
• A side‑thread discusses a pronoun‑updated manifesto quote: some appreciate the change; others see it as unnecessary ideological signaling, but this does not affect the technical design.