Talk on the Roc language

Learn
1

I enjoyed this Strangeloop talk by @rtfeldman. Not Elm but Roc. But as Roc is a ‘direct descendant’ of Elm, i think it deserves a mention here.

16 Likes
2

Besides that, the talk is very relevant because Elm shares the ‘pure Functional’ property with Roc.
I appreciate Richard’s thorough exploration and explanation. The level of detail makes it a great resource to clarify the differences between these classes of programming languages in practice.
Sometimes, it did not seem clear that using mutation to reduce runtime expenses is more of an implementation detail of runtimes and compilers than a property of the programming language.
I used to sum it up like this: If a human can program this optimization in an imperative language, we can just as well let a compiler do that. So there is less need to delegate responsibility for mutations to an application programmer.
But sometimes, it takes some elaboration to get that across. I’ve never seen anything that does that nearly as well as this talk.

3

Hi there !

Not much info out there yet but it seems really interesting ! Would definitely be great to have programmable platforms powered by an Elm like lang : cli, serverless, datastore, webserver, native gui…

Really looking forward :slight_smile:

4

This looks very, very interesting.

Are there any plans with having this as a ‘blessed’ Elm backend?
(ie something like Lamdera where types are wire-compatible without json encoding/decoding)

I’m currently writing a toy Elm app for work (just for shits n giggles) and while the python api server is a fraction of the complexity of the Elm front end I’m spending more time with that than the Elm side, the Elm code just works.

Having something on the backend with the same pedigree as Elm would be awesome.

(EDIT: considering how similar the structure of code looks in the “A Taste of Roc” I can almost see a transpiler converting Elm <-> Roc)

5

There are some subtle enough differences that direct transpiling likely won’t work. Roc does t have custom types like Elm does, but does have union types (I think I’m saying that correctly) which kind of have a similar purpose but are used differently. Roc also doesn’t have currying, e.g. in Elm You can write

add : Int -> Int -> Int
add = (+)

increment : Int -> Int
increment = add 1

but in Roc you’d write

add : Int, Int -> Int
add = \a, b -> a + b

increment : Int -> Int
increment = \x -> add x 1

There are also differences with piping. In Elm |> is a function, but in Roc it’s syntactic sugar.

These 2 differences mean that in Roc you typically pass the “thing you’re piping” as the first argument when in Elm it’s the last argument.

1 Like
6

  1. So if in some cases immutability is a performance win and in some this is crushing, can these optimisations actually make the first case worse? Or are the optimisations somehow able to make the best of both worlds?

  2. I think a good resource to create for Roc would be some techniques on translating mutable imperative algorithms to pure style. I suspect that this doesn’t exist at the moment, since in most cases if you want it to have performance characteristics in any way comparable, you have to invent a completely different algorithm, but presumably with Roc a direct translation would make sense, but this can be still quite tricky. I remember trying to translate some papers that use circular doubly linked lists for instance being quite challenging to port to a pure equivalent, since the mutable idioms were not very applicable to the pure style.

1 Like
7

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.