Hi everyone, I've wanted to get involved in contributing to Roc recently, but I'm not a compiler dev, so instead I wanted to contribute some tooling/peripheral stuff for Roc. Things like pre-commit hooks, a github action to install Roc, maybe a Docker image, stuff that I don't think the core team would be interested in maintaining.
I've made a Roc-Community organisation on GitHub (https://github.com/roc-community/) to house these kinds of projects and to hopefully attract some more contributors, but I realised I should check in here to make sure the core Roc team (and particularly @Richard Feldman) are okay with that. I don't want anyone thinking, for example that if they pull a Docker image from roc-community
that they're getting an officially endorsed image, or if they have a problem with the tools that they should contact/blame the Roc developers.
If anyone is unhappy with this, I can delete/deactivate the organisation and put these kinds of projects on my own GitHub account instead. Thanks :)
Im interested to explore ideas in this direction. It might be helpful to write up a bit of a proposal with more specific details? Are you thinking things like packages? or more like core compiler work? Maybe a brainstorming discussion to consider different things. I've had similar ideas but coming from a different direction. I was trying to think about intended use cases and possible future interest groups and how to identify and meet thier needs. Like a teacher using roc to teach programming, verse an embedded engineer using roc for a controller etc. Always up for a chat if that would help. :grinning:
Hi Luke, thanks for your interest. I can share the notes with ideas I've taken over the last few days, but they're pretty raw, I'm interested in hearing if any of them seem like they would be useful to work on.
Like I said, I'm not a compiler developer, so I don't plan to contribute to the compiler much :sweat_smile:
In terms of packages, I was thinking about eventually trying to build some basic packages like datetimes and regular expressions, the kinds of things that are in the stdlib of more batteries-included languages, but those were more long-term goals.
I'm coming from the Julia world, where the community has organised itself into organisations like JuliaDocs which manages the documentation generator packages and JuliaActions which manages CI configurations. These organisations are unofficial in that they don't get official support by the Julia team, but they're de-facto standards and are used by the core team, e.g. the official Julia documentation is generated by the Documenter.jl package, rather than something in the stdlib. I wasn't expecting any of the core developers to use anything in the roc-community organisation, but just to have an organisation name attached to the projects that let people know they were a community effort, rather than one person's work.
Here's the ideas I've collected in a very raw form:
Roc Community Ideas
Lots of fun stuff. This seems like a cool idea overall with tons of projects to learn with and help push the community forward.
Not sure about organization naming but overall seems like lots of great stuff to invest more into.
Yeah this is great stuff to work on. I can't comment on the organisation name etc, Richard and Anton know more about that side of things.
From your notes:
a serde kinda library
is this even possible without macros or similar?
We have a new language feature, implemented in the past year, called Abilities! Implementing something like serde was one of the big motivations for it. It's not well documented yet but there's an Encoding ability and a Decoding ability, and they are used in Json.roc in the repo.
@Brian Carroll Cool! I've heard of abilities but I also saw they're not documented yet, so I haven't looked into them at all so far :)
I posted an example using a JSON URL package recently if you're interested to see it in action zulip thread
hi @Hannes, and welcome! :smiley:
I appreciate the question about organization/repo naming - honestly I agree with Evan that elm-community
ended up not working out the way we'd hoped, so I personally wouldn't be in favor of having a roc-community
org or repo
Hannes said:
I'm not a compiler dev, so instead I wanted to contribute some tooling/peripheral stuff for Roc. Things like pre-commit hooks, a github action to install Roc, maybe a Docker image, stuff that I don't think the core team would be interested in maintaining.
this is really awesome to hear, because Roc could really use these things! :smiley:
one thing that would be immediately useful is a GitHub action to publish platforms
for example, let's say I want to do a release of https://github.com/roc-lang/basic-cli - I have to do a build of its low-level implementation for:
...and possibly more, if I want to support more than that.
then, afterwards, I need to take all of those compiled binaries and put them all together in a tarball so Roc application authors can install it from one convenient URL
a GitHub action to reduce all of those steps into one step (and which could run on all the different necessary operating systems) would be really helpful, not just for basic-cli
today, but for platform authors in general in the future!
Richard Feldman said:
I appreciate the question about organization/repo naming - honestly I agree with Evan that
elm-community
ended up not working out the way we'd hoped, so I personally wouldn't be in favor of having aroc-community
org or repo
out of the loop i guess but what happened with elm-community?
the only community driven gh org I know is https://github.com/nix-community and well seems that they're doing pretty good? idk maybe it's different in lang-space
more context here: https://elmlang.slack.com/archives/C0NLYJWSZ/p1673439727608069
tl;dr
elm-community
in practice created a misperception of reputation - e.g. if you see someone/csv
, and elm-community/csv
, you might think "ok, I don't know who someone
is, but I trust the Elm community, so I'll go with the elm-community
CSV library." But for all you know, elm-community/csv
is actually made by the same someone
, or maybe it's a different author but they didn't do as good a job as someone
did. In either case, it's a community member making the package, but one of the community members gets a special reputational bonus just for getting their package moved into the elm-community
repo, even though there isn't any special vetting process to ensure quality in there. (And I don't think a special vetting process would have been the solution here either.)elm-community
and let others take it over), over the years there have been several instances of "this elm-community
package used by lots of people isn't maintained anymore; will anyone volunteer to take it over?" - as opposed to the usual process of "if a package I use isn't maintained anymore, I can fork it under my own username and continue in the direction I think makes sense"elm-community
packages can end up being taken over by whoever happens to volunteer, but as a user of the package, you don't have any way to tell that the package is now under completely new ownership (because the org didn't change; it was the same before and after) and future releases might not be what you've come to expect from the current author(s)so overall, it seems best not to have a special org/repo whose name suggests it represents The Community; I think it's better if all community members are publishing on an equal playing field, and nobody's package gets a reputational bump by getting into the official-sounding repo :big_smile:
that said, I do think there's a separate case of packages being moved into the roc-lang/
org, which to me means "the people making Roc are collectively taking responsibility for actively maintaining this" - and in that case it's appropriate for the package to take on the reputation of the Roc organization as a whole...because that is indeed who is maintaining it!
Thanks for replying with your thoughts Richard, this is the exact kind of thing I was thinking of when I made the organisation. I won't use the organisation and instead put these kinds of projects in my own account. :+1:
Coming from the Julia world these kinds of community projects have worked really well there, so it felt natural to me to make one for Roc. I'm trying to think about why the system has worked so well in Julia but seemingly not in the Elm community (not having used Elm before). I think some of it is specific to the Julia language where multiple dispatch encourages a few small libraries that define common interfaces like Tables.jl which is the interface used by basically all rectangular data libraries or Colors.jl which basically every package that uses colours interfaces with.
I'll look into your suggestion for a github action to publish a platform, and of course if I get any of these ideas off the ground I'll share them in #show and tell :) Anyone reading this who's interested in sharing more ideas or contributing to any of them, free to DM me and/or @Luke Boswell, we're looking to flesh out a plan for these ideas.
awesome, sounds good!
Last updated: Jul 06 2025 at 12:14 UTC