I think we can step around this completely if we had a roc tutor type of experience
Kind of a little mini app called from the roc tool that on-boards the user
I guess I could just create roclings :tears:
3 messages were moved here from #ideas > "aka": APIs with multiple names by Anthony Bullard.
Kind of a little mini app called from the roc tool that on-boards the user
Would the onboarding be completely in the terminal?
Well that's one idea
The other is roclings - A project like ziglings/rustlings which is definitely terminal driven (with a cli tool), but the editing happens in the user's editor
If we had working wasm generation for real and could create a web platform, then you could imagine it even being in the browser
Yeah, I like in-browser on-boarding.
We gotta fix whatever the issue is with gen-wasm
Yeah, I like in-browser on-boarding.
It does not seem like a priority in the near future though
No, that's why I like the terminal approach
It was the way I learned Zig and it so _very_ fun
I need to try that :)
You should
And we can even maybe do it better when we have Sam's ... TODO syntax
Because right now you would need to commit invalid syntax for the "holes" to fill in
And example "porting" of exercise 001 from Ziglings:
# Oh no, this is supposed to print "Hello world!" but it needs
# your help.
#
# In Roc, the main function needs to be given to the platform
# for it to be executed.
#
# A function is provided to the platform in the header like so:
#
# ```roc
# app [function_name] {
# pf: "https://..../basic-cli"
# }
# ```
#
# Perhaps knowing this will help solve the errors we're getting
# with this little program?
#
app [...] {
pf: "https://..../basic-cli"
}
import Stdout
main = |_|
Stdout.line!("Hello world!")
Of course, some thought needs to be put into the narrative above, but I think it works well
I think having an in-browser experience is nice and the wasm compiler is a superpower for that (at least for cost - savings on server compute) . I enjoyed going through the go tour, even though I was much more comfortable within my neovim setup. The parts were so small, I wasn't bothered to write it in the browser.
The Go tour is good. But we don't have the resources I think to host a roc compiler service for potentially 10s of people concurrently
And then all the setup for a good editing experience etc
You could have an in-browser experience that's just "We explain and show a concept, and then you fill in the blanks and then we check it matches a predetermined result" system though
That might even dovetail with the new tutorial that Richard wants to build (I have no idea on the specifics of that idea though)
You could even set that up to be completely (actually) serverless
If everything is very constrained and well structured. But that means it will be a tutorial on stilts
But overall I think I personally would like to work on a Ziglings-style project. Implemented in 100% Roc of course
I've worked on the compiler a _lot_ recently, and the docs and website. I really need to inject some Roc into my veins so I remember what I'm working for :smile:
I'm going to move forward and start work on this in an unofficial capacity
Anthony Bullard said:
The Go tour is good. But we don't have the resources I think to host a roc compiler service for potentially 10s of people concurrently
it's possible for the roc compiler to run completely in the browser via wasm. Right now only the repl can do this, but we could expand that to work with things like modules
like the repl on the homepage is all wasm in the browser, and it's the full repl - same code base as roc repl on the CLI
Yep - there's just no effects
And you can't build a module, let alone an app
in the repl yeah
but we already separately have wasm platforms that run effects, e.g. https://bren077s.itch.io/rocci-bird
so the only missing piece (still a substantial project, of course) is connecting up the ability for wasm platforms to be built in a wasm build of the compiler
(and loading modules, of course)
Yep :-)
But I'm working on this CLI version.
After I scream at Sam for the weaver docs
Oh no, we like Sam
What's up with the docs, they look fine?
Skill issues more than likely, but I can’t get a very simple thing to compile
The opaque type docs seem to not get published since the type is not exposed
Anthony Bullard said:
After I scream at Sam for the weaver docs
This is why I wear earplugs
Let me know what I need to change
Anthony Bullard said:
The opaque type docs seem to not get published since the type is not exposed
ugh, I have a branch which fixes this but it's kind of a mess and changes a bunch of things in docs, probably has a pile of merge conflicts at this point :grimacing:
it's called can-docs if any brave souls want to delve into its depths
If no one gets to it, I'll try to fold that into my can efforts
After everything else
if you want to do it in the new can, we should talk about how it should be done - I'd do it differently when building it from scratch than what's on that branch :big_smile:
Okay, I'd expect it won't get touched for a few months, meaning it's guaranteed to be done in whatever the new way would be since we'll hopefully be done with the rework by then
We can sync whenever on that
I've got the first version of roclings almost ready to go. Missing three things:
Here's the help screen
Screenshot 2025-01-18 at 2.03.50 PM.png
Checking all solutions
Screenshot 2025-01-18 at 2.04.15 PM.png
Moving on to the next exercise:
Screenshot 2025-01-18 at 2.04.36 PM.png
I think my goal is 30 exercises for now
Working out the correct order of operations is probably the hardest part. Here's my outline:
# Lesson outline
## 001. Platform basics and Stdout
## 002. Assigning values and String literals
## 003. Calling functions
## 004. Numbers and String interpolation
## 005. Arithmetic operations
## 006. If-then-else
## 007. Top-level defines
## 008. Defining a function
## 009. Records
## 010. Structural typing
## 011. Lists basics
## 012. Dicts
## 013. Sets
## 014. Annotating defs
## 015. Comments and Doc comments
## 016. Destructuring
## 017. Debugging
## 018. Enums
## 019. Enum collapse
## 020. Pattern Matching Tags
## 021. Pattern Matching Other Types
## 022. Effects
## 023. Handling Errors
## 024. Heterogeneous List
## 025. Optional record fields / default values
## 026. Crashing your program
## 027. Expect
## 028. Wildcards (_)
## 029. Abilities
## 030. Early returns
...
## 999. What to do next
There's probably some moving around that needs to done, and some of these could be broken down some more. We might end up closer to 40-45 real lessons at the end.
I wonder if it's worth pulling something like a "learn you a Haskell" and doing "hello, world!" after the basics... Roc is a pure language that then works on top of platforms. We can encourage that thought pattern by starting with Roc the pure language for a few lessons
I really struggle with this
Because people are learning Roc to build applications
So a big part of me thinks of that starting with "repl-like" examples kind of goes against that
my feeling is:
it's good for people to know what the repl is, and also you gotta learn some basic syntax anyway that has nothing to do with I/O
but yeah, people want to build stuff, so get to that ASAP after some syntax basics in the repl
Ok, I can move 002-006 up to the top
I never run or execute these examples when checking them (I just compare them to goldens)
Though I will have CI to check and test the goldens
By the way, Roc is now my favorite scripting language
Little vim magic and Roc scripting and BOOM, issues for all the exercises:
https://github.com/gamebox/roclings/issues
Anthony Bullard said:
By the way, Roc is now my favorite scripting language
this is the first time I've seen anyone say this! :smiley:
That makes me super happy to hear - it's been a goal from the beginning to be great at that use case, and the language and ecosystem have gotten so much better in the past year...really awesome to see it turn that corner, thanks to all the awesome recent contributions! :heart_eyes:
PI is a big help here. Though there still are some rough edges, but overall just great. No type annotations or fuss, and I can just write stuff the way I want and I get great compiler feedback if I do something dumb
And I can just shebang the file, chmod it and run
I didn’t need an optimized build for a GH script since it’ll be slow anyway due to having to sleep in order to not make their api rate limiting mad
You can use the GITHUB_TOKEN to avoid rate limit issues. This is how we use it for a basic-webserver wokrflow:
https://github.com/roc-lang/basic-webserver/blob/8c95d6e9d41aa93bc5b7dd205f83dfa721f90b87/.github/workflows/test_latest_release.yml#L35
https://github.com/roc-lang/basic-webserver/blob/8c95d6e9d41aa93bc5b7dd205f83dfa721f90b87/ci/test_latest_release.sh#L57C20-L57C131
The GITHUB_TOKEN is available by default in github workflows, you don't need to change any settings
With Stdout coming after the basics (will come at num 6 after you moved the repl ones to the top), I would put Debugging right after that for num 7, so that you can continue with "But if you just want print debugging, you don't need to use Stdout. You can just call dbg myVar". I would use the dbg stmt during roclings if I were doing it, so the sooner it comes up the better I think. This enables others to experiment with the language more freely.
Last updated: Jun 16 2026 at 16:19 UTC