by marionauta on 3/6/24, 10:31 AM with 420 comments
by benrutter on 3/6/24, 1:03 PM
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
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
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
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
Those are two very different feelings though!
by mihaic on 3/6/24, 2:38 PM
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
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
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
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
[...]
# 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?
by Doctor_Fegg on 3/6/24, 12:50 PM
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
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
It's dynamically typed and uses lifetimes instead of a garbage collector.
by talkingtab on 3/6/24, 2:29 PM
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
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
by pxeger1 on 3/6/24, 3:24 PM
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'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
by Alifatisk on 3/6/24, 11:52 AM
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
by jamsterion on 3/6/24, 1:36 PM
by kkukshtel on 3/6/24, 6:36 PM
by couchand on 3/6/24, 12:56 PM
> 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
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
Are classes cool again?
by sn9 on 3/6/24, 10:52 PM
by zubairq on 3/6/24, 7:23 PM
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
by imjonse on 3/6/24, 1:16 PM
by greenie_beans on 3/6/24, 5:47 PM
> 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
by ubj on 3/6/24, 3:33 PM
by p0w3n3d on 3/6/24, 4:54 PM
by melodyogonna on 3/6/24, 3:41 PM
by Georgelemental on 3/6/24, 3:22 PM
by actionfromafar on 3/6/24, 12:53 PM
by VMG on 3/6/24, 12:05 PM
by Rucadi on 3/6/24, 11:51 AM
by sorenjan on 3/6/24, 2:13 PM
> Updated to use modern pronouns.
by richrichie on 3/6/24, 2:09 PM
by owenbrown on 3/6/24, 2:53 PM
by alphazard on 3/6/24, 12:57 PM
by udev4096 on 3/6/24, 3:13 PM