Announcing #junelang, an experimental safe systems language with a focus on being readable, learnable, and teach-able.

https://www.sophiajt.com/search-for-easier-safe-systems-programming/

The search for easier safe systems programming

Sophia June Turner

@sophiajt looks awesome! 😄 Looking forward to following the developments.

Quick question, how will `recycle` work on cyclic linked lists? Panic, keep the memory bloat (every pointer is still technically in use once), or somehow detect that the entire cycle can be recycled at once?

@basilehenry

it does a trace and then matches the trace count to the copy count. That works for structures with cycles, at least in theory.

@sophiajt @basilehenry Would you expect the average programmer (or say somebody used to a GCed language) to get away without ever calling recycle? Could you build a webserver with that without leaking memory as all the memory used for handling one request goes into groups that can be auto-reclaimed?
@mb21 @basilehenry maybe? The jury is still out on that
@sophiajt @basilehenry I think that must really be the goal. Otherwise people will just forget calling recycle in all the right places and memory will leak until the process is killed by the OS. That would be too much like in C, where the philosophy is more “if you do it well, it works well.”

@mb21 @basilehenry

perhaps, but I see this is a tooling challenge. We teach the developer about iterative improvement, we enable tracing in debug builds, and we light it up in CI. That way you can still get something to work quickly, and then iterate towards something that's good.

@sophiajt @basilehenry I like the iterative improvement philosophy. But memory leaks in common coding patterns is not the same as it just being a bit slow or memory-inefficient. It’s a continuum for sure: on one end is Rust, on the other end is only ever allocating memory and never releasing it, that would be the easiest for the programmer :P

@mb21 @basilehenry

hence the need for tooling

@sophiajt @basilehenry okay, you think that’s statically analyzable? or you have to run enough unit tests or something and then it may or may not tell you?

@mb21 @basilehenry

some of the folks I showed do believe that there's a lot of space for static analysis we could explore. Definitely something to look into

@sophiajt @basilehenry Then again, feels like if you do static analysis, you can insert the recycles automatically and you end up with something very similar to Swift’s refcounting.

Sorry to be so critical. I really liked everything in the post except for the manual recycle calls. But if the automatic grouping is good enough that e.g. everything in a web server request gets auto-collected and you never really need the recycles, that would be awesome.

@sophiajt @basilehenry (especially considering that you can also leak memory in GCed langs)

@mb21 @basilehenry

We wouldn't insert them automatically unless the user asks us to update the code. They need to be visible because they're a linear time operation, so the maintainers/reviewers need to see when the recycle happens.