Dada, an experimental new programming language • Hacker News Board

Re: Dada, an experimental new programming language

#121

Post by cmrdporcupine » Wed, Mar 06, 2024, 1:51 PM UTC

sanderjd wrote: post #107

afavour wrote: post #55

Earlier quoted context omitted.

I like Rust’s type system just fine but for me it’s types combined with language features like matching that draw me to Rust. When I was still learning I made an entire project using Arc with no lifetimes at all and it was actually a great experience, even if it’s not the textbook way to use Rust.

Honestly, I think syntax for Arc (and/or Rc or some generalization of the two) and more "cultural" support for writing in that style would have benefitted rust back when 1.0 was being finalized. But I think the cow is out of the barn now on what rust "is" and that it isn't this.

Yes, if you think about it, it's a bit weird that async gets first syntactical class treatment in the language but reference counting does not. A similar approach of adding a syntactical form but not mandating a particular impl could have been taken, I think.

Same for Box, but in fact Rust went the opposite way and turfed the Box ~ sigil.

Which I actually feel was a mistake, but I'm no language designer.

Re: Dada, an experimental new programming language

#122

Post by Groxx » Wed, Mar 06, 2024, 1:52 PM UTC

amw-zero wrote: post #73

gary17the wrote: post #53

Earlier quoted context omitted.

If you do not want to mess with Rust borrow checker, you do not really need a garbage collector: you can rely on Rust reference counting. Use 1.) Rust reference-counted smart pointers[1] for shareable immutable references and 2.) Rust internal mutability[2] for non-shareable mutable references checked at runtime instead of compile time. Effectively, you will be writing kind of verbose Golang with Rust's expressivenes…

A language has a paved road, and when you go off of that road you are key with extreme annoyance and friction every step of the way. You’re telling people to just ignore the paved road of Rust, which is bad advice.

It's telling people to avoid the famously hard meme-road.

Mutexes and reference counting work fine, and are sometimes dramatically simpler than getting absolutely-minimal locks like people seem to always want to do with Rust.

Re: Dada, an experimental new programming language

#123

Post by couchand » Wed, Mar 06, 2024, 1:52 PM UTC

sanderjd wrote: post #93

benrutter wrote: post #65

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 + si…

In college, my programming languages class used a language called "Mystery" (I believe created by my professor), which was configurable . Assignments would be like "write some test programs to figure out whether the language is configured to use pass-by-value or pass-by-reference". And there were a bunch of other knobs that could be turned, and in each case, the idea was that we could figure out the knob's setting by…

Don't be so quick to discount DSLs. Sure, you don't want a half-baked DSL when some simple imperative code would do. But if you watch your API evolve into an algebra and then don't formalize it with a DSL you might be leaving powerful tools for understanding on the table.

A poor-fitting language is terrible for abstract thinking, on the other hand an internally-consistent and domain appropriate language can unlock new ways of looking at problems.

I'd highly recommend Martin Fowler's work on DSLs to see how you can apply these techiques to large projects.

Re: Dada, an experimental new programming language

#124

Post by couchand » Wed, Mar 06, 2024, 1:55 PM UTC

ericyd wrote: post #92

thesz wrote: post #85

Earlier quoted context omitted.

> actually creating a working language is a big overhead Languages, with first class values, pattern matching, rich types, type inference and even fancy RTS, often can be embedded in Haskell. For one example, it is very much possible to embed into Haskell a Rust-like language, even with borrow checking (which is type-checking time environment handling, much like linear logic). See [1], [2] and [3]. [1] http://blog.si…

Are you suggesting that creating a new programming language from scratch is a trivial exercise? If yes, wow. If no, I think the intention of your comment could be more clear, particularly regarding the quote you took from the original comment.

I suspect the GP was merely suggesting a less-costly alternative. Perhaps building a complete standalone compiler or interpreter is hard, but we're all designing APIs in our programming languange of choice day in and day out.

Both strategies are very hard, but one of then is "build a prototype in a weekend" hard and one of them is "build a prototype is a month" hard.

Re: Dada, an experimental new programming language

#125

Post by cmrdporcupine » Wed, Mar 06, 2024, 1:56 PM UTC

sanderjd wrote: post #118

bradrn wrote: post #41

Earlier quoted context omitted.

Or Haskell!

Ocaml, yes, but not haskell. It does include these things the parent wants, but similar to how Rust ends up being quite "captured" by its memory semantics and the mechanics necessary to make them work, haskell is "captured" by laziness and purity and the mechanics necessary to make those work. Also, syntax does actually matter, because it's the first thing people see, and many people are immediately turned off by unf…

I learned SML/NJ and OCaml a bit over 20 years ago and liked them, but when I tried my hand at Haskell my eyes glossed over. I get its power. But I do not like its syntax, it's hard to read. And yes, the obsession with purity.

Re: Dada, an experimental new programming language

#126

Post by gary17the » Wed, Mar 06, 2024, 1:57 PM UTC

zozbot234 wrote: post #106

gary17the wrote: post #53

Earlier quoted context omitted.

If you do not want to mess with Rust borrow checker, you do not really need a garbage collector: you can rely on Rust reference counting. Use 1.) Rust reference-counted smart pointers[1] for shareable immutable references and 2.) Rust internal mutability[2] for non-shareable mutable references checked at runtime instead of compile time. Effectively, you will be writing kind of verbose Golang with Rust's expressivenes…

This is what Swift does, and it has even lower performance than tracing GC. (To be clear, using RC for everything is fine for prototype-level or purely exploratory code, but if you care about performance you'll absolutely want to have good support for non-refcounted objects, as in Rust.)

An interesting point, but I would have to see some very serious performance benchmarks focused specifically on, say, RC Rust vs. GC Golang in order to entertain the notion that an RC PL might be slower than a GC PL. Swift isn't, AFAIK, a good yardstick of... anything in particular, really ;) J/K. Overall PL performance is not only dependent on its memory management, but also on the quality of its standard library and its larger ecosystem, etc.

Re: Dada, an experimental new programming language

#127

Post by n2d4 » Wed, Mar 06, 2024, 1:58 PM UTC

sanderjd wrote: post #120

yamrzou wrote: post #6

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.

Also it immediately makes me wonder what `await` is... Is it a reference to a field of whatever the `print()` method is returning? Is it calling a method? If it's a method call without parentheses, how do I get a reference to a method without calling it? (These kinds of questions are just unavoidable though; everyone will have these little pet things that they subjectively prefer or dislike.)

They borrowed it from Rust: `.await` is special syntax, roughly equivalent to `await print(...)` in other languages.

https://rust-lang.github.io/async-book/01_getting_started/04...

Re: Dada, an experimental new programming language

#128

Post by color_me_not » Wed, Mar 06, 2024, 1:59 PM UTC

galangalalgol wrote: post #66

overstay8930 wrote: post #39

Earlier quoted context omitted.

You have awoken the ocaml gang

That is probably the closest, especially if they add ownership. That was the rust inventor's original goal, not just safety at minimal performance cost. I think ownership should be a minimal requirement for any future language, and we should bolt it on to any that we can. Fine grained permissions for dependency trees as well. I like static types mostly because they let me code faster, not for correctness, strong type…

There's no ownership concept, but in the JaneStreet fork, there is something resembling lifetimes[1].

[1]: https://blog.janestreet.com/oxidizing-ocaml-locality/

Re: Dada, an experimental new programming language

#129

Post by n2d4 » Wed, Mar 06, 2024, 2:00 PM UTC

MatthiasPortzel wrote: post #117

baq wrote: post #10

Earlier quoted context omitted.

I'd say you want something like 'debug_msg()' for this. 'print()' should be async because it does IO. In the real world most likely you'd see the output once you yield.

> 'print()' should be async because it does IO What if I want to do synchronous IO?

Just from glancing over the docs, that doesn't seem supported:

> 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.

Good riddance, IMO — never been a fan of blocking IO. Dada does have threads though, so I wonder how that works out. (Forcing async/await makes a lot more sense in JavaScript because it's single-threaded.)

Re: Dada, an experimental new programming language

#130

Post by couchand » Wed, Mar 06, 2024, 2:03 PM UTC

color_me_not wrote: post #113

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 exec…

I suspect they're heavily relying on intuition coming from Rust, where both of those forms are okay. The one from TFA is sugar for your version. This works fine as long as there is only a single await point, otherwise you have to transform the syntax into a bind, which you might not be able to legally do manually (in Rust at least) if you hold a borrow across the await point.