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

Roc – A fast, friendly, functional language

roc-lang.org

Post reply on HN
Print view View original

151–160 of 180 posts

Re: Roc – A fast, friendly, functional language

#151

Post by davidatbu »

rtfeldman wrote: post #90
davidatbu wrote: post #80

I'm super keen to see how Roc pans out, because it sits at an (IMO) riveting spot in the space of PL design tradeoffs: 1. The typesystem will be sound, ML-like, and so simple that any code that doesn't interact with external data will not need _any_ type annotations. 2. An aim to make it the fastest managed compiled lang around (faster than golang). 3. Functional. 4. A focus on fast compile times from the beginning (…

Glad you've been enjoying Software Unscripted, thank you for the kind words! > 1. Whether they'll support macros, The plan is not to support macros. A major reason is that macros tend to conflict with editor tooling, and I definitely have big plans for Roc's editor tooling! > 2. Whether their decision to build a whole new IDE will take away from the work that will go into an LSP (it will take a lot to pry away neovim…

> The plan is not to support macros.

Gotcha. In every lang I've used a lot, I've found meta-programming (compile-time or dynamic) to be valuable (and often indespensible). I can imagine that a lang like Elm that is domain-specific can do fine without the expressive power of macros, but I struggle to imagine that for a general-purpose lang like Roc.

I'm sure you've ruminated on this, so I'm excited to see how it all pans out.

Maybe a Software Unscripted episode with someone who's written a lot of macros is in order? :) David Tolnay (serde maintainer) would be great!

Re: Roc – A fast, friendly, functional language

#153

Post by rowyourboat »

rtfeldman wrote: post #90
davidatbu wrote: post #80

I'm super keen to see how Roc pans out, because it sits at an (IMO) riveting spot in the space of PL design tradeoffs: 1. The typesystem will be sound, ML-like, and so simple that any code that doesn't interact with external data will not need _any_ type annotations. 2. An aim to make it the fastest managed compiled lang around (faster than golang). 3. Functional. 4. A focus on fast compile times from the beginning (…

Glad you've been enjoying Software Unscripted, thank you for the kind words! > 1. Whether they'll support macros, The plan is not to support macros. A major reason is that macros tend to conflict with editor tooling, and I definitely have big plans for Roc's editor tooling! > 2. Whether their decision to build a whole new IDE will take away from the work that will go into an LSP (it will take a lot to pry away neovim…

> The plan is not to support macros

How do you plan on supporting meta-programming, then? Code-generation as a first class citizen a la .NET?

Re: Roc – A fast, friendly, functional language

#154

Post by 3836293648 »

Roc is definitely interesting and I like the platforms idea. The error messages are clear, but calling them friendly is clearly not something they've reached yet.

Just installing and trying to reach a valid hello world going just by the errors and it's actively rude within three error messages.

Also it's missing the final newline

Re: Roc – A fast, friendly, functional language

#155

Post by yashrk »

Yoric wrote: post #150
yashrk wrote: post #142

Earlier quoted context omitted.

Rc and Arc traits are implementations of the _runtime_ reference counters. Runtime reference counting is sometimes less efficient than tracing GC. But Roc counts references in _compile_ time. So it's like _usual_ (not wrapped in Rc ) values in Rust. But in Rust the value is deleted from the heap when the stack frame with the _only_ link to it («the owner») is deleted. And in Roc the value is deleted from the heap, wh…

Do you have a written source for this? What you're describing is nice, but I can see so many basic cases in which it doesn't work, at least not without a borrow analysis much more sophisticated than Rust's, that I imagine I'm missing something. Example: A linked list. Nitpick: Rc and Arc are not traits.

Two main papers about this topic AFAIK are: «Counting Immutable Beans» by Sebastian Ullrich and Leonardo de Moura (https://arxiv.org/pdf/1908.05647.pdf) and «Perceus: Garbage Free Reference Counting with Reuse» by Alex Reinking, Ningning Xie,Leonardo de Moura, Daan Leijen (https://dl.acm.org/doi/pdf/10.1145/3453483.3454032).

See also Anton Felix Lorenzen's master thesis: https://antonlorenzen.de/master_thesis_perceus_borrowing.pdf

Mr. Feldman also mentioned some «alias analysis» library «Morphic Solver» from Berkley University, but I cannot find anything about it.

BTW compile time reference counting was already discussed on HN, for example here: https://news.ycombinator.com/item?id=19567666

> Example: A linked list.

IIUC recursive data structures like linked list and trees are not the problem for the static reference counting. Mutation (and, therefore, link cycles) _is_ a problem, but Roc is a clean language with no explicit mutation. =)

> I can see so many basic cases in which it doesn't work

Sometimes runtime reference counting is still used. But, of course, in way more complex situations than just processing a linked list.

> Nitpick: Rc and Arc are not traits.

Of course, my fault. I haven't written on Rust for a long time (and never used this language in a serious project).

edit: link added

Re: Roc – A fast, friendly, functional language

#156

Post by tome »

bbkane wrote: post #140
lambda_garden wrote: post #33

Earlier quoted context omitted.

Some in the ML community think a simpler language has advantages over a more expressive one, in some cases. For example: https://github.com/fsharp/fslang-suggestions/issues/243#issu...

Not just the ML community. Go's simplicity is often derided, but I think the best in class tooling (dev tooling like gopls, golangci-lint, deployment tooling like ServiceWeaver, Goreleasor, etc) and easy understandability more than make up for "what yuu can't do"

Not just in the Go community! Everyone believes in "as simple as possible". The disagreement is about "but no simpler".

Re: Roc – A fast, friendly, functional language

#157

Post by okkdev »

catgary wrote: post #24
okkdev wrote: post #7

Big fan of Richard Feldman's talks and Roc is one of my most anticipated upcoming language besides Gleam. Great to see that there's now a nice Roc website. Looking forward to how the language evolves!

I know Koka is more of a research project than anything else, but I think it’s by far the most interesting. Moving to effect handlers, the Perseus ARC algorithm, and identifying “functional-but-in-place” algorithms all feel like game changers.

Oh I completely forgot about Koka, I remember looking at it a couple years ago. I'll have to give it a go again. :)

Re: Roc – A fast, friendly, functional language

#158

Post by Yoric »

yashrk wrote: post #155
Yoric wrote: post #150

Earlier quoted context omitted.

Do you have a written source for this? What you're describing is nice, but I can see so many basic cases in which it doesn't work, at least not without a borrow analysis much more sophisticated than Rust's, that I imagine I'm missing something. Example: A linked list. Nitpick: Rc and Arc are not traits.

Two main papers about this topic AFAIK are: «Counting Immutable Beans» by Sebastian Ullrich and Leonardo de Moura ( https://arxiv.org/pdf/1908.05647.pdf ) and «Perceus: Garbage Free Reference Counting with Reuse» by Alex Reinking, Ningning Xie,Leonardo de Moura, Daan Leijen ( https://dl.acm.org/doi/pdf/10.1145/3453483.3454032 ). See also Anton Felix Lorenzen's master thesis: https://antonlorenzen.de/master_thesis_per…

Thanks!

Re: Roc – A fast, friendly, functional language

#159

Post by trealira »

christophilus wrote: post #103
shortrounddev2 wrote: post #44

Has anyone else noticed that functional languages go heavy on the special keywords and operators? It feels like theres a larger cognitive load (more specific keywords to memorize) when learning languages like F# or OCaml compared to C or Python or Java

Clojure doesn't. I'd really, really love to see a fast, statically-typed, functional lisp.

You might like Coalton, which is statically typed, functional language embedded within Common Lisp. However, it hasn't reached version 1.0 yet.

https://github.com/coalton-lang/coalton

Post reply on HN