HNHacker News
TopNewBestAskShowJobs

odvcencio

108 karma · joined February 25, 2026

submissionscomments
odvcencio··on Show HN: I ported Tree-sitter to Go
i really appreciated this comment the most because of how much work "somehow" is doing here
odvcencio··on Show HN: I ported Tree-sitter to Go
ii am trying to not take issue with this comment because im aware of the huge stigma around ai generated code.

i needed this project so i made it for my use case and had to build on top of it. the only way to ensure quality is to read it all line by line.

if you give me code that you yourself have not reviewed i will not review it for you.

odvcencio··on Show HN: I ported Tree-sitter to Go
the 90x figure is on Go source for apples to apples against CGO bound tree-sitter.

your use case is not one i designed for although yeah maybe the readme has some sections too close. the only external scanner missing atm is norg. now that i know your use case i can probably think of a way to close it

odvcencio··on Show HN: I ported Tree-sitter to Go
thank you for the kind words! Very cool project! Very happy you can find some utility in it
odvcencio··on Show HN: I ported Tree-sitter to Go
yes and if you clicked the links you would know that i did answer it in the readme.
odvcencio··on Show HN: I ported Tree-sitter to Go
well how did it do?
odvcencio··on Show HN: I ported Tree-sitter to Go
re: up to date grammars, yes i found the official grammars in use by the original tree-sitter library today
odvcencio··on Show HN: I ported Tree-sitter to Go
yes basically about 70% of the engineering effort was spent porting the external scanners and ensuring parity with original (C) tree-sitter
odvcencio··on Show HN: I ported Tree-sitter to Go
206 binary blobs = 15MB, so not crazy but i built for this use case where you can declare the registry of languages you want to load and not have to own all the grammar binaries by default
odvcencio··on Show HN: I ported Tree-sitter to Go
yeah the tests live with the implementation code always (Go thing) and the repo root thing is like a preference, main is an acceptable package to put stuff in (Go thing), i see this a lot with smaller projects or library type projects
odvcencio··on Show HN: I ported Tree-sitter to Go
gah,. sincere apologies for formatting of this post. i ahve been on HN for basically 10 years now without ever having made a post (:
odvcencio··on Show HN: I ported Tree-sitter to Go
it is interoperable with git. we like git when its good but attempted to ease the pains in UX somewhat. you can take advantage of got locally but still push it to git remote forges jsut the same. when you pull stuff in this way, got will load the entity history into the git repo ensuring that you can still do got stuff locally (inspect entity histories, etc)
odvcencio··on Show HN: I ported Tree-sitter to Go
primarily, got is structural VCS intended for concurrent edits of the same file.

it does this via gotreesitter and gts-suite abstractions that enable it to: - have entity-aware diffs - not line by line but function by function - structural blame - attribution resolution for the lifetime of the entity - semver from structure - it can recommend bumps because it knows what is breaking change vs minor vs patch - entity history - because entities are tracked independently, file renames or moves dont affect the entity's history

when gotreesitter cant parse a language, the 3way text merge happens as a fallback. what the structural merge enables is no conflicts unless same entity has conflicting changes

odvcencio··on Show HN: I ported Tree-sitter to Go
thanks so much for the note! i really appreciate it. i built this precisely for folks like yourself with this specific pain, thanks again!
odvcencio··on Show HN: I ported Tree-sitter to Go
oh wow! i really thought i was being too clever but i shouldve assumed nothing new under the sun. well im taking name suggestions now!