Dada, an experimental new programming language • Hacker News Board

Re: Dada, an experimental new programming language

#321

Post by couchand » Wed, Mar 06, 2024, 6:39 PM UTC

jimbokun wrote: post #292

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…

Yes, but then you need to be able to market your DSL and get buy-in. Otherwise you will forever be just a team of one. And then need to sell to all the stakeholders of the project the idea of trusting one person for all the development. So in addition to the skill of creating a DSL, you need the skills of thoroughly documenting it, training other people to use it, creating tools for it, and explaining the benefits in…

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

Re: Dada, an experimental new programming language

#322

Post by bastawhiz » Wed, Mar 06, 2024, 6:40 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?

Node lets you cheat with "synchronous" APIs: it stops the whole event loop. If you start making exceptions for "little" bits of IO like printing to the console or reading files, the async parts of your code are "async when someone hasn't done something synchronous". Doing a `readFileSync` even on a small file in a hot code path means you're meaningfully tanking the performance of your code.

What you're asking for is "stop running my code until I've finished printing to the console". That's what the `.await` does. Synchronous IO on `print()` would mean _everything in the whole application that logs_ suddenly blocks the whole application from doing _anything_ while the console is being written to, not just the currently running code.

If you want synchronous stop-the-world IO (like Python, where async/await is bolted on), you shouldn't choose a language based around async/await concurrency.

Re: Dada, an experimental new programming language

#323

Post by hgs3 » Wed, Mar 06, 2024, 6:43 PM UTC

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.

Re: Dada, an experimental new programming language

#324

Post by hoosieree » Wed, Mar 06, 2024, 6:43 PM UTC

weatherlight wrote: post #233

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/

This was my first thought too. I've not used it (just clicked through the tutorial) but it has a strong flavor like "Rust, but pleasant".

Re: Dada, an experimental new programming language

#325

Post by 12_throw_away » Wed, Mar 06, 2024, 6:47 PM UTC

rcxdude wrote: post #170

amw-zero wrote: post #73

Earlier quoted context omitted.

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.

Reference counting and locks often is the easy path in Rust. It may not feel like it because of the syntax overhead, but I firmly believe it should be one of the first solutions on the list, not a last resort. People get way too fixed on trying to prove to the borrow checker that something or another is OK, because they feel like they need to make things fast, but it's rare that the overhead is actually relevant.

Yes! Thank you! Dunno what it is about Rust that makes everyone forget what premature optimization is the root of all of.

Re: Dada, an experimental new programming language

#326

Post by zozbot234 » Wed, Mar 06, 2024, 6:51 PM UTC

hgs3 wrote: post #323

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.

The Rust ownership system was built to be compositional - an architecture or algorithm must not just be "safe" in isolation, it must also preserve that safety when interacting with the rest of the system, even as either part gets modified or evolves further. Practically speaking, this is where many proposed architectures that may indeed appear "safe" run into issues. (If you can't provide these guarantees, the idiomatic approach in Rust is to isolate that part within an unsafe module, and document the expectations that said module imposes wrt. the rest of the system.)

Re: Dada, an experimental new programming language

#327

Post by ericyd » Wed, Mar 06, 2024, 6:57 PM UTC

arethuza wrote: post #149

ericyd wrote: post #92

Earlier quoted context omitted.

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.

Creating a "new" programming language isn't that difficult - creating something that is interesting, elegant and/or powerful requires a lot of thought and that is difficult.

For me, creating a new programming language which is suitable for general purpose programming would be extremely hard, regardless of how novel or good it is. But, fair point that "hard" is always subjective.

Re: Dada, an experimental new programming language

#328

Post by Diris » Wed, Mar 06, 2024, 7:04 PM UTC

obeavs wrote: post #305

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…

For what it's worth, Moonbit ( https://www.moonbitlang.com/ ) is a really nice take on this. Designed by the guys who created Rescript for OCAML, but for WASM-first world.

Wow, that's nice. I didn't know about that one. Thank you for posting!

Re: Dada, an experimental new programming language

#329

Post by hgs3 » Wed, Mar 06, 2024, 7:05 PM UTC

couchand wrote: post #132

speed_spread wrote: post #75

Earlier quoted context omitted.

Garbage collection is actually faster than generic malloc for allocating memory because it can work as a simple bump allocator. And there are ways to handle collection efficiently. Malloc is also not entirely deterministic in performance because the heap can get fragmented. Either way, if latency matters you end up having to care about (de)allocation patterns at the app level.

I think most people's concern with GC is not the allocation side of it? And in any case alloca blows them all out of the water. > if latency matters you end up having to care about (de)allocation patterns at the app level. Yes, and you want tools that allow you to precisely describe your needs, which might be more difficult if a lumbering brute is standing between you and your data.

Most GC concerns surround "stop the world" tracing collectors that "pause" the program unpredictably for an indeterminate time. These collectors are bad for real-time and soft real-time applications for obvious reasons. They would do better with a reference counting collector because its GC bookkeeping is smeared predictably across the run of the program.

Most languages don't use reference counting because most applications are either one-shot console apps, GUI apps, or web apps - the latter two operate on "bursts" of input. If your app operates in "bursts" then a tracing GC is superior since you can delay collection until the app is waiting for more input. Real-time apps don't have a moment where they "wait" therefore they should prefer reference counting for its predictable performance.

You have to use the right GC algorithm for the right job, but unfortunately programming language runtimes don't usually offer a choice.

Re: Dada, an experimental new programming language

#330

Post by 63stack » Wed, Mar 06, 2024, 7:12 PM UTC

BoppreH wrote: post #63

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.

I've always wondered if global type inference wouldn't be a game changer. Maybe it could be fast enough with caching and careful language semantics? You could still have your IDE showing you type hints as documentation, but have inferred types to be more fine grained than humans have patience for. Track units, container emptiness, numeric ranges, side effects and idempotency, tainted values for security, maybe even e…

I dabbled a bit with ReasonML which has global type inference, and the error messages from the compiler became very confusing. I assume that's a big reason for not gaining more adoption.