14 ms·

Roc – A fast, friendly, functional language

305 points by dlib 3y ago

nymanjon 3y ago
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 :-).
surprisetalk 3y ago
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/sw_unscripted https://twitter.com/sw_unscripted [2] https://www.youtube.com/results?search_query=richard+feldman https://www.youtube.com/results?search_query=richard+feldman [3] https://www.roc-lang.org/community https://www.roc-lang.org/community
- fouronnes3 3y ago
  What happened to Elm by the way?
  - surprisetalk 3y ago
    Elm is still delightful to use! [1] https://taylor.town/elm-2023 https://taylor.town/elm-2023 Evan also announced some stuff about Elm and Postgres at Strange Loop earlier this year, so I expect another wave of movement soon
    - bbkane 3y ago
      The talk is at https://m.youtube.com/watch?v=XZ3w_jec1v8 https://m.youtube.com/watch?v=XZ3w_jec1v8 I also recommend watching it, though the conclusion I came away with is that Evan is kind of in a "next steps" crisis.
  - zem 3y ago
    if nothing else it popularised TEA ("the elm architecture"), which a lot of other frontend frameworks have picked up on.
poulpy123 3y ago
The webpage is very nice, with 3-4 steps tutorial to engage people and an example with interactive explanations
jpease 3y ago
Just don’t try to use it with Paper.
- redbar0n 3y ago
  Lol. But it beats Scissors. :)
skitter 3y ago
Neat, looks like the website got an overhaul. 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. 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. ¹: I haven't checked how successful it is, given it's immaturity I expect there to be issues
- rzwitserloot 3y ago
  Many java editors (notably, eclipse) work the same way, _if_ you configure them to do so_: Just run it, don't worry about the compilation errors. If the code never hits that segment (in java, if there's a syntactical error in source code, that entire class cannot be used, but if it's a semantic error (e.g. a reference to a function that doesn't exist, which is syntactically perfectly valid, that's a semantic error), only that method is 'tainted'. If you hit a tainted area the debugger kicks in, freezes the process, and breakpoints on the spot. You can then fix it if you want and continue, or inspect the stack and state of e.g. local vars and learn something. What I find surprising is how few programmers I talk to are aware of this, let alone use it. I find it a significant productivity boost. Extrapolating away from debuggers: Everything should be warning, nothing should be an error. Then adopt a policy that you don't check in warnings. I find it utterly insane that 'unused variable' is treated as an _error_ (in the sense that it prevents compilation). It.. just isn't. I hear _lots_ of noise in the line of 'well but my dev team will just ignore that rule', but that's a "doctor it hurts when I press here" issue. You don't solve that by just being more beliggerent, you fix that by having a chat with the team. I wonder what 'friendly' means in the context of 'a programming language', but if its: "Assuming you are not a complete idiot", that's a plus, I guess.
  - 3y ago
drannex 3y ago
No real thoughts on the language yet, other than looks interesting and modern. 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.
- hombre_fatal 3y ago
  No kidding. It went from the most barebones "Under Construction, check back later" website possible to one of the best proglang homepages I've ever seen.
- jetrink 3y ago
  I really like that 'fast', 'friendly' and 'functional' all link directly to long, substantive explanations of the goals and decisions related to those qualities.
- otteromkram 3y ago
  For in-browser tutorials, Haskell does it on the main page, too: https://www.haskell.org/ https://www.haskell.org/ For web UI, I always thought QisKit set the bar pretty high. It's intuitive and informative: https://qiskit.org/ https://qiskit.org/
  - jnrk 3y ago
    Svelte does a pretty good job too. https://svelte.dev/ https://svelte.dev/
- hardkorebob 3y ago
  Yes indeed! I love this web page. Sleek and very upfront with everything. Great job team!! Would love to help in any way.
- jampekka 3y ago
  One thing I had to hunt for was what the backslash means in the first examples. Especially as it seems to be used for both string interpolation and function definition. But other than that great to have a quite good idea of the language in just a few seconds.
okkdev 3y ago
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!
- catgary 3y ago
  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.
  - ReleaseCandidat 3y ago
    Yes, Koka is evidently a inspiration for Roc, which uses Perceus, in-place mutation and their effect system is called "abilities". Roc aims to be something like the "practical version" of Koka('s ideas).
  - okkdev 3y ago
    Oh I completely forgot about Koka, I remember looking at it a couple years ago. I'll have to give it a go again. :)
- davidatbu 3y ago
  We have a very similar taste in PLs :)
exxos 3y ago
Can't be better than Rust.
yashrk 3y ago
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 https://www.youtube.com/watch?v=vzfy4EKwG_Y Among those clever optimizations: - static reference counting (no GC, like in Rust, but with no borrowing and borrow problems); - stack allocation of the data with no external links; - hidden («opportunistic») mutability even in the cases, where Haskell or Lisp will copy the value. edit:markup
- teucris 3y ago
  I’d say that’s one of a few unique selling points. Some others I noticed: - side effects are strictly relegated to async effects, eg all I/O calls return a future - declarative static loading as imports
- deleted 3y ago
  [deleted]
- IshKebab 3y ago
  That sounds a lot like Koka. Is there any relationship?
  - yashrk 3y ago
    See https://news.ycombinator.com/item?id=38350940 https://news.ycombinator.com/item?id=38350940
- 1letterunixname 3y ago
  > 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.
tromp 3y ago
Does Roc have any features that a Haskell programmer could consider improvements?
- yashrk 3y ago
  First of all — way faster machine code. Many other things are features or bugs depending of your preferences. For me, for example, eager evaluation is a big improvement, but YMMV.
  - tromp 3y ago
    > eager evaluation is a big improvement Does it have any support for laziness? E.g. could one define the list of all fibonacci numbers similarly to Haskell's fib = let f a b = a : f b (a+b) in f 0 1
  - satvikpendem 3y ago
    How does it compare to HVM [0]? It is an alternative to GHC that in some cases is orders of magnitudes faster, at least from their benchmarks. [0] https://github.com/HigherOrderCO/hvm https://github.com/HigherOrderCO/hvm
    - weatherlight 3y ago
      i thought the orders of magnitudes faster benchmarks were around lazy evaluation, and probably wouldn't apply here.
    - tkz1312 3y ago
      Roc uses perceus, which is a reference counting model that allows for opportunistic in place mutation if it is safe to do so. HVM is more like a fundamentally new evaluation model that is parallel by default. They are both very exciting, but HVM is much more radical and probably needs at least a few more years until it starts to be seriously practical.
- deleted 3y ago
  [deleted]
satvikpendem 3y ago
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. 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."? [0] https://github.com/gdotdesign/elm-github-install/issues/62#issuecomment-415860947 https://github.com/gdotdesign/elm-github-install/issues/62#i... (check the edit history) [1] 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 https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
- desireco42 3y ago
  I think we need to be able to accept apologies when someone makes them... otherwise we are all doomed.
- rtfeldman 3y ago
  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 your heart to give their work some consideration, if not mine. [0] https://github.com/roc-lang/roc/graphs/contributors https://github.com/roc-lang/roc/graphs/contributors
  - Capricorn2481 3y ago
desireco42 3y ago
I was thinking of this the other day. I was trying to remember the name of the language and to look it up. 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.
10000truths 3y ago
Interesting divide-by-zero behavior when I use the interpreter in the webpage: » 1/0 1000000000000000000 : Frac *
- rtfeldman 3y ago
  Oops, that's a bug - just opened an issue for it: https://github.com/roc-lang/roc/issues/6027 https://github.com/roc-lang/roc/issues/6027 Thanks for pointing it out!
  - ReleaseCandidat 3y ago
    You won't like the result of `0/0` either ;)
    - deleted 3y ago
      [deleted]
Eji1700 3y ago
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.
- ReleaseCandidat 3y ago
  > hybridish space I'm sorry, but what do you mean by that? Roc is "as" pure as Haskell (or Koka), if that's your point.
  - Eji1700 3y ago
    I glanced at the example code and it looked like it allowed side effects, but maybe I was wrong. I haven't had much time to mess with it and seemed to be able to hard crash the repl doing some testing so it's something i'll have to look at later.
    - ReleaseCandidat 3y ago
      Well, yes, if there are no type annotations because all types are inferred, you don't see the effect "types". https://www.roc-lang.org/tutorial#tasks https://www.roc-lang.org/tutorial#tasks
      - Eji1700 3y ago
        Then to my limited understanding that's less "pure" than haskell isn't it, which doesn't allow side effects and thus forces monads?
        whizzter 3y ago
        Honestly it looks like basically the same as getline/putStrLen from the tutorial(1) in the link below, just not written in an intentionally obtuse language. Considering how much more approachable this Roc documentation/naming is, I'm wondering if it isn't so that the people writing Wikipedia's math pages are probably the same people that are drawn to and writes Haskell/monad "tutorials". 1: http://learnyouahaskell.com/input-and-output http://learnyouahaskell.com/input-and-output
babarjaana 3y ago
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?
- ReleaseCandidat 3y ago
  Zig for the standard library, Rust for the compiler. A video about the design decisions of the (hash) map: https://www.youtube.com/watch?v=Z3UGuaJWbaA https://www.youtube.com/watch?v=Z3UGuaJWbaA
shortrounddev2 3y ago
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
- ReleaseCandidat 3y ago
  Actually they both (and OCaml has a whole lot of almost never used OOP - that's where the O comes from) have _way_ less "syntax" than Python or Java.
  - shortrounddev2 3y ago
    I just did some quick math. If you count all the keywords and operators for F# in microsoft's documentation, you come to 150 symbols. This doesn't include the nullary operators (of which there are 14) Counting all the java operators and keywords, you get 84. This doesn't include assignment operators like "+=" or "-=" (11 such operators). ChatGPT tells me that python has 36 keywords and 28 operators (not including the 13 assignment operators). This seems low and may be missing some syntactical sugar operators, but even then 64 is a far lower number than F#'s 150. Much debate could be had about which of these operators are fair to count or not, but it seems preliminarily that the data supports the position that functional programming languages (or at least F#) tend to go heavy on special keywords and operators
    - ReleaseCandidat 3y ago
      You're right, there actually are more. Interesting, I "feel" the opposite. Haskell (55 + some more, because of the grouping): https://wiki.haskell.org/Keywords https://wiki.haskell.org/Keywords F# https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/keyword-reference https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... OCaml: https://v2.ocaml.org/manual/lex.html#sss:keywords https://v2.ocaml.org/manual/lex.html#sss:keywords Python: https://github.com/python/cpython/blob/3.12/Lib/keyword.py https://github.com/python/cpython/blob/3.12/Lib/keyword.py Java (I think these are the current ones): https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_k...
hardkorebob 3y ago
Lets make Tcl/Tk GUI bindings for this! Please it would kick python butt! Roc on!
- deleted 3y ago
  [deleted]
whalesalad 3y ago
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.
asplake 3y ago
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). Edit: related to state management, the "platform" concept looks interesting too https://github.com/roc-lang/roc/wiki/Roc-concepts-explained#platform https://github.com/roc-lang/roc/wiki/Roc-concepts-explained#...
- quaunaut 3y ago
  I imagine state should be managed via GenServers[1][2], since that's the general BEAM way of doing that. 1. https://www.erlang.org/doc/man/gen_server.html https://www.erlang.org/doc/man/gen_server.html 2. https://hexdocs.pm/elixir/1.12/GenServer.html https://hexdocs.pm/elixir/1.12/GenServer.html
davidatbu 3y ago
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 (like golang). 5. Serde from rust is essentially a language builtin. 6. Zero side effects, only managed effects (which I think will do wonders for testability and mocking in a compiled language). What I'm unclear about is: 1. Whether they'll support macros, 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). It'd be dope if anyone more familiar can comment on the above! 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. EDIT: Forgot another feature I'm allured by: ability to run programs with type errors (as best as one can).
- fourteenminutes 3y ago
  It's unlikely that macros will be supported. Regarding editors, it's unlikely that effort on the advertised Roc editor will start in earnest some time soon. I actually recently merged an LSP implementation into the mainline compiler ([details on how to integrate here](https://roc.zulipchat.com/#narrow/stream/304902-show-and-tell/topic/Language.20server/near/397961230 https://roc.zulipchat.com/#narrow/stream/304902-show-and-tel...)), and that's likely to develop more in the near future, before a standalone Roc editor is available.
- rtfeldman 3y ago
  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 from my hands). The IDE project has been deprioritized a lot (e.g. I don't expect any work to be done on it in 2024) because we realized there's a way to build the editor plugin ecosystem we want to build in a way that works across multiple editors. There already is a preliminary language server, and there are instructions in the VS Code extension for how to get it set up [0]. I assume something similar should work for neovim! EDIT: I just noticed that while I was typing this, the author of the Roc language server responded too...hi, Ayaz! Thanks for all your excellent contributions to Roc! https://github.com/ivan-demchenko/roc-vscode-unofficial#configuring-language-server https://github.com/ivan-demchenko/roc-vscode-unofficial#conf...
myaccountonhn 3y ago
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? As a big elm fan who does backend work, I’ve been looking Roc for a while with a lot of excitement.
taraparo 3y ago
Not a fan of the usage of backslashes \
laerus 3y ago
camelCase instead of snake_case is such a turnoff :(
- redbar0n 3y ago
  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.
1letterunixname 3y ago
0. I don't see type annotations. 1. Why another language and not a better runtime for an existing language with an install base that already exists?
- bhansconnect 3y ago
  0. Roc is capable of always inferring types. So type annotations are never required. That said, type annotations are used commonly and 100% supported.
fuzztester 3y ago
Refreshing to see a tech, and better yet, proglang post on the HN front page again, after the last few days. Need less Altman, and more altlang posts.
adamgordonbell 3y ago
I'm super excited to see Roc up on HN. I like the 'be fast' and 'be haskell like' approach. 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. ( We've been working on making Earthly faster for Rust builds by using cache mounts. )
gsuuon 3y ago
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!
sheepscreek 3y ago
Is Roc inspired from Elm? Can’t help but to notice a very strong resemblance between the two.
- rtfeldman 3y ago
  Absolutely! More details: https://github.com/roc-lang/roc/blob/ad5ed57c4202f847cf9e215cda970c6ece22f9ff/FAQ.md#where-did-the-name-roc-come-from https://github.com/roc-lang/roc/blob/ad5ed57c4202f847cf9e215...
osener 3y ago
Roc looks great, props to everyone involved in designing this language! Is there an (C) FFI planned?
- bhansconnect 3y ago
  Yes and No. Roc fundamentally is built on top of platforms. Platforms are communicated with through cffi. So cffi is fundamental to roc. At the same time, roc will never have general cffi where a package can wrap an arbitrary c library. Those primitives must always come through the platform. https://www.roc-lang.org/platforms https://www.roc-lang.org/platforms
3836293648 3y ago
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
- bhansconnect 3y ago
  > it's actively rude within three error messages. Can you share those error messages? I am sure that is not the intent.
naasking 3y ago
Their FAQ is an eminently reasonable breakdown of their choices: https://github.com/roc-lang/roc/blob/main/FAQ.md 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.
- redbar0n 3y ago
  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?
  - naasking 3y ago
    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.
redbar0n 3y ago
Since the type is inferred, why can't the module name by convention be inferred from the data type in pipe operations? So instead of: ["a", "b", "c"] |> List.append "d" |> List.append "e" |> List.append "f" You could have: ["a", "b", "c"] |> append "d" |> append "e" |> append "f" Since Roc knows that the type returned from each function is a List.
- bhansconnect 3y ago
  Roc cares a lot about explicitness, so I don't think this would be a wanted feature. That said, it is easy to get this functionality with something like ``` append = List.append ``` An important note is that any module could expose an append function that has the same interfaces as `List.append`, so that could easily lead to confusion.
jkmcf 3y ago
Why “\(var)” instead of one of the other, more prevalent string interpolation escapes? Is it a Haskell/Elm thing I’m unfamiliar with?

305 points by dlib 3y ago

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 :-).

surprisetalk 3y ago

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/sw_unscripted https://twitter.com/sw_unscripted [2] https://www.youtube.com/results?search_query=richard+feldman https://www.youtube.com/results?search_query=richard+feldman [3] https://www.roc-lang.org/community https://www.roc-lang.org/community

fouronnes3 3y ago
What happened to Elm by the way?
- surprisetalk 3y ago
  Elm is still delightful to use! [1] https://taylor.town/elm-2023 https://taylor.town/elm-2023 Evan also announced some stuff about Elm and Postgres at Strange Loop earlier this year, so I expect another wave of movement soon
  - bbkane 3y ago
    The talk is at https://m.youtube.com/watch?v=XZ3w_jec1v8 https://m.youtube.com/watch?v=XZ3w_jec1v8 I also recommend watching it, though the conclusion I came away with is that Evan is kind of in a "next steps" crisis.
- zem 3y ago
  if nothing else it popularised TEA ("the elm architecture"), which a lot of other frontend frameworks have picked up on.

poulpy123 3y ago

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

jpease 3y ago

Just don’t try to use it with Paper.

redbar0n 3y ago
Lol. But it beats Scissors. :)

skitter 3y ago

Neat, looks like the website got an overhaul. 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. 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. ¹: I haven't checked how successful it is, given it's immaturity I expect there to be issues

rzwitserloot 3y ago
Many java editors (notably, eclipse) work the same way, _if_ you configure them to do so_: Just run it, don't worry about the compilation errors. If the code never hits that segment (in java, if there's a syntactical error in source code, that entire class cannot be used, but if it's a semantic error (e.g. a reference to a function that doesn't exist, which is syntactically perfectly valid, that's a semantic error), only that method is 'tainted'. If you hit a tainted area the debugger kicks in, freezes the process, and breakpoints on the spot. You can then fix it if you want and continue, or inspect the stack and state of e.g. local vars and learn something. What I find surprising is how few programmers I talk to are aware of this, let alone use it. I find it a significant productivity boost. Extrapolating away from debuggers: Everything should be warning, nothing should be an error. Then adopt a policy that you don't check in warnings. I find it utterly insane that 'unused variable' is treated as an _error_ (in the sense that it prevents compilation). It.. just isn't. I hear _lots_ of noise in the line of 'well but my dev team will just ignore that rule', but that's a "doctor it hurts when I press here" issue. You don't solve that by just being more beliggerent, you fix that by having a chat with the team. I wonder what 'friendly' means in the context of 'a programming language', but if its: "Assuming you are not a complete idiot", that's a plus, I guess.
- 3y ago

drannex 3y ago

No real thoughts on the language yet, other than looks interesting and modern. 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.

hombre_fatal 3y ago
No kidding. It went from the most barebones "Under Construction, check back later" website possible to one of the best proglang homepages I've ever seen.
jetrink 3y ago
I really like that 'fast', 'friendly' and 'functional' all link directly to long, substantive explanations of the goals and decisions related to those qualities.
otteromkram 3y ago
For in-browser tutorials, Haskell does it on the main page, too: https://www.haskell.org/ https://www.haskell.org/ For web UI, I always thought QisKit set the bar pretty high. It's intuitive and informative: https://qiskit.org/ https://qiskit.org/
- jnrk 3y ago
  Svelte does a pretty good job too. https://svelte.dev/ https://svelte.dev/
hardkorebob 3y ago
Yes indeed! I love this web page. Sleek and very upfront with everything. Great job team!! Would love to help in any way.
jampekka 3y ago
One thing I had to hunt for was what the backslash means in the first examples. Especially as it seems to be used for both string interpolation and function definition. But other than that great to have a quite good idea of the language in just a few seconds.

okkdev 3y ago

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!

catgary 3y ago
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.
- ReleaseCandidat 3y ago
  Yes, Koka is evidently a inspiration for Roc, which uses Perceus, in-place mutation and their effect system is called "abilities". Roc aims to be something like the "practical version" of Koka('s ideas).
- okkdev 3y ago
  Oh I completely forgot about Koka, I remember looking at it a couple years ago. I'll have to give it a go again. :)
davidatbu 3y ago
We have a very similar taste in PLs :)

exxos 3y ago

Can't be better than Rust.

yashrk 3y ago

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 https://www.youtube.com/watch?v=vzfy4EKwG_Y Among those clever optimizations: - static reference counting (no GC, like in Rust, but with no borrowing and borrow problems); - stack allocation of the data with no external links; - hidden («opportunistic») mutability even in the cases, where Haskell or Lisp will copy the value. edit:markup

teucris 3y ago
I’d say that’s one of a few unique selling points. Some others I noticed: - side effects are strictly relegated to async effects, eg all I/O calls return a future - declarative static loading as imports
deleted 3y ago
[deleted]
IshKebab 3y ago
That sounds a lot like Koka. Is there any relationship?
- yashrk 3y ago
  See https://news.ycombinator.com/item?id=38350940 https://news.ycombinator.com/item?id=38350940
1letterunixname 3y ago
> 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.

tromp 3y ago

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

yashrk 3y ago
First of all — way faster machine code. Many other things are features or bugs depending of your preferences. For me, for example, eager evaluation is a big improvement, but YMMV.
- tromp 3y ago
  > eager evaluation is a big improvement Does it have any support for laziness? E.g. could one define the list of all fibonacci numbers similarly to Haskell's fib = let f a b = a : f b (a+b) in f 0 1
- satvikpendem 3y ago
  How does it compare to HVM [0]? It is an alternative to GHC that in some cases is orders of magnitudes faster, at least from their benchmarks. [0] https://github.com/HigherOrderCO/hvm https://github.com/HigherOrderCO/hvm
  - weatherlight 3y ago
    i thought the orders of magnitudes faster benchmarks were around lazy evaluation, and probably wouldn't apply here.
  - tkz1312 3y ago
    Roc uses perceus, which is a reference counting model that allows for opportunistic in place mutation if it is safe to do so. HVM is more like a fundamentally new evaluation model that is parallel by default. They are both very exciting, but HVM is much more radical and probably needs at least a few more years until it starts to be seriously practical.
deleted 3y ago
[deleted]

satvikpendem 3y ago

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. 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."? [0] https://github.com/gdotdesign/elm-github-install/issues/62#issuecomment-415860947 https://github.com/gdotdesign/elm-github-install/issues/62#i... (check the edit history) [1] 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 https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

desireco42 3y ago
I think we need to be able to accept apologies when someone makes them... otherwise we are all doomed.
rtfeldman 3y ago
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 your heart to give their work some consideration, if not mine. [0] https://github.com/roc-lang/roc/graphs/contributors https://github.com/roc-lang/roc/graphs/contributors
- Capricorn2481 3y ago

desireco42 3y ago

I was thinking of this the other day. I was trying to remember the name of the language and to look it up. 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.

10000truths 3y ago

Interesting divide-by-zero behavior when I use the interpreter in the webpage: » 1/0 1000000000000000000 : Frac *

rtfeldman 3y ago
Oops, that's a bug - just opened an issue for it: https://github.com/roc-lang/roc/issues/6027 https://github.com/roc-lang/roc/issues/6027 Thanks for pointing it out!
- ReleaseCandidat 3y ago
  You won't like the result of `0/0` either ;)
  - deleted 3y ago
    [deleted]

Eji1700 3y ago

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.

ReleaseCandidat 3y ago
> hybridish space I'm sorry, but what do you mean by that? Roc is "as" pure as Haskell (or Koka), if that's your point.
- Eji1700 3y ago
  I glanced at the example code and it looked like it allowed side effects, but maybe I was wrong. I haven't had much time to mess with it and seemed to be able to hard crash the repl doing some testing so it's something i'll have to look at later.
  - ReleaseCandidat 3y ago
    Well, yes, if there are no type annotations because all types are inferred, you don't see the effect "types". https://www.roc-lang.org/tutorial#tasks https://www.roc-lang.org/tutorial#tasks
    - Eji1700 3y ago
      Then to my limited understanding that's less "pure" than haskell isn't it, which doesn't allow side effects and thus forces monads?
      - whizzter 3y ago
        Honestly it looks like basically the same as getline/putStrLen from the tutorial(1) in the link below, just not written in an intentionally obtuse language. Considering how much more approachable this Roc documentation/naming is, I'm wondering if it isn't so that the people writing Wikipedia's math pages are probably the same people that are drawn to and writes Haskell/monad "tutorials". 1: http://learnyouahaskell.com/input-and-output http://learnyouahaskell.com/input-and-output

babarjaana 3y ago

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?

ReleaseCandidat 3y ago
Zig for the standard library, Rust for the compiler. A video about the design decisions of the (hash) map: https://www.youtube.com/watch?v=Z3UGuaJWbaA https://www.youtube.com/watch?v=Z3UGuaJWbaA

shortrounddev2 3y ago

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

ReleaseCandidat 3y ago
Actually they both (and OCaml has a whole lot of almost never used OOP - that's where the O comes from) have _way_ less "syntax" than Python or Java.
- shortrounddev2 3y ago
  I just did some quick math. If you count all the keywords and operators for F# in microsoft's documentation, you come to 150 symbols. This doesn't include the nullary operators (of which there are 14) Counting all the java operators and keywords, you get 84. This doesn't include assignment operators like "+=" or "-=" (11 such operators). ChatGPT tells me that python has 36 keywords and 28 operators (not including the 13 assignment operators). This seems low and may be missing some syntactical sugar operators, but even then 64 is a far lower number than F#'s 150. Much debate could be had about which of these operators are fair to count or not, but it seems preliminarily that the data supports the position that functional programming languages (or at least F#) tend to go heavy on special keywords and operators
  - ReleaseCandidat 3y ago
    You're right, there actually are more. Interesting, I "feel" the opposite. Haskell (55 + some more, because of the grouping): https://wiki.haskell.org/Keywords https://wiki.haskell.org/Keywords F# https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/keyword-reference https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... OCaml: https://v2.ocaml.org/manual/lex.html#sss:keywords https://v2.ocaml.org/manual/lex.html#sss:keywords Python: https://github.com/python/cpython/blob/3.12/Lib/keyword.py https://github.com/python/cpython/blob/3.12/Lib/keyword.py Java (I think these are the current ones): https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_k...

hardkorebob 3y ago

Lets make Tcl/Tk GUI bindings for this! Please it would kick python butt! Roc on!

deleted 3y ago
[deleted]

whalesalad 3y ago

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.

asplake 3y ago

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). Edit: related to state management, the "platform" concept looks interesting too https://github.com/roc-lang/roc/wiki/Roc-concepts-explained#platform https://github.com/roc-lang/roc/wiki/Roc-concepts-explained#...

quaunaut 3y ago
I imagine state should be managed via GenServers[1][2], since that's the general BEAM way of doing that. 1. https://www.erlang.org/doc/man/gen_server.html https://www.erlang.org/doc/man/gen_server.html 2. https://hexdocs.pm/elixir/1.12/GenServer.html https://hexdocs.pm/elixir/1.12/GenServer.html

davidatbu 3y ago

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 (like golang). 5. Serde from rust is essentially a language builtin. 6. Zero side effects, only managed effects (which I think will do wonders for testability and mocking in a compiled language). What I'm unclear about is: 1. Whether they'll support macros, 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). It'd be dope if anyone more familiar can comment on the above! 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. EDIT: Forgot another feature I'm allured by: ability to run programs with type errors (as best as one can).

fourteenminutes 3y ago
It's unlikely that macros will be supported. Regarding editors, it's unlikely that effort on the advertised Roc editor will start in earnest some time soon. I actually recently merged an LSP implementation into the mainline compiler ([details on how to integrate here](https://roc.zulipchat.com/#narrow/stream/304902-show-and-tell/topic/Language.20server/near/397961230 https://roc.zulipchat.com/#narrow/stream/304902-show-and-tel...)), and that's likely to develop more in the near future, before a standalone Roc editor is available.
rtfeldman 3y ago
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 from my hands). The IDE project has been deprioritized a lot (e.g. I don't expect any work to be done on it in 2024) because we realized there's a way to build the editor plugin ecosystem we want to build in a way that works across multiple editors. There already is a preliminary language server, and there are instructions in the VS Code extension for how to get it set up [0]. I assume something similar should work for neovim! EDIT: I just noticed that while I was typing this, the author of the Roc language server responded too...hi, Ayaz! Thanks for all your excellent contributions to Roc! https://github.com/ivan-demchenko/roc-vscode-unofficial#configuring-language-server https://github.com/ivan-demchenko/roc-vscode-unofficial#conf...

myaccountonhn 3y ago

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? As a big elm fan who does backend work, I’ve been looking Roc for a while with a lot of excitement.

taraparo 3y ago

Not a fan of the usage of backslashes \

laerus 3y ago

camelCase instead of snake_case is such a turnoff :(

redbar0n 3y ago
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.

1letterunixname 3y ago

0. I don't see type annotations. 1. Why another language and not a better runtime for an existing language with an install base that already exists?

bhansconnect 3y ago
0. Roc is capable of always inferring types. So type annotations are never required. That said, type annotations are used commonly and 100% supported.

fuzztester 3y ago

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

adamgordonbell 3y ago

I'm super excited to see Roc up on HN. I like the 'be fast' and 'be haskell like' approach. 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. ( We've been working on making Earthly faster for Rust builds by using cache mounts. )

gsuuon 3y ago

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!

sheepscreek 3y ago

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

rtfeldman 3y ago
Absolutely! More details: https://github.com/roc-lang/roc/blob/ad5ed57c4202f847cf9e215cda970c6ece22f9ff/FAQ.md#where-did-the-name-roc-come-from https://github.com/roc-lang/roc/blob/ad5ed57c4202f847cf9e215...

osener 3y ago

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

bhansconnect 3y ago
Yes and No. Roc fundamentally is built on top of platforms. Platforms are communicated with through cffi. So cffi is fundamental to roc. At the same time, roc will never have general cffi where a package can wrap an arbitrary c library. Those primitives must always come through the platform. https://www.roc-lang.org/platforms https://www.roc-lang.org/platforms

3836293648 3y ago

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

bhansconnect 3y ago
> it's actively rude within three error messages. Can you share those error messages? I am sure that is not the intent.

naasking 3y ago

Their FAQ is an eminently reasonable breakdown of their choices: https://github.com/roc-lang/roc/blob/main/FAQ.md 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.

redbar0n 3y ago
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?
- naasking 3y ago
  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.

redbar0n 3y ago

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

bhansconnect 3y ago
Roc cares a lot about explicitness, so I don't think this would be a wanted feature. That said, it is easy to get this functionality with something like ``` append = List.append ``` An important note is that any module could expose an append function that has the same interfaces as `List.append`, so that could easily lead to confusion.

jkmcf 3y ago

Why “\(var)” instead of one of the other, more prevalent string interpolation escapes? Is it a Haskell/Elm thing I’m unfamiliar with?