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://twitter.com/sw_unscripted" rel="nofollow noreferrer">https://twitter.com/sw_unscripted</a><p>[2] <a href="https://www.youtube.com/results?search_query=richard+feldman">https://www.youtube.com/results?search_query=richard+feldman</a><p>[3] <a href="https://www.roc-lang.org/community" rel="nofollow noreferrer">https://www.roc-lang.org/community</a>
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:<p>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.<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'm unclear about is:<p>1. Whether they'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'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's what's made me excited about your PL.<p>EDIT: Forgot another feature I'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'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's not going to pass any sensible CI setup and make its way into production, but that doesn't mean I should be disallowed from checking whether what I've got so far works. Roc allows¹ running a program with type errors as long as you don'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't know how it will play into code reuse. I guess the different io/platform interfaces might not be quite as big of a problem in a pure functional language? I'm not experienced enough to tell.<p>¹: I haven't checked how successful it is, given it'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'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 (& old) language should have a website and onboarding experience like this one.
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!
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://www.youtube.com/watch?v=vzfy4EKwG_Y">https://www.youtube.com/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'm a huge fan of F# and think anything working in that hybridish space is the way to go. I'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's managed effects sounds interesting, maybe Gleam could layer something similar atop Erlang's OTP? Right now, outside a database, it'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's work I didn't anticipate and I am at this stage only playing).<p>Edit: related to state management, the "platform" concept looks interesting too <a href="https://github.com/roc-lang/roc/wiki/Roc-concepts-explained#platform">https://github.com/roc-lang/roc/wiki/Roc-concepts-explained#...</a>
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 stopped using Elm after a while, it didn'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 "wouldn't trust anything that Richard Feldman was involved in. He was instrumental in making the Elm community a hostile and unwelcoming place."?<p>[0] <a href="https://github.com/gdotdesign/elm-github-install/issues/62#issuecomment-415860947">https://github.com/gdotdesign/elm-github-install/issues/62#i...</a> (check the edit history)<p>[1] <a href="https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=https%3A%2F%2Fgithub.com%2Fgdotdesign%2Felm-github-install%2Fissues%2F62&sort=byDate&type=all" rel="nofollow noreferrer">https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...</a>
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.
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/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's only one way to declare functions (anonymous or not). Excited to see where it goes!
I'm excited to take a look at this. I learned F# early on in my career and really enjoyed it. These days I'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://github.com/roc-lang/roc/blob/main/FAQ.md">https://github.com/roc-lang/roc/blob/main/FAQ.md</a><p>I don't fully agree with all of the reasoning, but it's a reasonable position to stake.
I'm super excited to see Roc up on HN.<p>I like the 'be fast' and 'be haskell like' 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'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't the module name by convention be inferred from the data type in pipe operations?<p>So instead of:<p>["a", "b", "c"]
|> List.append "d"
|> List.append "e"
|> List.append "f"<p>You could have:<p>["a", "b", "c"]
|> append "d"
|> append "e"
|> append "f"<p>Since Roc knows that the type returned from each function is a List.
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.<p>Just installing and trying to reach a valid hello world going just by the errors and it's actively rude within three error messages.<p>Also it'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.
0. I don'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?