In C# the LSP (that's a bit more complicated there, but let's say the LSP) can show you things like this:
![]()
Object allocations, things escaping scope etc
I think it would be great if the Roc LSP provided a highlight for when the reference count increases above 1, and then another one when it increases further. This would make writing optimized programs much easier.
I've using Roc a bit here and there, mostly for agents skills to replace Python, and sometimes I "race" it against F#, Python and some others, and then ask the agents to optimize the program because I want Roc to win of course. When it gets stuck, I give the compiler repo as context, so it learns about all the in-place mutations options, and that ends up being the biggest factor in real life things.
Probably an LSP indication (or even something weaker than compiler warning, like a diagnostic) that points "this line allocates on heap", "this line makes the ref count 2, so no in place mutation" and would make this much easier, not only for AI.
If it offers a code action fix "refactor for in-place mutation" - that's even better!
is that achievable?
Kind of related ... but for optimizing pure Roc implementations, I like to kill two birds with one stone. I reach for roc-fuzz and write lots of small property based fuzz targets, and include memory invariants I want to hold too. This has the benefit of flushing out unnecessary clones, scaling issues, and also catches correctness bugs all in one swoop.
My biggest pet peeve with Roc by far is that performance guarantees are so brittle when it comes to the reference-count optimizations. I don't oppose the optimization itself, but I agree with Krzysztof Skowronek that it should be more transparent. I would actually go further than the LSP and ask for first-class language support for it.
Steve Howell said:
that it should be more transparent. I would actually go further than the LSP and ask for first-class language support for it.
I think everyone is aligned and would love to do this... getting a design that fits well and meets everyones needs it the hard part.
yeah, performance is quite brittle if you change the code in a way that removes the in place mutation, and you have to guess whether it's still applied
I have created a vague issue #12676 to make sure we address this, this has been requested several times before.
Last updated: Nov 04 2026 at 18:54 UTC