I can't believe I'm suggesting this... I guess I love big PR's... anyway.
@Sam Mohr pointed out that we are effectively making a breaking change with the basic-cli PI changes. Also we have Str.fromUtf8
staged ready to go.
Maybe we should just double down and make all the builtins snake_case
too, and do another big-bang release all the new things together when we've had time to polish them and test everything?
This would delay basic-cli and webserver PI landing until probably mid-late Jan though.
If we keep it as is, there's a chance we land those upgrades (in pre-release form) later this week in time for Christmas and the holiday season (I assume everyone else get's holidays around this time of year :holiday_tree: )
It is a little strange seeing the occasional Str.camelCase
for builtins, but I'd say it's pretty minor impact.
I would push to release it sooner rather than later
Many breaking changes are in the pipeline. As they arrive we can keep cutting new releases.
That gets it tested and gets people to avoid Task, which is really nice
Hopefully not too long from now, I'll be fixing abi stuff (which also will probably be a breaking change for all platforms).
For AoC folks, would this look like "hey while you're here, here's an optional upgrade to try some 2025 Roc syntax"?
Even if it releases before Christmas, I don't think we really need to push this year aoc over to it
Just note that people can try it and we would love bug reports
yeah also keep in mind that at this point pretty much everyone is either done with AoC or already has a working setup and doesn't need to change anything :big_smile:
also we can release a new basic-cli without updating the tutorial to reference it
I think PI is so good that making people wait until January isn't worth it. I presume a casual Roc user would prefer having two breaking updates released as they are ready rather than having to wait a month and a half for a polished single break
also I think landing it with a note in the readme like "hey fyi we're in the middle of a snake_case transition in case you're wondering why this is snake_case and builtins aren't!"
would be helpful
Richard Feldman said:
yeah also keep in mind that at this point pretty much everyone is either done with AoC or already has a working setup and doesn't need to change anything :big_smile:
True, there's a low chance of someone needing a bugfix in the next few weeks.
I’ll get the formatter fixed right now to make the builtins transition a little faster
Get ready to List.walk_with_index_until
Luckily I think walking generally will go the way of the buffalo with for
If I wasn't logging off for the day I'd write a working Roc app version of the "buffalo buffalo buffalo buffalo buffalo buffalo buffalo buffalo buffalo buffalo" sentence.
Damn, forgot I needed to update to LLVM18 and Zig 13
Should be pretty easy to upgrade
Yeah, it wasn't bad at all
Just brew takes a while sometimes, and I only had 20 minutes :-)
This is where nix is super amazing
Yeah just having a program make such major changes to my file system is just not something I feel comfortable with until I have time to understand it deeply - which isn’t right now :grinning_face_with_smiling_eyes:
What's the origin of your trauma? :p
To be fair, nix has its own folder and is pretty contained
Just downloads a lot of crap and makes them priority in path
For me I’m sure nix is great. Lots of people love it. I just want to actually understand all the pieces before I go in
Nix is a very deep rabbit hole
I know and I don’t have enough time to visit
Maybe 30 mins in the morning and sometimes 30 at night
The rest of my time is looking at Zulip while waiting for something to load or compile at work
Anthony Bullard said:
I just want to actually understand all the pieces before I go in
Depending on your definition of understand that may be impossible at this point
Brendan Hansknecht said:
Anthony Bullard said:
I just want to actually understand all the pieces before I go in
Depending on your definition of understand that may be impossible at this point
You aren’t selling it :joy:
Reminds me of this
If only I knew how to drive a meme generator, there's an opportunity here somewhere @Anthony Bullard
You aren’t selling it :joy:
Just being honest. It is one of those super complex systems that getting a rough picture of isn't too hard, but truly understanding +especially the full thing) is exceptionally difficult. Just like Linux or many other large pieces of software. Made worse by the fact it is trying to deterministically and idempotently manage essentially all software in existence.
At the same time, it is simply awesome. I CD into my roc dir. It automatically loads up every dependency and everything just works.
Being able to go back to old commits and being 100% sure all the dependencies are correct is a life-saver too. An order of magnitude more convenient compared to manually uninstalling and installing things.
Yeah, makes bisecting bugs and measuring perf changes way easier.
I've been thinking about this a bit more...
Can we duplicate the builtins, and expose both a snake_case
and the current version to assist with a transition.
This wouldn't be a breaking change I think.
We have doubled the number of functions in the builtins, though we could mitigate this by keeping all the new/old functions together and not mixing them so they aren't displayed together in the docs.
This wouldn't be breaking. If you think it'd be less effort than just making the change (which I expect would be the case), then this is a good idea.
There is probably a way to automatically do this. Any function call to a builtin gets translated from camelCase to snake_case
So you would see all the camelCase and then all the snake_case ones?
And that gets paired with a change of the builtins to be snake_case
You could migrate it, copy, undo the changes, and then paste :-)
I was thinking... of duplicating, and replacing the implementation with an alias
I think this would be really confusing to anyone who visits the builtin docs during the transition :sweat_smile:
That seems like more effort than having canonicalization-level translation
Richard Feldman said:
I think this would be really confusing to anyone who visits the builtin docs during the transition :sweat_smile:
Yes, I agree... this is my main concern
I think it's probably less disruptive to just make the breaking change
Richard Feldman said:
I think it's probably less disruptive to just make the breaking change
It's pretty painful getting fresh releases of all the platforms coordinated
Actually, roc migrate
should just make this pretty simple
If we get my PR in, migrate should work flawlessly: https://github.com/roc-lang/roc/pull/7402
I just need to back out the snapshot stuff
Anyone else that has time can feel free to do that as well. It's dinner time in the Bullard Household :pizza:
I'm not worried about actually implementing the change to snake case in the builtins .roc
files... it's the impact on the platforms and ecosystem from a breaking change that makes it difficult to land.
I'm hoping we might be able to find another solution
If the duplicate (the current camelCase version) doesn't have any doc comments, it's not going to show in the docs right?
So to clarify @Richard Feldman, it's only confusing in the sense that you see current code that works, but can't see the camelCase
version in the builtin docs... but it is there in snake_case
form
I think the duplicate version will prob still show up even without doc comments
but we could manually filter those out
for builtins
or just temporarily change how that works in roc docs
- I don't think anyone is relying on it for things that don't have doc comments at the moment :big_smile:
Would it be a feature that is needed in future, like a doc comment that says "dont include in the docs"?
nah
we can just temporarily do without
Related topic, and feel free to move this out if it feels right, but with PNC about to land should we make sure to include that. And @Luke Boswell if this is going to be a while, should I make the migration flag parameterizable so that we could just migrate one of (snake_case and PNC)?
I'm not quite following your question... what should we include?
Do you feel we should get the snake_case builtins in before PNC?
I mean when you do the migration - should we make sure to wait for PNC to land and just do it at once. It has no actual impact on user code at all
And the second part - pointed at you - is do you think the snake_case migration will take long enough that we'll want to do the PNC migration separate?
Ah, yeah that could be good. I was only thinking of changing the function definitions and not all of the code/impl.
Oh right, you are just going to kind of proxy it in can or something?
As in I was thinking of just doing the user facing/affecting stuff, and looking for a way to mitigate the impact
Ok, well maybe we can do it as a separate piece of work
As soon as we have your change in, I want to migrate the examples full bore
No, we discussed duplicating the exposed definitions with both the current and a snake_case version. Like having both Result.mapErr
and Result.map_err
and then just filtering out the non snake case version manually so it doesnt show in the docs website
I haven't started on this yet... I've been taking a little break doing other side projects around the house
No worries and no rush at all!
I'm not stressed when we do it, I just was wanting a way to migrate incrementally.
Last updated: Jul 06 2025 at 12:14 UTC