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

401–410 of 428 posts

Re: Dada, an experimental new programming language

#401

Post by happens »

quadrature wrote: post #30
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’ve just described scala.

It's a personal preference but I'm not a big fan of JVM languages - big startup costs and not having one "true" runtime that is just compiled into the binary are my main reasons. I've spent so much time fiddling with class paths and different JRE versions...

Re: Dada, an experimental new programming language

#402

Post by happens »

dartos wrote: post #32
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.

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.

By "rusts type system" I mean enums with exhaustive pattern matching and associated structs, generics, conventional option and results types, and so on. None of that necessarily has anything to do with lifetimes as far as I understand.

Re: Dada, an experimental new programming language

#403

Post by happens »

cmrdporcupine wrote: post #34
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.

... so OCaml or StandardML then

I do like the underlying ideas, and OCaml has been on my radar for a while. However, from my experience, functional languages with a big F always tend to feel a bit too "academic" when writing them to gain enough mainstream adoption.

Imperative code with functional constructs seems like the most workable approach to me, which rust, go, and other languages like kotlin, crystal etc. all offer.

Re: Dada, an experimental new programming language

#404

Post by happens »

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.

I've written a lot of kotlin and it does indeed come very close! Now if only it wasn't bound to java's bytecode under the hood...

Whenever I've had to write kotlin for Android in the past I did quite enjoy it. It seems like the entire ecosystem is very enterprise-y when it comes to web though. Forced adherence to object orientedness and patterns like 100 files, 5 folders deep with 10 lines of code each keep cropping up in most kotlin projects I've seen.

Re: Dada, an experimental new programming language

#405

Post by happens »

sanderjd wrote: post #100
overstay8930 wrote: post #39

Earlier quoted context omitted.

You have awoken the ocaml gang

Yeah, ocaml is awesome! Frankly, if it had a more familiar syntax but the same semantics, I think its popularity would have exploded in the last 15 years. It's silly, but syntax is the first thing people see, and it is only human to form judgments during those moments of first contact.

Yeah, I like the underlying ideas and I can deal with the syntax, but I wouldn't expect anyone else to :-/

Re: Dada, an experimental new programming language

#406

Post by luke-stanley »

luke-stanley wrote: post #43
mtsr wrote: post #22

Earlier quoted context omitted.

Maybe it’s actually a non-leaky abstraction because it makes the async-nature explicit. The alternative is hiding it, but it’s still going to affect your code, making that effectively a leaky abstraction.

Maybe there could be something like a aprint() wrapper, if the authors wanted to make the async nature explicit? Or something else, probably not this for one of the most common things a programmer must do.

Actually, surely you'd want an async print and a synchronous print with clear labels? aprint might be interpreted as an async print, not an awaited print, which is what I meant. Maybe this goes against "everything is async". Anyhow a better name could be print_awaited, so a "print_awaited" could be used directly without the extra syntax to await it (saving some autocomplete time?), it's still long though.

Re: Dada, an experimental new programming language

#407

Post by rkangel »

mplanchard wrote: post #268
nu11ptr wrote: post #96

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

Personally I love explicit coroutines for their flexibility. It's great to be able to multiplex a bunch of IO bound operations on a single thread, defining some in chains and other to execute in parallel. It's great to be able to easily decide when I want to wait for them all to finish, to do something like `select`, or to spin them off into the background. Rust's ownership occasionally makes this a bit more of a cha…

Elixir and its Task module (https://hexdocs.pm/elixir/1.12/Task.html) is the best of both worlds here.

The fundamental concurrency system is green threads (similar to Go), which makes for a fantastic programming model where you spend your time writing linear blocking code, while actually having full parallelism. This is achieved both with the VM and the abstractions built on top like GenServers.

The Task module is a convenience that allows you to do "await" type work when that makes sense - because (as you describe) sometimes it does.

Re: Dada, an experimental new programming language

#408

Post by couchand »

jimbokun wrote: post #394
couchand wrote: post #321

Earlier quoted context omitted.

Every word you wrote is true. It's all still true if you replace "DSL" with any project and "Boring Old Language" with the competitor. This is the stopping at 90% problem somebody just posted a link to in another thread. edit: https://austinhenley.com/blog/90percent.html

No, for Boring Old Language other people have already solved those problems for you.

Regardless of how supposedly non-controversial each technical design decision is, you will find that the entire scope of them never is.

So you will always be working to bring people along to your design choices and help them understand the (relative) value, or risk forever languishing as the sole contributor.

You don't get buy-in with technology, you get buy-in with ideas.

Re: Dada, an experimental new programming language

#409

Post by gpderetta »

steveklabnik wrote: post #381
gpderetta wrote: post #362

Earlier quoted context omitted.

>>[mutexes] are just regular functions in most languages including Rust. >Because the kernel doesn't expose that contract, so they don't have that behaviour Which OS are we talking about? Linux doesn't really have mutices as primitives. You can build async mutexes on top of eventfd and soon even on top of futexes with io_uring.

I’m on mobile so it’s tough to look up the details, but IIRC at least Windows? Implementations of the standard library mutexes are here https://github.com/rust-lang/rust/tree/master/library/std/sr... And of course it’s pthreads on Linux.

Windows has a lot of mutex and signaling primitives. Some of them can be asynchronously waited on. It also has an IoRing and I wouldn't be surprised if keyed events (the local futex equivalent) will be supported in the future.

As an aside, it is interesting that rust uses pthread_mutex for its standard library mutex. GCC/libstdc++ regrets that decision as its std::mutex is now way larger than it needs to be but it is now permanently baked in the ABI. I guess rust still doesn't guarantee ABI stability so the decision could be reversed in the future.

Re: Dada, an experimental new programming language

#410

Post by couchand »

int_19h wrote: post #361
myrmidon wrote: post #161

Earlier quoted context omitted.

Panic is a perfectly proper way for a well-built program to stop execution. There is no point in juggling around Result types if a failure means that you can not recover/continue execution. That is in fact exactly what panic! is intended for [1]. [1]: https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-pa...

A failure to write to stdout should not be unexpected given that stdout is routinely redirected to files or to pipes, both of which can be suddenly closed or otherwise fail from the other direction. Yes, you can't recover in this case, but you should at least properly report the error to stderr before exiting, in a way that lets the end user (rather than app dev) properly diagnose the error. Now if you fail to write…

Woah woah woah let's not get hasty. We can have panicking and nonpanicking versions of the API (at least until somebody builds the nonpanicking version of Rust, that will be great). The panicking version is for quick, off-the-cuff usage, and the nonpanicking one for production use.

There's value in the Hello, World and println-debugging style print, even if it should be eschewed in most general contexts.

Post reply on HN