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!
Git is just a mechanism for storing plain-text data as a series of commits. The underlying data are just blobs of bytes. So all data is Git data and Radicle takes full advantage of that.
The "special" data in Git would be `refs/heads`, `refs/remotes`, `refs/tags`, and the lesser known `refs/notes`. Radicle doesn't touch those directly, we still allow the use of Git tooling for working with that data.
It then extends on top of these by use `refs/rad` and `refs/cobs` for storing Radicle associated data, using all of Git's mechanisms that it provides to do so.
I'd like to note here that Radicle has defined our own version of issue and patch management, but they're not necessarily required to be used as part of the protocol. The protocol only defines that any and all COBs will be stored and replicated under the `refs/cobs` hierarchy.
If someone wanted to come along and define a way to embed Fossil wikis/issues as a COB then they could be replicated on the Radicle network and it's then up to application developers to load and interpret that data.
I think this is cool because it essentially allows developers to extend the Radicle ecosystem easily and define new workflows! However, that does not avoid our XKCD problem stated above ;P But hey, sometimes that's the beauty of these things -- we're given the power to define our own workflows and not locked into something everyone complains about coughGitHub branches PR flowcough
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!