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

141–150 of 180 posts

Re: Roc – A fast, friendly, functional language

#141

Post by yashrk »

1letterunixname wrote: post #106
yashrk wrote: post #9

If you are interested, «why yet another programming language?». The unique selling point of Roc is clever optimization to convert purely functional source code to deep-imperative fast machine code, while keeping all the correctness of functional algorithms. See this video of Richard Feldman for details — «Outperforming Imperative with Pure Functional Languages»: https://www.youtube.com/watch?v=vzfy4EKwG_Y Among those…

> convert purely functional source code to deep-imperative fast machine code, while keeping all the correctness of functional algorithms. All functional language compilers, interpreters, and/or runtimes ultimately have to do this by definition. The efficiency of transpilation varies widely.

Definition of resulting code as _deeply_ imperative was crucial in my phrase.

The only «sine qua non» optimization through opportunistic mutablity is AFAIK tail call optimization. But it is probably too well-known to call it «clever optimization» in 2023.

But, for example, applying a function to a list will produce the code allocating new list in, say, OCaml and Haskell, at least by default. And Roc will produce the code for mutating the list in-place _from the source code with the same semantic_ (see example for the Quicksort algorithm in the video above).

Compile-time lifetime analysis (that probably is not needed at all in functional languages with GC) and widely used unboxed values are way not common in functional language implementations. For example, in OCaml those features are still experimental (and probably never will be used by default, as in Roc).

Re: Roc – A fast, friendly, functional language

#142

Post by yashrk »

Yoric wrote: post #134
yashrk wrote: post #9

If you are interested, «why yet another programming language?». The unique selling point of Roc is clever optimization to convert purely functional source code to deep-imperative fast machine code, while keeping all the correctness of functional algorithms. See this video of Richard Feldman for details — «Outperforming Imperative with Pure Functional Languages»: https://www.youtube.com/watch?v=vzfy4EKwG_Y Among those…

> - static reference counting (no GC, like in Rust, but with no borrowing and borrow problems); Does this mean that it's somewhat equivalent to Rust with everything behind a `Rc` or `Arc`?

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, when the _last_ link to it leaves the stack.

So we have the machine code _almost_ as efficient as a Rust-produced machine code, but the source code with a much simpler semantics.

Re: Roc – A fast, friendly, functional language

#144

Post by rtfeldman »

MrJohz wrote: post #132
rtfeldman wrote: post #121

Earlier quoted context omitted.

Oh I totally agree that it's a good idea to annotate top-level functions even if you don't have to, and better compiler error messages is one of the benefits of doing that. Personally I basically always choose to annotate them except in the very specific situation of writing beginner introductory materials, when it's not a given that the reader actually knows how to read the annotations yet. One of the practical bene…

> Personally I basically always choose to annotate them except in the very specific situation of writing beginner introductory materials, when it's not a given that the reader actually knows how to read the annotations yet. Having just gone through your tutorial (albeit not yet with a computer in hand, that's the next step), might I suggest putting those annotations in anyway? I suspect most of the people reading the…

Thanks for the kind words, and thanks for the feedback!

> Is there an explicit type hole mechanism as well, for getting the compiler to spit out the types it expects?

Not currently, although you can write `_` for any part of a type annotation that you don't want to bother annotating (which means that part of the type will be inferred as if you hadn't written any annotation for it), and we either have or want to have "hover to see the type" in editor extensions.

Re: Roc – A fast, friendly, functional language

#146

Post by zem »

fouronnes3 wrote: post #110
surprisetalk wrote: post #2

For those out of the loop, Roc was spearheaded by Richard Feldman, who made major contributions to Elm. Feldman is such a charming guy! I highly recommend checking out his podcast Software Unscripted and watching his many talks on YouTube. The recent SU episode with Brian Carroll talking about WASM in Roc was a great listen. Roc also has an active community on zulip, so consider stopping by :) [1] https://twitter.com…

What happened to Elm by the way?

if nothing else it popularised TEA ("the elm architecture"), which a lot of other frontend frameworks have picked up on.

Re: Roc – A fast, friendly, functional language

#148

Post by jcuenod »

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…

+1 for Software Unscripted! I know barely anything about compilers, but I really enjoy being a fly on the wall of these conversations :)

Re: Roc – A fast, friendly, functional language

#149

Post by darthrupert »

rtfeldman wrote: post #18
satvikpendem wrote: post #13

I don't know, after having used Elm and seeing the community accused of "hostile attacks" by one of the main contributors (who is the creator of Roc now) [0], I don't feel that it's worth my time to put into learning it, even if it is objectively good; I simply cannot know what the creators will do (or refuse to do, in the case of Elm) in the future, especially in a BDFL governance paradigm. This was in fact why I st…

Wow, this is depressing to read. :( 5 years ago I was upset and posted a comment that was unfairly harsh to another commenter. I apologized at the time, and I meant it. I definitely should not have made the harsh comment that I did. It was wrong. There's no excuse for my having written it. There are a lot of people working on Roc other than me. I'm not even the top committer anymore. [0] I hope you can find it in you…

Come join the open source software community. Everything you say will be used against you in the public court, forever.

Re: Roc – A fast, friendly, functional language

#150

Post by Yoric »

yashrk wrote: post #142
Yoric wrote: post #134

Earlier quoted context omitted.

> - static reference counting (no GC, like in Rust, but with no borrowing and borrow problems); Does this mean that it's somewhat equivalent to Rust with everything behind a `Rc` or `Arc`?

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.

Post reply on HN