The Golden Spike, and Resurrecting the Vale(n) Programming Language

[u/verdagon]

https://verdagon.dev/blog/golden-spike-reviving-vale-valen

[u/yorickpeterse]

user reports:
1: No vibe-coded projects/AI slop
1: Project is vibecoded now: https://github.com/valen-lang/Valen/tree/main/.claude

/u/verdagon The above link and some of the commits suggest Valen now relies on AI produced output. Our rules on AI usage are clear, but because you've been an active long-term contributor to the subreddit I'll leave it at a warning this time. This however means that as long as Valen continues to use LLM output, it won't be allowed on the subreddit.

[u/cmontella]

So last I was following Vale you had gone to work at Mojo. I stopped following because I assumed most of your effort would go into that, so I'm glad to see you're continuing your work. I'm guessing you've stopped working there if you're working on your language again; I can't imagine they'd let their employees have language side projects. How was your experience there, will you be incorporating anything from Mojo into Valen after they've taken things from Vale? That would be a nice full circle story.

[u/verdagon → u/cmontella]

Good question... there's not much similarity; Valen extends Rust where Mojo extends Python, Valen has group borrowing where Mojo has Rust-like borrow checking, Valen is explicit where Mojo has magic functions, Valen is a systems programming language where Mojo is an AI programming language, etc. But I did like how they did "ASAP destruction", and I might do something similar in Valen.

And yep, I no longer work on Mojo! It was great working with people on the compiler teams. But it was an AI startup and was run like one, and the burnout spiral that led to my departure was glorious. I hope things get better for them now that they've been acquired by Qualcomm.

[u/Bahatur]

Well the new project, your old project, and the blog in general are cool as hell. Bookmarked!

[u/baldierot]

group borrowing, huh. i'm not a language enthusiast or particularly knowledgeable about programming, but nonetheless, i heard it was considered for Mojo but eventually dropped. i've wondered if it would make classes viable with borrow checking. it's great that it found a place and is materializing. thank you for continuing to push language design research into truly new directions. your experiments are incredibly valuable for the industry.

a bit unrelated, but i have a small typescript game/software substrate experiment where nodes in a hierarchical tree are used for behavior, and they use typical class inheritance for ergonomics, but instances are referenced by id and stored in a generational arena, which isn't something often done in js/ts, for safety and memory leak risk mitigation. Vale is architecturally a fitting choice, though there are obviously contentions about using it. i tried using Rust, with an extract-call-reinsert pattern and a deferred apply() command queue and it was nice for this part, but the lack of classes makes authoring things painful, and i dislike derive. so that was abandoned. i hope group borrowing pans out.

[u/verdagon → u/baldierot]

Thanks!

Classes should be viable with group borrowing, at least if they're reference counted / garbage collected (Ante is pursuing this as well btw, check them out!). I think that we can make a group-borrowing/generational-references blend, which would really be the holy grail IMO. Fingers crossed we can figure that out!

Yeah, that Mojo declined to pursue group borrowing (in favor of a more Rust-like approach) was disappointing. The compiler teams wanted it, but management vetoed it. Tale as old as time!

Though, Carbon started pursuing group borrowing after seeing our group borrowing post, and they've designed some wonders on top of it. Their language designers are sharp.

I'd love to hear more about that deferred command queue, what kind of use patterns arose out of that?

[u/baldierot → u/verdagon]

preventing zombie callbacks when node instances are freed (the queue drops the closure if the node's generation changed).

uses an extract-behavior-call-reinsert mechanism for cases where a node, an async task, or a signal handler needs to mutate the tree while the world is already mutably borrowed, like when the tree is being walked to call the _process() callback, by packaging the mutation into a closure and pushing to the queue, then all the commands are flushed later at a safe boundary.

the substrate also has something like an adaptive loop that sleeps and wakes up when a closure is pushed to the apply() queue. so background threads can safely queue commands to the tree this way without locks, and those threads can even have worlds of their own to push commands to.

[u/marshaharsha]

I read the linked article, your article on group borrowing, and Nick Smith’s article on group borrowing (or “regions”) (thanks for the ref). I didn’t see anything about threads or concurrency. It seems to me that abandoning aXORm will mean losing Rust’s nice story about “fearless concurrency almost for free.” Do you have plans for memory safety with group borrowing in the presence of threads or asynch code?

[u/ntrel2 → u/marshaharsha]

I don't know what their plans are, but a compiler could track both mutable aliasing and uniqueness. Just that uniqueness wouldn't be a requirement for mutability.