Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dada, an experimental new programming language

dada-lang.org

Post reply on HN
Print view View original

231–240 of 428 posts

Re: Dada, an experimental new programming language

#231

Post by helsinki »

malermeister wrote: post #37
happens wrote: post #25

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.

You might like Kotlin. It'll also give you access to the entire JVM ecosystem.

Is that a blessing or a curse?

Re: Dada, an experimental new programming language

#232

Post by dartos »

School-Cotton wrote: post #40
dartos wrote: post #32

Earlier quoted context omitted.

That sounds… bad? The whole point of rusts type system is to try to ensure safe memory usage. Opinions are opinions, but if I’m letting my runtime handle memory for me, I’d want a lighter weight, more expressive type system.

I’m assuming by rust’s type system they mean without lifetimes. In which case it’s existed in lots of GC languages (OCaml, Haskell) but no mainstream ones. It isn’t really related to needing a GC or not.

Without lifetimes, Pins, Boxes, Clone, Copy, and Rc (Rc as part of the type itself, at least)

Re: Dada, an experimental new programming language

#233

Post by weatherlight »

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…

Have you played at all with Gleam?

https://gleam.run/cheatsheets/gleam-for-rust-users/

Re: Dada, an experimental new programming language

#234

Post by gary17the »

wredue wrote: post #203
gary17the wrote: post #108

Earlier quoted context omitted.

No, not really. Firstly, there is no significant "friction" to using Rust smart pointers and internal mutability primitives, as those constructs have been added to Rust for a reason: to solve certain borrow checker edge cases (e.g., multiply interconnected data structures), so they are treated by the Rust ecosystem as first-class citizens. Secondly, those constructs make a pretty good educational tool. By the time pe…

I find quite a lot of friction in being demanded to understand all of the methods, what they do, when you’d use them, why you’d choose one over another that does a slightly different thing, but maybe still fits. The method documentation alone in reference counting is more pages than some entire programming languages. That’s beside the necessary knowledge for using it.

I don't think it's necessary to understand every single `Rc` method[1] to use Rust smart pointers to learn Rust. Perhaps try a different learning resource such as "Rust By Example"[2], instead?

[1] https://doc.rust-lang.org/std/rc/struct.Rc.html

[2] https://doc.rust-lang.org/rust-by-example/std/rc.html

Re: Dada, an experimental new programming language

#235

Post by smallnamespace »

wredue wrote: post #201
couchand wrote: post #123

Earlier quoted context omitted.

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

The problem a lot of people have with DSLs is… well, just look at a prime example: SAS. If you’re an experienced programmer coming in to SAS, your vocabulary for the next LONG time is going to consist primarily of “What The Fuck is this shit?!?”

What do you mean? Computations very naturally organize into batches of 40 cards each.

Re: Dada, an experimental new programming language

#236

Post by geodel »

happens wrote: post #25

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.

> but in the end it's adoption and the ecosystem that keeps me from using them.

Well, since you can't really use without high adoption even if something comes up with all features you want, you still won't be able to use it for decades or longer.

Re: Dada, an experimental new programming language

#237

Post by steveklabnik »

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.

A long time ago, it did have specialized syntax! We fought to remove it. There’s a variety of reasons for this, and maybe it would make sense in another language, but not Rust.

Re: Dada, an experimental new programming language

#238

Post by dartos »

sanderjd wrote: post #103
dartos wrote: post #32

Earlier quoted context omitted.

That sounds… bad? The whole point of rusts type system is to try to ensure safe memory usage. Opinions are opinions, but if I’m letting my runtime handle memory for me, I’d want a lighter weight, more expressive type system.

> The whole point of rusts type system is to try to ensure safe memory usage. It isn't though. The whole trait system is unnecessary for this goal, yet it exists. ADTs are unnecessary to this goal, yet they exist. And many of us like those aspects of the type system even more than those that exist to ensure safe memory usage.

It is the first and foremost goal of every language choice in rust.

I think traits muddy that goal, personally, but their usefulness outweighs the cost (Box)

I should’ve probably said “the whole point of rusts type system, other than providing types and generics to the language”

But I thought that went without saying

Re: Dada, an experimental new programming language

#239

Post by weatherlight »

happens wrote: post #25

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.

checkout Gleam.

Re: Dada, an experimental new programming language

#240

Post by naasking »

klabb3 wrote: post #215
naasking wrote: post #180

Earlier quoted context omitted.

It does make sense if you want other types of resources, like time and memory, to also be part of the contract. Async annotations let you do this but hiding the asynchrony does not.

Make sense might be an overstatement but ok. Then why do functions with sync syscalls (ie file, timers or mutex ops) not expose the same contractual differences? They’re just regular functions in most languages including Rust. Perhaps anything involving syscalls should be exposed and contractual. I doubt it, but maybe it’s important for some obscure ownership-of-resources reason. But then why the inconsistency betwee…

> Then why do functions with sync syscalls (ie file, timers or mutex ops) not expose the same contractual differences? They’re just regular functions in most languages including Rust.

Because the kernel doesn't expose that contract, so they don't have that behaviour.

> The only difference is whether the runtime sits in the kernel or in user space.

In other words, what contracts you have control over and are allowed to provide.

> My take has been for years that this is throwing complexity over the fence and shaming users for not getting it.

I'm sure how we got here would seem baffling if you're going to just ignore the history of the C10K problem that led us to this point.

You can of course paper over any platform-specific quirks and provide a uniform interface if you like, at the cost of some runtime overhead, but eliminating as much of this kind of implicit runtime overhead as possible seems like one of Rust's goals. Other languages, like Go, have a different set of goals and so can provide that uniform interface.

It's probably also possible to have some of that uniform interface via a crate, if some were so inclined, but that doesn't mean it should be in the core which has a broader goal.

Post reply on HN