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

161–170 of 180 posts

Re: Roc – A fast, friendly, functional language

#161

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.

I found what is «Morphic», mentioned by Richard Feldman.

It's an another experimental programming language with the static reference counting. «Morphic uses a borrow-based reference counting scheme which is able to eliminate almost all reference count increments and decrements for a large class of programs»ⓒMorphic developer team.

Site: https://morphic-lang.org/

Paper: https://dl.acm.org/doi/10.1145/3591260

Re: Roc – A fast, friendly, functional language

#162

Post by Mawr »

ReleaseCandidat wrote: post #117
Georgelemental wrote: post #113

Earlier quoted context omitted.

Rust takes the "at least annotate all your function signatures" approach as well. It's essential for making borrow-checking tractable (for both the compiler and the programmer).

Rust has the "you must annotate your functions signatures, because there is no global type inference possible" approach.

It's a carefully chosen, deliberate design decision [1]. Interface boundaries should be stable.

[1] https://steveklabnik.com/writing/rusts-golden-rule

Re: Roc – A fast, friendly, functional language

#164

Post by elbear »

ReleaseCandidat wrote: post #109
elbear wrote: post #99

Earlier quoted context omitted.

A few of the Haskell ones are introduced by extensions, so they're not part of the language proper.

Yes, I know. Same for OCaml with PPXs. That was just to show that even Haskell has many, even though most operators aren't keywords but "normal" infix functions (of type classes).

> even though most operators aren't keywords but "normal" infix functions

yes, that is also important to mention

Re: Roc – A fast, friendly, functional language

#165

Post by Yoric »

yashrk wrote: post #161
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.

I found what is «Morphic», mentioned by Richard Feldman. It's an another experimental programming language with the static reference counting. «Morphic uses a borrow-based reference counting scheme which is able to eliminate almost all reference count increments and decrements for a large class of programs»ⓒMorphic developer team. Site: https://morphic-lang.org/ Paper: https://dl.acm.org/doi/10.1145/3591260

Thanks, it makes sense now!

I think I've read a post by Niko Matskakis (Rust lead) who suggested doing something similar. That would be exciting to see!

Re: Roc – A fast, friendly, functional language

#167

Post by redbar0n »

naasking wrote: post #163

Their FAQ is an eminently reasonable breakdown of their choices: https://github.com/roc-lang/roc/blob/main/FAQ.md I don't fully agree with all of the reasoning, but it's a reasonable position to stake.

Yes, it was exceptionally well written and argued! Did you find any of the arguments faulty, or lacking counterweight? Or do you just weigh some drawbacks less harshly so you want some of the features they decided against?

Re: Roc – A fast, friendly, functional language

#168

Post by redbar0n »

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.

Carp - https://github.com/carp-lang/Carp - "A statically typed lisp, without a GC, for real-time applications." where it's "Ownership tracking enables a functional programming style while still using mutation of cache-friendly data structures under the hood".

Re: Roc – A fast, friendly, functional language

#169

Post by naasking »

redbar0n wrote: post #167
naasking wrote: post #163

Their FAQ is an eminently reasonable breakdown of their choices: https://github.com/roc-lang/roc/blob/main/FAQ.md I don't fully agree with all of the reasoning, but it's a reasonable position to stake.

Yes, it was exceptionally well written and argued! Did you find any of the arguments faulty, or lacking counterweight? Or do you just weigh some drawbacks less harshly so you want some of the features they decided against?

I pretty much only really disagree about HKP. Not specifically because I want monads, but having used C# for 20 years now, I feel it every time I try to create reusable abstractions, and so much of the ecosystem would be simplified had HKP been available. I don't see any issue with not having a monad in the std lib and having a Roc sub-community create their own extension library.

I do suspect there's a way to solve the issues they raise with currying, but haven't thought about it enough to be sure.

The only other complaint I have that isn't addressed in the FAQ is the choice to use '\' to start a lambda. I've never liked that syntax anytime I've seen it. '->' as a infix operator is sufficient to disambiguate, so given all of the other good ergonomic choices they've made, that just kinda sticks in my craw.

Re: Roc – A fast, friendly, functional language

#170

Post by redbar0n »

laerus wrote: post #105

camelCase instead of snake_case is such a turnoff :(

Even coming from Ruby, which uses snake_case, I've come to prefer camelCase over both snake_case or kebab-case. Since camelCase compacts more into a single token (separating it from what comes after), and it better passes the squint test.
Post reply on HN