I think it would imply that it is a Turing incomplete language. So, it would not be able to express certain programs, but all the computation you can represent is mathematically shown to reduce to a termination point.
IIRC they do some stuff with f co algebras. Which if I understand it is effectively doing things like "hey here's a generator that produces an infinite number of the number 1, but the only way to evaluate it is via a take with a finite number".
I know with idris there is also a progress evaluator for otherwise general recursion that proves that your input is always "getting smaller". Not sure if charity has the same deal or not.
Regardless, it isn't turning complete, but the interesting part is how far you can get in a sub turing environment.
If you have the time, it would be great to see you trying out Radicle, even if it’s just for a mirror to start; then see how we can turn that into something more integrated!
I remember the day Rúnar told me he was going to work on this new language called Unison.
I have always thought it was an amazing project to set out on, and was paving the way for a new kind of paradigm. Super proud to see them release a 1.0 and I would love to say Unison is my go-to language in the near future!
I’m pretty sure one of the Zed founders wrote tree-sitter, so I’m sure there’s some overlap
It’s really cool to see tree-sitter unlock so many of these use cases. I love using [difftastic] for my diffing tool to get context aware diffs. So in the example from the article, the diff would highlight the `void` and `int` changes with a heavier background of red and green respectively
Max Brunsfeld in fact, yep. He went along to Zed from the Atom team.
But curiously Zed hasn't been very interested in Tree-sitter. They don't seem to see it as having much strategic value to their company, which is odd because lots of other people do see it as a valuable platform. You have Tweag building code formatting on it, you had GitHub building stack graphs on it, you have Merigraph. You even have sone really "out there" stuff like the Software Evolution Library!
It comes down to tree sitter being the heart of a semantic IDE. If you use Tree sitter's data to apply a fix for a formatting problem or a lint error you are making a semantic edit to your code using it: you aren't describing that change in terms of the line/col in a text buffer then, but first in terms of the path to the node you wish to adjust in the syntax tree and the semantic rules used to target it.
Zed doesn't want to build a semantic IDE. They've said it a million times, they want to build a text editor, so they just aren't going to put the tree representation at the center of the experience. A text editor's UX is built around the text buffer so that it emulates experience of coding while sitting at a typewriter filling out punch cards. We can do better than the typewriter as the anchoring metaphor for all UX!
I think those projects I listed that build on top of Tree-sitter (all ignored by Zed) all see the potential of semantic changes and of Tree-sitter as a platform for making them.
I don't mean a standalone syntax highlighter, I mean it's a whole environment in which you can write software and in which things integrate. An Integrated Development Environment.
But Zed doesn't want that product. That product, if they cared that they owned it, would compete with Zed
I believe the after change hovers over the before line. So if you go back to the video, e.g. at 27s in, there's a lightning bolt highlighting which line is going to be changed, then there's a box, with "tab" at the end, above the line, highlighting the change that will be performed :)
We're quite aware that Git is a distributed code collaboration tool, even trying out the email based flow in the past :)
You may notice that the title is "peer-to-peer code collaboration stack built on Git", emphasis on "built on". We're using Git as a storage and transport mechanism for code collaboration data. So we're building a local-first tool for the social data, e.g. patches and issues.
The Radicle project doesn't involve the crypto token, started by Radworks, in its technology.
It's also stated in the FAQ on the website (https://radicle.xyz/faq) that the project is funded by Radworks and also provides a link to the funding page.
I, for one, work on Radicle and what I care about is the data sovereignty and local-first code collaboration. We're building on top of Git to provide a local-first, extensible collaboration experience -- avoiding walled gardens like GitHub :)
As a project team, we only posted once on HN when we were announcing our v1.0 release candidates. The other two posts have been from other people outside of the organisation, so it's nice to see there's interest in the project but don't blame us for that kind of hype :')
At the moment there isn't any mechanism for that kind of drive-by action. The current mechanism for creating an issue requires that a Git reference is created (the COBs structure) for replicating by other nodes.
Perhaps in the future, a user could use a web interface for a Radicle node and they post it directly from their browser. Some questions about that would the verifiability of that action though. Definitely some food for thought here!
reply