Sophia J. TurnerAnnouncing #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/
J Λ M Ξ S@sophiajt very exciting!
Travis B. Hartwell@sophiajt Very interesting! I'll definitely be keeping my eye on the project. I'm barely out of the beginner stage with Rust and it feels like there are many corners that would make it difficult to get beyond that.
David Wilson@sophiajt congrats! I really want to sit down and try it out soon, sorry I wasn't more helpful during the beta period 😅
Baz@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?
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 nice! 😊
I can see the similarities with a GC. The fine grain control is very cool!
Another quick question, for the free lists to be efficient, I imagine you only store objects of the same size in a given allocation pool, is that right? So it's a bit like you have a ref pool for each type? Or maybe there's some sharing if different types have the same size?
@basilehenry they aren't implemented yet, but there's good work on free list optimisation we'll no doubt leverage
mb21@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.”
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
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?
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)
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.
vera grey 
@sophiajt hell yeah, congrats on shipping! this looks neat
Doug Gregor@sophiajt Congrats on the announce!
Nate@sophiajt I'll be following this for sure.
soc@sophiajt Congrats!
The ideas and axioms are definitely worthwhile to explore, even if the language itself is not my jam.
Tom@sophiajt Nice. Is there any future where memory recycling is automatic? I read the reasoning, but... that bit sapped the enthusiasm that had been building in me.
@tjk doubtful. It's still a systems language at its heart. We don't want to hide performance costs.
@sophiajt To me, that makes it feel lower level than Rust, having to think about 'free'/recycle statements. Lifetimes, and the other things June removes/hides, seem like higher-level concerns that I can understand having to learn, even if it's not easy; thinking about whether I'm using a part of memory feels like C. But this is why we have different languages; people think differently :)
Wesley Moore@sophiajt Congratulations! Fascinating project. Excited to see where it goes
James Widman@sophiajt will it support custom allocators (like, maybe with something similar to placement-new in C++, where the user can write an overload of 'operator new' that can accept their own custom allocator type)?
yes, very likely it will support changing out the program allocator (and maybe even fancier allocator configurations)
Genders: ♾️, 🟪⬛🟩; Soni L.@sophiajt whoa. have you heard of the "selfref" crate in rust? we can see some interesting parallels between what you're doing here and what we did there...
haven't heard of that one. someone else mentioned another crate that did some similar things. Would be nice to have Rust let you do some of these things more easily.
@sophiajt we quit rust development but, yeah, it really would.
we made "selfref" as part of trying to rewrite hexchat in rust. we never finished that, but for the parts we did do, it worked really well. we never used its theoretical ability to have cyclic linked lists and whatnot tho.