5 comments

[ 3.2 ms ] story [ 31.5 ms ] thread
Nice article. It reminds me of another post a little while ago about OCaml. Like OCaml, Scala is getting more systems programming capabilities. Capture checking can, for example, be used to implement safe memory arenas (aka slab allocation or memory pools.) If you can prove that no code has captured anything from the arena, you can prove it is safe to deallocate the arena. This is less fine-grained than Rust's approach, but I think it is much more usable. I think of it as similiar to Zig's approach but with safety guarantees.

The other part, doing away with monads, is also exciting for FP nerds like me, but probably less generally exciting as it doesn't add new capabilities to the language so much as make existing capabilities easier to use (puns intended, of course!)

Meh. Scala's great strength used to be a simple, consistent model instead of zillions of ad-hoc features (e.g. implicits replace maybe 5 or 6 special-case features in other languages). But Scala 3 seems to be determined to destroy that elegance and turn into a pile of special cases. If I wanted that I'd use Kotlin.
Oh, Scala...I thought the language was practically dead.
Scala is very much alive, it's just past the initial hype stage, well into the slope of enlightenment / plateau of productivity depending on which style of Scala one is into. It's now growing slower but based on more sustainable pragmatism instead of just hype.
Does the capture check on Secret prevent you from just using `_.value` as your extractor now? I'm not seeing how this approach could ever be made to work without tracking primitives, and even with that it's not clear that you can actually use this to prevent a leak. You're always going to have to serialize the secret somehow (unless the capability is entirely used as a token within your same process, and then you don't need to wrap anything and can just pass an opaque object around), so you can always get at it.