Tobias Steckenborn (Jul 13 2022 at 07:34): Tobias Steckenborn (Jul 13 2022 at 07:34):I've got a question regarding the documentation and the public milestone:
Currently, it seems to me that the documentation is more focused on the how, but we are still missing the why / where there. To me, it seems that we are missing a short pitch where we see the language heading (and where not, perhaps based on use cases) and assume that people interested know its potential benefits.
So it seems to me that it might be beneficial to add some answers to the questions right in the FAQ / Readme:
However, these are likely to depend on the platforms that are made available early on which, apart from the main contributors, are likely to be of most interest to potential Roc developers.
I know that some of these answers are implicitly given in some of Richard's talks, but I guess we can't assume everybody to watch through them. Is anyone else of the same opinion? Is this something we should be working on?
Georges Boris (Jul 13 2022 at 22:02):just my 2c - but I think there is an emergent aspect of Roc that makes it tricky to plan its use cases ahead.
the platform approach is very hackable and I'm super curious about what people will come up with. it would be sad to encourage specific use cases on its infancy instead of just being surprised for a while and then showcasing all the different things that happened.
Richard Feldman (Jul 13 2022 at 22:28):Currently, it seems to me that the documentation is more focused on the how, but we are still missing the why / where there. To me, it seems that we are missing a short pitch where we see the language heading (and where not, perhaps based on use cases) and assume that people interested know its potential benefits.
this is partly by design, actually! I don't want to "market" Roc as more polished than it actually is.
so right now it's almost good for certain use cases, but it's not there yet. Once it is actually good for certain use cases (e.g. hopefully CLIs soon, and then hopefully servers after that!) I think it's worth talking about how to present that with caveats (e.g. "Roc is a viable choice for a personal project where you're okay with hitting compiler crashes. The compiled executable should run fast, and compile times should be low, but we still regularly find new bugs where the compiled executable segfaults, the compiler itself crashes, or compile times get super long because there's a pathological code path that hasn't been optimized yet.")
Richard Feldman (Jul 13 2022 at 22:31):I think setting clear expectations around these things has served the project well so far (it turns out lots of people are interested in a language well before it's reached maturity!) and I'd like to continue doing that :smiley:
Zeljko Nesic (Jul 14 2022 at 11:32):Anti-marketing campaign! :)
jan kili (Jul 14 2022 at 11:39):I agree with all of the above, though I think that the term "use case" might be more specific than @Tobias Steckenborn means. Use cases are supported by platforms and will change with time, as @Georges Boris said, but I feel like Roc definitely already has something like use categories or use styles - reasons why a developer might want an app/platform distinction, purely functional code, or in-place mutation. Perhaps these are just "language advantages/features", but the README currently assumes familiarity with them or delegates their marketing to conference talks. What if there was a short section on such advantages, which are platform-agnostic and timeless?
Martin Stewart (Jul 14 2022 at 11:43):In addition to what others wrote, I think it's best if the Roc community grows slowly in order to give time for best practices and standards to emerge. I think it's really valuable for an ecosystem when there are single, well written, packages to address particular needs. For example, a single package for managing colors that all other packages build upon, rather than several color packages with inconsistent feature sets and have opaque types you need to convert between because PackageA uses ColorPackageA and PackageB uses ColorPackageB.
Edit: Here's another example from the Elm community image.png. And to make it worse, I have a package for sending emails that uses its own implementation because none of these 3 suit my needs. This is the sort of situation want to want avoid in Roc :sweat_smile:
Georges Boris (Jul 14 2022 at 12:56):kinda drifting the topic but in response to you @Martin Stewart - it would be awesome if Roc's package system contained more information than Elm's... having multiple published packages is a much smaller problem when you have more info available "what is the most used? what is the one with most recent adoption?" etc.
Richard Feldman (Jul 14 2022 at 12:59):this is probably worth a separate thread, but I think "what is the most used?" and "what is the one with the most recent adoption?" are problems that haven't been reliably solved in any language :sweat_smile:
Last updated: Jul 26 2025 at 12:14 UTC