Salman Shaik (Jan 10 2023 at 07:15): Salman Shaik (Jan 10 2023 at 07:15):How to get Roc to the mainstream?
How to bring Roc to the mainstream?
This is going to be a very opiniated statement. But, at the same time extremely important if Roc ever wants to hit the mainstream.
What are the most popular languages across the world?
These are just the top 3 of the most used languages for programming. I would like to emphasize on the importance of the word 'used'. All three of these languages are primarily object oriented, atleast the derived understanding of OOP.
Let's dissect the words of R Feldman, the creator of Roc, "I wanted a language with the ergonomics of Elm on the server side".
If you are not aware, Elm is a functional language that compiles to javascript. Roc is a functional language that compiles to a native binary and also webassembly.
Before we answer the question "How to bring Roc to mainstream?", Let's understand what's mainstream. Is it the no.of users of a language. If so are they using it for the ergonomics it provides?
Off the top 3, I would direct you to Java. There are better and more performant languages than Java on the backend. Then why is it still being used and is it at the top of userbase. One reason from my understanding is that it is being taught in the workhouse countries as the entry to software engineering.
By that I mean India, Indonesia, China and Thailand. Java is so far behind Goland, that even after being developed in the open source ecosystem for 4+ years, it is still catching up to C#.
If Roc wants to succeed or atleast be known it has to target a certain set of developers. Make the transition to Functional programming as smooth as possible.
Nothing is bleak, there is an extremely high opportunity for Roc to become the defacto functional programming language in academia.
These are the points in my biased opinion would allow it to be that.
better onboarding process.
Code documentation.
Tutorial topics at a glance. see Kotlin.
Compiler
Build tool
Content repository
Abstract I/O implementations
Do not talk about Rust or Zig only Roc (these 17 years old kids trying the programming landscape)
Be infitesimally faster than go. Even by 0.00000000001% would help.
Grow a community in South and Southeast Asia.
I know, this may sound preposterous, but recent trends have indicated that a languages' success is highly dependent on its use in these 4 countries.
Would love to reply to your own opinions.
Anton (Jan 10 2023 at 08:31):I've replied on reddit :)
https://www.reddit.com/r/roc_lang/comments/1083810/how_to_bring_roc_to_the_mainstream/
Notification Bot (Jan 10 2023 at 08:32):This topic was moved here from #Writing a platform > Developer advocation by Anton.
Anton (Jan 10 2023 at 08:33):@Salman Shaik I've moved your topic to the ideas stream
Brendan Hansknecht (Jan 11 2023 at 03:06):Totally my own opinion and strong in some ways:
This is definitely a big topic that I'm sure a lot of people have a number of thoughts on. In my personal opinion, I think mainstream is overrated. Yes, a language should garner a decent community, but I don't think being mainstream matters much. I get that mainstream can mean more contributors or funding or etc, which all does matter, but I think it only matters a little. As long as Roc becomes large enough to support development of the language, I think it will be successful enough. Instead of focusing on mainstream and chasing crowds, I think it is much more valuable to focus on making a great language. Maybe it is a little greedy of an opinion, but fundamentally, I just want Roc to meet its goals (fast, friendly, functional language) . I don't really care about if it manages to market to java or python devs. In fact, I think it might be a negative to focus too much on these devs. It might lead to modifying the language in ways that makes it worse for Roc devs even though it manages to entice Java devs to pick up and learn Roc.
All of this said, I think it is still very important to think about this. It is also really important to add all of the mentioned documentation in order to make the language really friendly. If the language is confusing, undocumented, or hard to learn, it is not friendly. Hopefully by continually making Roc into a better version of Roc, more aligned with its goals, we will naturally draw a larger crowd, but I think mainstream is overrated.
Side coments/questions:
Do not talk about Rust or Zig only Roc
What is the value of this?
Be infitesimally faster than go.
I think this will happen, but I don't think it matters much. People don't generally actually care much about performance. They pick languages for so many other reasons before performance. Elm is faster than a lot of javascript frameworks, but that really didn't lead to a bunch of people picking elm.
Grow a community in South and Southeast Asia.
I get the sentiment, but that is a very vague and non-actionable goal.
Joshua Warner (Jan 11 2023 at 18:25):Grow a community in South and Southeast Asia.
I get the sentiment, but that is a very vague and non-actionable goal.
IMO it is probably actionable (if we so chose). The actions would be:
In particular, I could imagine a very concrete change being better support for unicode names in the compiler.
Georges Boris (Jan 11 2023 at 20:19):I pretty much agree with everything Brendan said but I also agree with spending more effort on unicode support and other non-english accessibility concerns that could make the language reach new crowds.
Not so it becomes mainstream, but imo it just makes sense for Roc and its ethos to be welcoming for people coming from all places and with different backgrounds.
Joshua Warner (Jan 11 2023 at 20:35):One major sticking point with unicode identifiers is that currently in roc, capitalization is important for distinguishing types of identifiers - modules/tags/types must all be upper-case and variables/functions/type-variables must all be lower-case. That doesn't really work for languages that don't have upper vs lower case, like many (most?) asian languages. Or basically anything that's not written with the latin alphabet.
Richard Feldman (Jan 11 2023 at 21:06):so I remember there being a security concern with Unicode variable names - e.g. people submitting malicious PRs to a Roc project that looks like it's doing one thing but actually it's doing something else, based on using tricks like unicode characters that have different internal representations but which get rendered the same way as something else (so a reviewer can't visually tell the difference)
Richard Feldman (Jan 11 2023 at 21:06):I'm not saying we for sure shouldn't support them, but this was something I thought about in the early days and decided to revisit later
Richard Feldman (Jan 11 2023 at 21:07):it's easier to add support for them later (after investigating nonobvious downsides like security more thoroughly) than discovering later on that there was a downside and having to do a breaking change to remove support for things!
Kevin Gillette (Jan 11 2023 at 21:38):Georges Boris said:
I pretty much agree with everything Brendan said but I also agree with spending more effort on unicode support and other non-english accessibility concerns that could make the language reach new crowds.
Not so it becomes mainstream, but imo it just makes sense for Roc and its ethos to be welcoming for people coming from all places and with different backgrounds.
It'd also force Roc authors to write code that is more correct, for no extra effort on their part, merely by having the stdlib expose the most i18n-correct string abstractions.
Kevin Gillette (Jan 11 2023 at 21:43):Richard Feldman said:
so I remember there being a security concern with Unicode variable names - e.g. people submitting malicious PRs to a Roc project that looks like it's doing one thing but actually it's doing something else, based on using tricks like unicode characters that have different internal representations but which get rendered the same way as something else (so a reviewer can't visually tell the difference)
Different modern languages approach this in different ways. iirc, Swift famously allowed (fairly arbitrary?) Unicode as variable names, including emojis. Go allows fairly typical ASCII identifiers, though also accepts codepoints from the Unicode "letter" class (which includes most non-numeric scripts from living languages).
Kevin Gillette (Jan 11 2023 at 21:46):So Go would be less susceptible, but does not mitigate the issue entirely. We could, during compilation, perform some normalization pass and reject if any two identifiers in related scopes have a different UTF-8 encoding yet have the same normalized encoding.
Kevin Gillette (Jan 11 2023 at 21:48):Such a normalization pass could be an attempt to perform a lossy transform to ascii (such as ß -> ss).
Kevin Gillette (Jan 11 2023 at 21:52):For portions of inputs with no ASCII lookalike and no diacritic or other normalizable aspects, those portions would pass through unchanged (e.g. Chinese characters).
Although normalization transforms are understood to be lossy, since it would only be used as an internal safety check (we wouldn't use it in roc format), the lossy nature is more a benefit than a detraction in this case.
Last updated: Jun 16 2026 at 16:19 UTC