Roc – A fast, friendly, functional language

For those out of the loop, Roc was spearheaded by Richard Feldman, who made major contributions to Elm.<p>Feldman is such a charming guy! I highly recommend checking out his podcast <i>Software Unscripted</i> and watching his many talks on YouTube.<p>The recent SU episode with Brian Carroll talking about WASM in Roc was a great listen.<p>Roc also has an active community on zulip, so consider stopping by :)<p>[1] <a href="https:&#x2F;&#x2F;twitter.com&#x2F;sw_unscripted" rel="nofollow noreferrer">https:&#x2F;&#x2F;twitter.com&#x2F;sw_unscripted</a><p>[2] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;results?search_query=richard+feldman">https:&#x2F;&#x2F;www.youtube.com&#x2F;results?search_query=richard+feldman</a><p>[3] <a href="https:&#x2F;&#x2F;www.roc-lang.org&#x2F;community" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.roc-lang.org&#x2F;community</a>

I&#x27;m super keen to see how Roc pans out, because it sits at an (IMO) riveting spot in the space of PL design tradeoffs:<p>1. The typesystem will be sound, ML-like, and so simple that any code that doesn&#x27;t interact with external data will not need _any_ type annotations.<p>2. An aim to make it the fastest managed compiled lang around (faster than golang).<p>3. Functional.<p>4. A focus on fast compile times from the beginning (like golang).<p>5. Serde from rust is essentially a language builtin.<p>6. Zero side effects, only managed effects (which I think will do wonders for testability and mocking in a compiled language).<p>What I&#x27;m unclear about is:<p>1. Whether they&#x27;ll support macros,<p>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 from my hands).<p>It&#x27;d be dope if anyone more familiar can comment on the above!<p>Also, as feedback to Richard Feldman, your podcast is (imo) great marketing for your lang! It&#x27;s what&#x27;s made me excited about your PL.<p>EDIT: Forgot another feature I&#x27;m allured by: ability to run programs with type errors (as best as one can).

Neat, looks like the website got an overhaul.<p>I like Roc&#x27;s approach of detecting errors statically but still trying to let you run the code. If a snippet is work in progress and has an unused variable, Go or Zig will refuse to compile it. Yes, an unused variable indicates a problem, which is why it&#x27;s not going to pass any sensible CI setup and make its way into production, but that doesn&#x27;t mean I should be disallowed from checking whether what I&#x27;ve got so far works. Roc allows¹ running a program with type errors as long as you don&#x27;t execute a code path affected by them, which I imagine is very useful for refactoring.<p>The platform approach is also interesting, but I don&#x27;t know how it will play into code reuse. I guess the different io&#x2F;platform interfaces might not be quite as big of a problem in a pure functional language? I&#x27;m not experienced enough to tell.<p>¹: I haven&#x27;t checked how successful it is, given it&#x27;s immaturity I expect there to be issues

No real thoughts on the language yet, other than looks interesting and modern.<p>But, that website has one of the smoothest on boarding experience I&#x27;ve ever seen for a new language. From the inline REPL (with built in tutorial), to the code definition section, its insanely practical. Every new (&amp; old) language should have a website and onboarding experience like this one.

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

If you are interested, «why yet another programming language?».<p>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.<p>See this video of Richard Feldman for details — «Outperforming Imperative with Pure Functional Languages»: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=vzfy4EKwG_Y">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=vzfy4EKwG_Y</a><p>Among those clever optimizations:<p>- static reference counting (no GC, like in Rust, but with no borrowing and borrow problems);<p>- stack allocation of the data with no external links;<p>- hidden («opportunistic») mutability even in the cases, where Haskell or Lisp will copy the value.<p>edit:markup

Looks interesting. I&#x27;m a huge fan of F# and think anything working in that hybridish space is the way to go. I&#x27;ll have to dedicate some more time to this when I get a moment.

I was thinking of this the other day. I was trying to remember the name of the language and to look it up.<p>Elm really broke my heart, I believed it will go places it never went. Roc honestly, I am OK to play around with it and build whatever makes me happy.

Having a play with Gleam right now. Roc&#x27;s managed effects sounds interesting, maybe Gleam could layer something similar atop Erlang&#x27;s OTP? Right now, outside a database, it&#x27;s not clear to this newbie how state is meant to be managed in Misty, the Gleam web framework I am kicking the tyres of. If I can be bothered, I was seeing myself having to delegate state management to a separate process (which Gleam seems to support well, but it&#x27;s work I didn&#x27;t anticipate and I am at this stage only playing).<p>Edit: related to state management, the &quot;platform&quot; concept looks interesting too <a href="https:&#x2F;&#x2F;github.com&#x2F;roc-lang&#x2F;roc&#x2F;wiki&#x2F;Roc-concepts-explained#platform">https:&#x2F;&#x2F;github.com&#x2F;roc-lang&#x2F;roc&#x2F;wiki&#x2F;Roc-concepts-explained#...</a>

I don&#x27;t know, after having used Elm and seeing the community accused of &quot;hostile attacks&quot; by one of the main contributors (who is the creator of Roc now) [0], I don&#x27;t feel that it&#x27;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 stopped using Elm after a while, it didn&#x27;t seem like they wanted to ever address the issues they had, or even to acknowledge them as issues in the first place.<p>I know in my linked [0] that Feldman has since apologized, if only because the comment was being linked to so often [1], but again, why not use any other language where the creators are not so hostile, some even going so far as to say that they &quot;wouldn&#x27;t trust anything that Richard Feldman was involved in. He was instrumental in making the Elm community a hostile and unwelcoming place.&quot;?<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;gdotdesign&#x2F;elm-github-install&#x2F;issues&#x2F;62#issuecomment-415860947">https:&#x2F;&#x2F;github.com&#x2F;gdotdesign&#x2F;elm-github-install&#x2F;issues&#x2F;62#i...</a> (check the edit history)<p>[1] <a href="https:&#x2F;&#x2F;hn.algolia.com&#x2F;?dateRange=all&amp;page=0&amp;prefix=true&amp;query=https%3A%2F%2Fgithub.com%2Fgdotdesign%2Felm-github-install%2Fissues%2F62&amp;sort=byDate&amp;type=all" rel="nofollow noreferrer">https:&#x2F;&#x2F;hn.algolia.com&#x2F;?dateRange=all&amp;page=0&amp;prefix=true&amp;que...</a>

Does Roc have any features that a Haskell programmer could consider improvements?

The webpage is very nice, with 3-4 steps tutorial to engage people and an example with interactive explanations

Just don’t try to use it with Paper.

Looks interesting for sure and I like the syntax. Also, they seem to be using both Zig and Rust in their compiler from the looks of it?

Refreshing to see a tech, and better yet, proglang post on the HN front page again, after the last few days.<p>Need less Altman, and more altlang posts.

Lets make Tcl&#x2F;Tk GUI bindings for this! Please it would kick python butt! Roc on!

Just the other day I was looking at this website and it was the old one. Does this mean that Roc is out of alpha&#x2F;beta?<p>As a big elm fan who does backend work, I’ve been looking Roc for a while with a lot of excitement.

I think Roc has a lot of good ideas, especially the backpassing syntax sugar and that there&#x27;s only one way to declare functions (anonymous or not). Excited to see where it goes!

I&#x27;m excited to take a look at this. I learned F# early on in my career and really enjoyed it. These days I&#x27;m into ultimate simplicity. I really like V-lang. It has the simplicity of Go but adds some ergonomics that Go has been missing. Also, it can seamlessly interact with C libraries. So, that is my current favorite language. Hopefully Roc will be my favorite functional language :-).

Their FAQ is an eminently reasonable breakdown of their choices:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;roc-lang&#x2F;roc&#x2F;blob&#x2F;main&#x2F;FAQ.md">https:&#x2F;&#x2F;github.com&#x2F;roc-lang&#x2F;roc&#x2F;blob&#x2F;main&#x2F;FAQ.md</a><p>I don&#x27;t fully agree with all of the reasoning, but it&#x27;s a reasonable position to stake.

I&#x27;m super excited to see Roc up on HN.<p>I like the &#x27;be fast&#x27; and &#x27;be haskell like&#x27; approach.<p>I see you have an Earthfile in the repo. Let me know if you have any Earthly feedback or if I can help with the build in any way, @rtfeldman.<p>( We&#x27;ve been working on making Earthly faster for Rust builds by using cache mounts. )

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

Since the type is inferred, why can&#x27;t the module name by convention be inferred from the data type in pipe operations?<p>So instead of:<p>[&quot;a&quot;, &quot;b&quot;, &quot;c&quot;] |&gt; List.append &quot;d&quot; |&gt; List.append &quot;e&quot; |&gt; List.append &quot;f&quot;<p>You could have:<p>[&quot;a&quot;, &quot;b&quot;, &quot;c&quot;] |&gt; append &quot;d&quot; |&gt; append &quot;e&quot; |&gt; append &quot;f&quot;<p>Since Roc knows that the type returned from each function is a List.

Interesting divide-by-zero behavior when I use the interpreter in the webpage:<p><pre><code> » 1&#x2F;0 1000000000000000000 : Frac *</code></pre>

Roc is definitely interesting and I like the platforms idea. The error messages are clear, but calling them friendly is clearly not something they&#x27;ve reached yet.<p>Just installing and trying to reach a valid hello world going just by the errors and it&#x27;s actively rude within three error messages.<p>Also it&#x27;s missing the final newline

Looks cool but I am somewhat weary of languages that are so wholly dependent on whitespace for significance. I say this as a Python user... but my favorite part of Lisp is the homoiconicity. Things become very intuitive ... whereas the syntax of a language like this takes much longer to grok.

Why “\(var)” instead of one of the other, more prevalent string interpolation escapes?<p>Is it a Haskell&#x2F;Elm thing I’m unfamiliar with?

Is Roc inspired from Elm? Can’t help but to notice a very strong resemblance between the two.

Roc looks great, props to everyone involved in designing this language!<p>Is there an (C) FFI planned?

camelCase instead of snake_case is such a turnoff :(

Can&#x27;t be better than Rust.

Not a fan of the usage of backslashes \

0. I don&#x27;t see type annotations.<p>1. Why another language and not a better runtime for an existing language with an install base that already exists?