Dada | Dada
dada-lang.org
Dada is a WIP programming language

Created by Niko Matsakis, a core Rust developer (Language Team leader) who was influential in its evolution. He wrote the last article I posted. Also worked on by Brian Anderson, another core developer who worked on Rust in its early stages, on critical features such as the Result type as well as build system, testing support, and language websites.

Dada is a thought experiment. What if we were making a language like Rust, but one that was meant to feel more like Java or JavaScript, and less like C++? One that didn’t aspire to being used in kernels or tiny embedded devices and was willing to require a minimal runtime. What might that look like?

…

Dada is an ownership-based language that is in some ways similar to Rust:

  • Like Rust, Dada doesn’t require a garbage collector.
  • Like Rust, Dada guarantees memory safety and data-race freedom.
  • Like Rust, Dada data structures can be allocated in the stack and use flat memory layouts.

In other ways, though, Dada is very different:

  • Like TypeScript, Dada is a gradually typed language:
    • That means you can start out using Dada in the interpreter, with no type annotations, to get a feel for how it works.
    • Once you’ve gotten comfortable with it, you can add type annotations and use the compiler for performance comparable to Rust.
  • Dada targets WebAssembly first and foremost:
  • Dada is object-oriented, though not in a purist way:
    • Dada combines OO with nice features like pattern matching, taking inspiration from languages like Scala.

Dada also has some limitations compared to Rust:

  • Dada has a required runtime and does not target “bare metal systems” or kernels.
  • Dada does not support inline assembly or arbitrary unsafe code.
  • onlinepersona@programming.devEnglish
    52·
    8 months ago

    Dada is object-oriented, though not in a purist way

    This is what I’m missing from Rust. No paradigm fits all cases and the lack of inheritance Rust makes it difficult to write DRY code when types have shared fields or you want to expand on an existing class. It forces you to either write a macro to generate those types of compose types and then self.shared_type.attribute or worse self.shared_type.parent_shared_type.attribute.

    CC BY-NC-SA 4.0

    • echindod@programming.dev
      3·
      8 months ago

      So, I think I understand your comment: you want inheritance for shared fields, not shared methods? The shared methods could be access with traits. But if you have a struct for Building, you can’t inherit the default fields to a struct for House that would add something like the name of the family who lives there. Do I understand this right?

      • onlinepersona@programming.devEnglish
        41·
        8 months ago

        Quite close. The fields part is spot on. The shared methods should be provided as a default by the parent and overriden by the child with no super() possible.

        Basically, inheritance should just be merging structs at compiler time to cause no runtime performance hit caused by looking up the parent.

        struct Parent {
  something: bool
}

impl Parent {
  fn shared_parent_def() { println!("I'm shared and defined in parent"); }
  fn shared_overriden() { println!("I'm shared and defined in parent too"); }
}

impl

// inherits from Parent
struct Child {
  another_thing: bool
}

impl Child {
  fn shared_overriden() { println!("I'm specialized and overriden in child"); }
  fn child_only() { println!("I'm only in the child"); }
}

        should compile to

        struct Parent {
  something: bool
}

impl Parent {
  fn shared_parent_def() { println!("I'm shared and defined in parent"); }
  fn shared_overriden() { println!("I'm shared and defined in parent too"); }
}


struct Child {
  something: bool  #notice me
  another_thing: bool
}

impl Child {
  // notice copied shared_parent_def
  fn shared_parent_def() { println!("I'm shared and defined in parent"); }
  // notice override shared_overriden
  fn shared_overriden() { println!("I'm specialized and overriden in child"); }
  fn child_only() { println!("I'm only in the child"); }
}

        This could all be written manually, but changing something in the Parent would require copy-pasting everything to the descendants. Not DRY at all. If Dada did the generation of the types in the compiler, it would be amazing.

        CC BY-NC-SA 4.0