from Hacker News

Dada, an experimental new programming language

by marionauta on 3/6/24, 10:31 AM with 420 comments

  • by benrutter on 3/6/24, 1:03 PM

    I love the idea of a "thought experiment language" - actually creating a working language is a big overhead, and its really fun to think about what an ideal language might look like.

    The crazy thing with reading this and the comments, is that it seems like we all have been daydreaming about completely different versions of a "high level rust" and what that would look like. For me I'd just want a dynamic run time + simpler types (like "number" or a single string type), but it looks like other people have a completely different list.

    Some of the additions here, like a gradual type system, I would really not want in a language. I love gradual type system for stuff like Python, Typescript and Elixir, but those are cases where there's already so much untyped code written. I would way prefer the guarantees of a fully static typed codebase from day one when that's an option.

  • by yamrzou on 3/6/24, 11:47 AM

    Their Hello, Dada! example:

    print("...").await

    I'm coming from Python, and I can't help but ask: If my goal as a programmer is to simply print to the console, why should I care about the await? This already starts with a non zero complexity and some cognitive load, like the `public static void main` from Java.

  • by happens on 3/6/24, 12:09 PM

    It's weird, I want pretty much the exact opposite of this: a language with the expressive type system and syntax of rust, but with a garbage collector and a runtime at the cost performance. Basically go, but with rusts type system.

    I'm aware that there are a few languages that come close to this (crystal iirc), but in the end it's adoption and the ecosystem that keeps me from using them.

  • by nu11ptr on 3/6/24, 1:32 PM

    I like the idea, but please no "async/await". In a higher level language green threads like Go has are the correct answer IMO (and I'm not a Go fan, but I feel they got this part right).

    Gradual typing is interesting, but I wonder if necessary. Static typing doesn't have to feel like a burden and could make it hard to reason about performance. I think more type inference would be better than gradually typed (like OCaml/ML).

  • by jgilias on 3/6/24, 11:39 AM

    > but one that was meant to feel more like Java or JavaScript

    Those are two very different feelings though!

  • by mihaic on 3/6/24, 2:38 PM

    I've written a bit of Rust, and I was left with mixed feelings, that seem to be still the same here: - loved the memory safety patterns when compared to the horrible things that you can do with C++ - found almost every thing where it was different to have a harder to parse syntax, that I could never get used to. The implicit return at the end of a statement for instance make it harder for me to visually parse what's being returned, since I really depend on that keyword.

    Code in general is hard for me to mentally read. I know it sounds nitpicky, but to me all keywords should be obviously pronounceable, so something like "func" instead of "fn" would be mandatory. Also, using the permission keywords where I'd expect the type to be also seems a bit strange, as I'd imagine that keyword to prefix the variable -- that's just how I think though.

    It does seem like less decorator magic and symbol-based syntax would make it easier for beginners to grasp.

    I may sound like a curmudgeon, but I'd prefer only one type of language innovation at a time.

  • by emporas on 3/6/24, 12:34 PM

    The absence of GC, makes embedded Rust a joy. It can be easily attached to other programs like Erlang with NIFs, Javascript and web pages with Web Assembly and Emacs with command line execution. Micro-controllers as well of course.

    I do consider the lightning start-up speed of a program to be one of the killer features of Rust. Rust with garbage collection throws away one of it's biggest advantages compared to every other language around.

  • by brabel on 3/6/24, 11:35 AM

    If the claim that its performance will be similar to Rust's if you add type annotations, this could become a really attractive language!

    As easy as JavaScript to write, as fast as Rust when the extra effort to write it justifies it.

  • by sagebird on 3/7/24, 7:12 PM

    Interesting. The about page starts with a quote from Dada Manifesto 1918. The quote is changed, as explained in a footnote: "Updated to use modern pronouns."

    Here is the original quote:

    I speak only of myself since I do not wish to convince, I have no right to drag others into my river, I oblige no one to follow me and everybody practices his art in his own way, if be knows the joy that rises like arrows to the astral layers, or that other joy that goes down into the mines of corpse-flowers and fertile spasms.

    changed to :

    I speak only of myself since I do not wish to convince, I have no right to drag others into my river, I oblige no one to follow me and everybody practices their art their own way.

    dada-lang about: https://dada-lang.org/docs/about/ Tzara, Dada Manifesto 1918: https://writing.upenn.edu/library/Tzara_Dada-Manifesto_1918....

  • by color_me_not on 3/6/24, 1:43 PM

    I don't understand the comment in the method print_point in the class Point of the tutorial.

        [...]
        # This function is declared as `async` because it
        # awaits the result of print.
        async fn print_point(p) {
            # [...]
            print("The point is: {p}").await
        }
    
        [...]
    
    From the first page of the tutorial:

    > Dada, like JavaScript, is based exclusively on async-await. This means that operations that perform I/O, like print, don't execute immediately. Instead, they return a thunk, which is basically "code waiting to run" (but not running yet). The thunk doesn't execute until you await it by using the .await operation.

    So, what it boils down to is that async/await are like lazily computed values (they work a bit like the lazy/force keywords in Ocaml for instance, though async seems to be reserved for function declarations). If that is the case, that method "print_point" is forcing the call to print to get that thunk evaluated. Yet, the method itself is marked async, which means that it would be lazily evaluated? Would it be the same to define it as:

        fn print_point(p) {
            print("The point is: {p}")
        }
    
    If not, what is the meaning of the above? Or with various combinations of async/await in the signature & body? Are they ill-typed?

    I wish they'd provide a more thorough explanation of what await/async means here.

    Or maybe it is a dadaist[0] comment?

    [0] https://en.wikipedia.org/wiki/Dada

  • by Doctor_Fegg on 3/6/24, 12:50 PM

    > 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++?

    That would be Swift?

    Interesting experiment. But it does seem like there are increasing numbers of languages trying to crowd into the same spaces.

  • by jokethrowaway on 3/6/24, 12:54 PM

    The main idea is that leases are an easier concept to understand than borrowing and lifetimes?

    I don't think it will be, it sounds like a concept of similar complexity and it won't make it an "easy language".

    People are scared of Typescript, so a typed language with an extra ownership concept will sound exactly like rust in terms of difficulty.

    Not that I get the reputation of Rust being hard, even as a complete novice I was able to fight a bit with the compiler and get things working.

    The gradually typed approach is nice but it just sounds like smarter type inference would get you 99% there while keeping the performance (instead of using runtime checks).

    Not having unsafe code is both interesting and limiting. I keep all my code safe for my own mental sanity but sometimes having bindings to some big library in c/c++ is convenient (eg Qt or OpenCV).

  • by k__ on 3/6/24, 1:06 PM

    Reminds me of Dyon, a scripting language for Piston.

    It's dynamically typed and uses lifetimes instead of a garbage collector.

    https://github.com/PistonDevelopers/dyon/issues/173

  • by talkingtab on 3/6/24, 2:29 PM

    My opinionated opinion: programming languages have three goals. 1) Be safe, don't make mistakes 2) Be expressive: The Sapir Whorf hypothesis 3) Be easy to use.

    JavaScript (new) is +++2, and ++3 (to me). Java is +++1 & --2, -3.

    Personally I like OO ("has a") but think Class-ification,("is a") is a big mistake. Take a truck and a car. Start replacing the pieces of the car with pieces from the truck. When is a car not a car? Arbitrary. When does the car have a tail gate, a flat bed?

    That is not a joke. Classes and Types are a way to think (Sapir Whorf) that makes you do strange things.

    The interesting thing about Dada is the "borrow", "share" etc and seems very good. But then instead of wrapping it in a class can't we just use an Object?

  • by snarfy on 3/6/24, 5:54 PM

    It's a bit frustrating that I have to click around hunting for an example of the syntax.

    If you are making a new programming language, please do us a favor and put your Hello World syntax example right on the landing page.

  • by bananapub on 3/6/24, 11:45 AM

    what does "creators of rust" mean? Graydon? niko? pcwalton?
  • by pxeger1 on 3/6/24, 3:24 PM

    I think there isn't enough research into languages with affine/linear typing (the property of some types that they can't be copied - which is partly what the borrow checker ensures in Rust). I'm super sold on it for enhancing safety. Vale with its "Higher RAII"[0] is the only other example I was aware of until seeing this.

    Rust is great but being an early adopter has made its usability imperfect in places. Combining substructural typing with gradual typing and OOP is interesting here. Others in this thread have also mentioned wanting a higher-level Rust, like Go. I'd like to see a purely functional Rust. Haskell has experimental support for linear typing[1], but I suspect a language built with it from the ground up would be very different.

    [0]: https://verdagon.dev/blog/higher-raii-7drl

    [1]: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/line...

  • by luke-stanley on 3/6/24, 1:19 PM

    I was posting that "a_print" (an auto running async printer) might be better for one of the most common features a programmer uses.

    I'm coming from Python, and for situations when people grasp for C/++ kind of performance and control, I think people are aware of the need for high performance memory safe languages that are easier to use than Rust but with many of Rust's benefits being at least possible. So I am quite excited by thinking from Dada and the people who are behind Rust and I'm also intrigued by SerenityOS's Jakt language project. I hope the insecure "C code problem" has a smooth migration path that let's C/++ devs, Typescript devs, and others make progress quickly in a powerful way. What other sort of alternative languages are there, among Dada's aspirations? Jakt? Vale (I understand a lead dev is poorly, so it's slowed a bit lately)? D? Go? Obviously AI will have a big impact. What language is going to have a big impact in this space?

  • by hgs3 on 3/6/24, 6:43 PM

    I've dabbled in PL research before, and not to downplay the work as this is just my opinion, but the Rust ownership system is too invasive. It prevents entire classes of architectures and algorithms from being directly represented without auxiliary structures and other code contortions. I don't think it is an approach that should be mimicked.
  • by Alifatisk on 3/6/24, 11:52 AM

    Why the name and the logo? Couldn't find info about it.

    Otherwise, the idea of creating something close to rust but without the complexity sounds interesting. I just hope they don't stick to that name.

  • by librasteve on 3/7/24, 4:50 AM

    ++ that gradual types are included … Rust does an awesome job of the contract you want with your compiler is enforce types strongly for maximum safety, but this is not always the appropriate trade off for small projects … i prefer a language with a sliding scale where i can grow a codebase and be more strict if and when it becomes more mission critical (gradual typing is the answer for this imo and is well done in eg rakulang)
  • by jamsterion on 3/6/24, 1:36 PM

    Dada looks "almost" great! I especially like that it targets wasm; I believe wasm is the future of frontend and also backend with wasi. However, I believe that being gradually typed is a mistake. Dart started being optionally typed and then they made it fully statically typed for very good reasons. I hope they learn from Dart's experience there.
  • by kkukshtel on 3/6/24, 6:36 PM

    Feel like there would be fewer posts and languages like this if people just took 10 seconds to read about modern C#.
  • by couchand on 3/6/24, 12:56 PM

    > As of right now, Dada doesn't really exist, though we have some experimental prototypes...

    > OK, from here on out I'm going to pretend that Dada really exists in its full glory.

    This is a brilliant trick I only recently discovered in another context: write the docs first, to validate the user experience of a novel system.

  • by stephen on 3/6/24, 3:52 PM

    If you're cloning parts of TypeScript, please bring along mapped & conditional types!

    Feel free to experiment on the syntax, but the concept is amazing, especially if you're planning on being dynamic-ish.

  • by dist-epoch on 3/6/24, 1:08 PM

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

    Are classes cool again?

  • by sn9 on 3/6/24, 10:52 PM

    This might be a naive question, but rather than targeting WASM directly, why not target MLIR (used by projects like Mojo) and use LLVM to compile to WASM?
  • by zubairq on 3/6/24, 7:23 PM

    Amazing way to test if a new computer language is viable! I think that more people (including myself) should take this approach to language design.
  • by brakmic on 3/6/24, 11:54 AM

  • by helothereycomb on 3/8/24, 6:09 AM

  • by bmitc on 3/6/24, 2:27 PM

    I thought the creators of Rust were creator, singular, in Graydon Hoare. Are they involved with this?
  • by imjonse on 3/6/24, 1:16 PM

    Not new, launched in 2021 apparently.
  • by greenie_beans on 3/6/24, 5:47 PM

    love this quote

    > I speak only of myself since I do not wish to convince, I have no right to drag others into my river, I oblige no one to follow me and everybody practices their art their own way.

    > Tristan Tzara, "Dada Manifesto 1918”

  • by BobbyTables2 on 3/6/24, 2:06 PM

    Sounds a bit like Python but with actual & optional runtime type checking?
  • by ubj on 3/6/24, 3:33 PM

    Interesting, but the intent seems similar to Chris Lattner's new Mojo language which arguably has similar characteristics and is further along in its development.

    https://docs.modular.com/mojo/

  • by p0w3n3d on 3/6/24, 4:54 PM

    It sounds like mockups to create a programming language
  • by melodyogonna on 3/6/24, 3:41 PM

    Mojo but for Javascript
  • by Georgelemental on 3/6/24, 3:22 PM

    See also Graydon Hoare's Rust-that-could-have-been: https://graydon2.dreamwidth.org/307291.html
  • by actionfromafar on 3/6/24, 12:53 PM

    What is Dada?
  • by VMG on 3/6/24, 12:05 PM

    the contrast of the links against the light background is pretty poor
  • by Rucadi on 3/6/24, 11:51 AM

    no upfront types, for me this is unusable sadly
  • by sorenjan on 3/6/24, 2:13 PM

    Changing a quote to change "his" to "theirs" seem like a very Rust community thing to do.

    > Updated to use modern pronouns.

    https://dada-lang.org/docs/about/

  • by richrichie on 3/6/24, 2:09 PM

    It was only a matter of time before even the creators of Rust grew tired of it being another C++.
  • by owenbrown on 3/6/24, 2:53 PM

    Every time I see a new language, I immediately check if it uses significant white space like Python. If it doesn’t, I sigh sadly and dismiss it.
  • by alphazard on 3/6/24, 12:57 PM

    Just so everyone knows. Graydon is not in the list of contributors on GitHub.

    https://github.com/dada-lang/dada/graphs/contributors

    https://github.com/graydon

  • by udev4096 on 3/6/24, 3:13 PM

    Not this again. How many languages do we need? I am having a good time with Go and Python!