Francesco Orsenigo (Nov 17 2021 at 06:20): Francesco Orsenigo (Nov 17 2021 at 06:20):I wonder what are the plans for managing Roc's community.
I have been using Elm professionally for about four years and, as much as I love the language and its many innovations, I found it very difficult to participate in Elm development to the point where I don't think proposing ideas or trying to contribute there was a good use of my (limited) mental resources.
A few of those ideas ended up being implemented years later when the right people with enough visibility proposed them, while all our work to document and justify those ideas was (as far as I can tell) never even considered.
I suffer of chronic depression and this was frustrating enough that it took a toll on my mental health.
While I might have been an extreme case, I have spoken with a lot of people who have been very enthusiastic about Elm (to the point where they adopted it in production), but disaffected from the community.
I am now trying to develop my own language to feel less constrained, and while I see that Roc has had many of the same ideas (and more reach than I will ever have) I am very, very wary of participating.
Will Roc follow a similar model, where actual engagement with the community (similar to what Rust does) is not a priority and only a few people have the ears of the language developers?
Will there be departures from this model?
What will the hierarchy look like? How are decisions taken?
What are the current thoughts on how to foster a healthy community?
Lucas Rosa (Nov 17 2021 at 07:00):Good question. First, I’d like to say I’m sorry to hear that you had a bad experience. Second, things are very early so now is the time to try to make significant impact. Although there is a general goal/mission, Richard is very open and receptive to hearing people out. So far there has been a nice variety of contributors with more coming every week. That being said as long as things are presented in a friendly and collaborative manager I doubt you’ll be ignored. Anecdotally speaking, I never knew anyone here before submitting pull requests and I never felt like I was being disregarded. I personally would like to end up with more of an open Rust approach as you described. There is no explicit hierarchy at the moment and for the most part decisions are made by Richard and Folkert. Considering how ambitious the project is and how early things are it’s still a little early to tell where exactly things will end up in that regard. There are several areas of the compiler and each have someone who is more or less an expert in that part of the code base, they tend to be able to freely make decisions in terms of implementation but we are all implicitly working towards a common vision largely laid out by Richard. I should also say I don’t speak for anyone mentioned above and I think they’ll also probably chime in soon with their own two cents on the matter.
Richard Feldman (Nov 17 2021 at 12:42):I have thoughts on this topic, but in the spirit of this being a community question I'll hold off, to let others in the Roc community speak first! :big_smile:
Anton (Nov 17 2021 at 13:32):I think the elm community by itself is pretty good but it is very hard to contribute to the elm compiler and core tooling.
I believe It's a lot easier for anyone to contribute to roc. We can however do a better job at helping new contributors get started but this is also very time consuming, hence the current situation.
So far, we've been listening to concerns/feedback/ideas from anyone who shared them. I'd like to keep it like this, although this becomes harder at scale.
Currently bigger decisions are openly discussed until a natural consensus is reached. In cases without a clear consensus Richard makes the final decision which been working fine so far.
As things scale up we'll need some formal way of deciding things. This should be thoroughly researched. Intuitively I believe anyone should be able to weigh in but voting power should be adjusted based on how much knowledge of the context that person has.
Lucas Rosa (Nov 17 2021 at 15:00):We have a really good opportunity once we have an organization for a dedicated repo for Roc Improvement Proposals or RIP for short :D. For those unaware RIP is also online slang so it's pretty funny
Folkert de Vries (Nov 17 2021 at 15:22):totally off-topic is it online slang in a different meaning that "rest in peace"?
Folkert de Vries (Nov 17 2021 at 15:23):I'm assuming it originates in games and then propagated from there
Lucas Rosa (Nov 17 2021 at 15:32):yes and yes
Lucas Rosa (Nov 17 2021 at 15:33):https://www.urbandictionary.com/define.php?term=RIP
Wolfgang Schuster (Nov 17 2021 at 15:57):I'm not here to contribute to Roc the compiler and I kinda like when languages like Elm and Roc have a small number of core contributors to the language. I do think it could be nice to have a core compiler team and potentially core platform teams that work together but aren't trying to contribute to everything.
To me it's similar to cooking, if you have too many people in the kitchen trying to add their own flavors then you're going to end up with something that tastes awful. For a great meal, you want someone leading with some people implementing, and everyone else stay out of the kitchen. At least this was my experience working in restaurants as well as with large family meals.
The timing of this is kinda of interesting for me because I was just discussing TC39 proposals with coworkers and I mentioned how I've been waiting for many years for a few of them to go through. During that time I've seen a lot of other proposals reach stage 4 that I personally have found useless or worse have cause issues (IMO). But at the end of the day, JS, Elm, Roc, and the many other languages that affect my life (or I'm just involved with casually) aren't mine they belong to other people.
Brendan Hansknecht (Nov 17 2021 at 16:39):I personally find open but curated projects to be the best. What i mean is open to discuss ideas with anyone (though willing to just return a link with a small bit of context if it is a commonly repeated comment), but ultimately decisions are made or heavily weighted by a core team.
I think this context and tighter guidance is extremely important for good design and avoiding a large plethora of issues.
Brendan Hansknecht (Nov 17 2021 at 16:43):I think there is some sort of balance between people feeling like this is just Richard's (or a small group of people's) project where they have no input, and people feeling like a core team is doing a good job at guiding the language with community input.
Lucas Rosa (Nov 17 2021 at 16:55):I’m a personal fan of having a BDFL
Lucas Rosa (Nov 17 2021 at 16:55):Rust is an interesting exception cause it was born out of a corporation, not just some random people hoping to make something better than what’s out there
Lucas Rosa (Nov 17 2021 at 16:56):Although I guess Hoare was an internal BDFL for it at Mozilla till he stepped down. Java is probably another exception cause it was born out of sun Microsystems. I’m also not aware of a BDFL for Dart which is by Google
Brendan Hansknecht (Nov 17 2021 at 17:02):I think having a BDFL or not doesn't matter too much as long as there is a good core team with open and responsive discussion. I think Elm, to many people, is an example where BDFL has led to a lot of community tension. I think things would have gone smoother there if it had a larger group of core contributors that helped in discussion and evolution.
Johannes Maas (Nov 17 2021 at 17:02):I find what @Brendan Hansknecht alluded to poignant. Everyone getting a vote has a risk of stalling decisions, but everone offering their insights and perspective is very valuable. So maybe there is a way to formally separate the two.
Lucas Rosa (Nov 17 2021 at 17:03):Yea 100%
Lucas Rosa (Nov 17 2021 at 17:09):For now I think things are fine. But as more people come in and things grow having some kind of formalization will help. Getting the conversation started now so that we are ready for when that time comes is a good thing
Wolfgang Schuster (Nov 17 2021 at 17:10):The offering of insights and perspectives is only valuable if you have a way to take them in. If there are 1000 people posting their perspectives on HN, Reddit, or where ever, that can be very overwhelming.
https://esbuild.github.io/faq/#production-readiness might be a good example of other projects operating (from what I can see) similar to Elm. Specifically the last part
I'm not planning on including major features that I'm not interested in building and/or maintaining. I also want to limit the project's scope so it doesn't get too complex and unwieldy, both from an architectural perspective, a testing and correctness perspective, and from a usability perspective. [..]
I'm hoping that plugins will allow the community to add major features (e.g. WebAssembly import) without needing to contribute to esbuild itself. However, not everything is exposed in the plugin API and it may be the case that it's not possible to add a particular feature to esbuild that you may want to add. This is intentional; esbuild is not meant to be an all-in-one solution for all frontend needs.
Lucas Rosa (Nov 17 2021 at 17:12):I think a separate repo for proposals and ideas as to not clutter bug/approved feature issues would help a lot in that regard
Lucas Rosa (Nov 17 2021 at 17:12):RFCs I think is what people call them but I like RIP lol :p
Richard Feldman (Nov 18 2021 at 16:46):so my thoughts on this are pretty much a mix of what's been said already here :big_smile:
when I started the project, at first it was literally just me, so there was no community and no other contributors...I was making all the decisions, by default! Now that more people are involved, there are more perspectives contributing to decisions, which I think has already led to better decisions than when it was just me. I definitely want to continue that trend!
however, there is definitely a point at which the sheer number of people involved in the discussion becomes detrimental to the participants' ability to have a productive discussion. At the extreme, there's a point where it becomes mathematically impossible to have a productive design discussion because there are too many people involved. A Rust core team member wrote about this:
Rust is my full time job and even I find it impossible to keep up on every design discussion happening related to the teams that I am on (lang, libs, and cargo). Its been a regular event this year that I discover during lang team triage that there’s a new RFC I hadn’t seen that already has more than 50 comments. For someone who isn’t paid to do this, trying to participate productively in any of these discussions seems extremely difficult.
so if you were to graph "number of people involved in discussion" on one axis and "quality of final design" on another, I think it's safe to say the quality improves as you go from 1 person to multiple people, but there's some point where the slope tapers off and then starts decreasing. I don't know exactly where that point is (nobody does for sure) but it's definitely there somewhere!
Richard Feldman (Nov 18 2021 at 16:50):at Roc's current stage, I don't think we need to make things particularly formal. There aren't even 300 people in the repo yet, so the community is still small enough that there's no "fire hose" problem yet. So I don't think we should set up a bunch of formal structures or anything when we can instead just talk about things with basically anyone who wants to without getting overwhelmed.
Richard Feldman (Nov 18 2021 at 16:51):for right now, as several people mentioned above, we have sort of an informal "we talk through decisions but Richard has the final say" thing going, and I think that's been working well. We aren't tending to get stalled on things, and we have lots of input from lots of people.
I definitely don't intend to be a BDFL, but I kinda think of myself at the moment as a BDFN (FN = "For Now") until we grow to the point where it makes sense to transition to some other, more formal structure. That's years away though!
Richard Feldman (Nov 18 2021 at 16:52):one thing I consider an unsolved problem is how to keep a language simple over the long term if it has a committee model for making language design decisions
Richard Feldman (Nov 18 2021 at 16:53):like let's say it's many years in the future, I'm long since dead, and all Roc language design decisions are being made by a committee - how could we set up incentives to prevent the language from becoming bloated?
Richard Feldman (Nov 18 2021 at 16:53):this seems like a hard problem because committees seem to produce bloat by default
Richard Feldman (Nov 18 2021 at 16:54):see for example Java, JavaScript, and Rust - all of which get consistently more complex by the year
Richard Feldman (Nov 18 2021 at 16:54):and all of which have been designed by committee for many years
Richard Feldman (Nov 18 2021 at 16:55):one of the reasons I don't want to be a BDFL is that I want Roc to outlast me
Richard Feldman (Nov 18 2021 at 16:57):so I'd be happier seeing the transition happen, and thinking "cool, this seems sustainable!"
Richard Feldman (Nov 18 2021 at 16:57):so one thing I'd want to figure out before transitioning to a different model is how to set those incentives up in a way that can promote maintaining simplicity as opposed to adding features forever until the language stops being simple.
Richard Feldman (Nov 18 2021 at 16:58):I have a few ideas, but they're kind of off-topic at this stage! :big_smile:
Richard Feldman (Nov 18 2021 at 16:58):anyway, that's my take on the subject!
Zeljko Nesic (Nov 19 2021 at 01:51):I have seen couple of things that I have started that have outgrown me, and took life of their own. When things get popular, you start to dislike it's own popularity. My saying is: when the tide rises it brings a lot of shit on the shore. Just remember what kind of crap Evan took when Elm got bit of a traction (post 0.18 release) - all kinds of naysayers and distractions all over the place.
My only constructive input is that formalism is a cope out mechanism for those that don't know how to handle the pressure.
Keeping the core small and manifold is best way to ensure that the mantra of simplicity holds amidst of chaos of other people's great ideas.
Francesco Orsenigo (Nov 19 2021 at 04:45):There are plenty more possibilities other than "everyone gets a vote" and "BDFL", and often times is not even a matter of what specific hierarchy model you pick, but about the details of its implementation (for example, transparency), or the culture you foster around it.
(There might also be a discussion on how our culture is not very good at taking decisions without a ruler but let's not go into anthropology...)
What is important to me is that there is at least as much depth of thought put on this as there is on, say, picking a hashmap algorithm, (that discussion is super interesting BTW), that if you decide to go with a model (for example, BDFL) there is a discussion on what are the factors that allow some BDFLs to do well and while others do less well and so on.
I do appreciate that Richard is asking himself these questions and has some sort of vision for the future of Roc.
Anyway, thank you, I think this is more or less what I wanted to know.
Brendan Hansknecht (Nov 19 2021 at 04:49):What is important to me is that there is at least as much depth of thought put on this as there is on, say, picking a hashmap algorithm, (that discussion is super interesting BTW), that if you decide to go with a model (for example, BDFL) there is a discussion on what are the factors that allow some BDFLs to do well and while others do less well and so on.
Brendan Hansknecht (Nov 19 2021 at 04:49):100% that
Last updated: Jul 26 2025 at 12:14 UTC