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

341–350 of 428 posts

Re: Dada, an experimental new programming language

#341

Post by mike_hearn »

emporas wrote: post #42

The absence of GC, makes embedded Rust a joy. It can be easily attached to other programs like Erlang with NIFs, Javascript and web pages with Web Assembly and Emacs with command line execution. Micro-controllers as well of course. 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…

Garbage collection doesn't make program startup slow. Look at Go, or Java compiled with native-image.

Re: Dada, an experimental new programming language

#342

Post by avianlyric »

gpderetta wrote: post #260
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.

Why is I/O so special that need to be explicitly marked across the call stack? What about memory allocation, that can arbitrarily delay a process? Should allocating functions be transitively annotated? What about functions that lock a mutex or wait on some synchronisation primitive? What about those that signal a synchronization primitive? What about floating points, that can raise exceptions? What about panicking fu…

I/O tends to be the slowest operations your software can perform, and also the riskiest, because you’re dependent on so many different underlying components working correctly. Everything from the kernel syscall, to the device driver, the device itself, and potentially devices attached to device that’s attached to your computer. In short IO operations are a complete shit show of possible problems, that can all occur while your software is suspended in a syscall.

Memory allocation by comparison are extremely quick, and generally very reliable. Your system’s memory subsystem isn’t a smorgasbord of different memory drivers and controllers. It one memory system, taking to one memory controller, via an API that been standardised for decades, and where every implementation of that API is basically tested to the extreme every time a computer turns on. That’s assuming your language even bother asking the OS for memory on every allocation, which it probably doesn’t. Most language runtimes request large blocks of memory from the OS, then allocate out of those block on demand. So most “allocating functions” never result in syscall at all.

Re: Dada, an experimental new programming language

#343

Post by nu11ptr »

couchand wrote: post #134
nu11ptr wrote: post #114

Earlier quoted context omitted.

Agreed, it seems weird to me to avoid garbage collection in a high level language. It is one thing to use escape analysis to avoid creating garbage, but mallocing every object is going be slower than a well tuned GC.

> mallocing every object So don't do that then? Put most things on the stack. It's far faster than any allocation.

In the context of escape analysis (which would place many objects on the stack) that should have read: mallocing every _heap_ object

Re: Dada, an experimental new programming language

#344

Post by munificent »

jerf wrote: post #174
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…

"Gradual typing is interesting, but I wonder if necessary." Open question: Are there any languages that can be used in a (decent [1]) REPL, that are strongly typed, but do not have Hindley–Milner-based type inference? We have multiple concrete proofs that you can have a REPL with Hindley-Milner inference, but I'm curious if this is perhaps a concession to the difficulty of a strongly-typed REPL without a deeply infer…

I'm not aware of any technical reasons why a given language would profoundly struggle to have a good REPL. I think it's mostly a matter of culture where REPLs aren't a priority in some language ecosystems because programmers there don't generally work that way.

Re: Dada, an experimental new programming language

#345

Post by gpderetta »

avianlyric wrote: post #342
gpderetta wrote: post #260

Earlier quoted context omitted.

Why is I/O so special that need to be explicitly marked across the call stack? What about memory allocation, that can arbitrarily delay a process? Should allocating functions be transitively annotated? What about functions that lock a mutex or wait on some synchronisation primitive? What about those that signal a synchronization primitive? What about floating points, that can raise exceptions? What about panicking fu…

I/O tends to be the slowest operations your software can perform, and also the riskiest, because you’re dependent on so many different underlying components working correctly. Everything from the kernel syscall, to the device driver, the device itself, and potentially devices attached to device that’s attached to your computer. In short IO operations are a complete shit show of possible problems, that can all occur w…

Memory allocation can literally fail for reasons completely outside the control of the application (for example because the OS enforces a maximum virtual memory size on the application).

The fact the most allocations are fulfilled via internal pools is immaterial, at some point the allocator needs to ask the OS for more memory. This parallels the way that most I/O doesn't actually performs syscalls because of buffering.

Also allocations might end up performing arbitrary I/O indirectly if the OS needs to flush dirty pages to disk to free up memory.

Re: Dada, an experimental new programming language

#346

Post by gpderetta »

avianlyric wrote: post #336
MatthiasPortzel wrote: post #111

Earlier quoted context omitted.

It’s not an end goal, maybe, but if I’m writing a complex program and I want to print to the console for logging or debugging or status, I shouldn’t have to think about the design of that print-call. I would like to be able to focus on the main complexity of the program, rather than worry about boiler-plate complexity every time I want to print.

You seem to be making the assumption that in other languages calling print is a blocking function that guarantees the printing of a string. Which it isn’t. In python print adds your string to the stdout buffer, which eventually gets written out to the console. But it not guaranteed, if you want that guarantee you need to call flush on the stdout IO handler. Dada has taken the approach of making blocking IO operations…

Would waiting on a mutex or signaling a semaphore require explicit awaiting in Dada? What about faulting in an mmaped memory buffer?

Re: Dada, an experimental new programming language

#347

Post by munificent »

emporas wrote: post #42

The absence of GC, makes embedded Rust a joy. It can be easily attached to other programs like Erlang with NIFs, Javascript and web pages with Web Assembly and Emacs with command line execution. Micro-controllers as well of course. 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…

GC doesn't affect startup time.

The slow startup you associate with GC language implementations like ones for Java and JavaScript mostly comes from JIT warmup.

Re: Dada, an experimental new programming language

#349

Post by sanderjd »

cmrdporcupine wrote: post #173
sanderjd wrote: post #151

Earlier quoted context omitted.

Exactly right. I quite like haskell in theory, but in practice I quite dislike both reading and writing it. But I like ocaml both in theory and practice (also in part due to having my eyes opened to SML about 20 years ago).

I actually preferred SML/NJ when I played with writing it, but OCaml "won" in the popularity contest. Some of the things that made OCaml "better" (objects, etc.) haven't aged well, either. Still with OCaml finally supporting multicore and still getting active interest, I often ponder going back and starting a project in it someday. I really like what I see with MirageOS. These days I just work in Rust and it's Ok.

Yep, right there with you. OCaml was only ever better in my view because it had developed enough libraries to be an actual pragmatic choice, unlike the other languages in that family. And yep, Rust is perfectly good too, IMO, but I do find that I rarely-to-never actually care about all the zero-cost abstractions that make it "hard" to use.

Re: Dada, an experimental new programming language

#350

Post by sanderjd »

kaba0 wrote: post #312
sanderjd wrote: post #109

Earlier quoted context omitted.

Ha, no. Scala does contain this language the parent described, but alongside the huge multitudes of other languages it also contains.

Scala is an absolutely small language. It is just very expressive, but its complexity is quite different than, say, Cpp’s, which has many features.

In my view you have compared it to the only other language for which it is small by comparison :) But different strokes for different folks! I have nothing against Scala, its multi-paradigm thing is cool and impressive, it just isn't for me except by way of curiosity.
Post reply on HN