It is true that the current neatify scripts to not aim to replicate rustfmt. My personal goal is cross-language standardization, where reading Java, TypeScript, or Rust all follows the same visual "layout".
Of course, I totally understand that people often have very different ideas on formatting, depending on which tool they are generally used to. That's why I made the scripts pluggable.
If someone wants to build a rustfmt compatible formatting script in neatify, they can. The real power comes from being able to apply those same formatting rules to other languages to get a consistent result across a polyglot stack.
The age of MCP is not unlike that of microservices where the primary feature was polyglot implementations. Except now there is the added angle of AI generation.
The goal is to allow absolute freedom in formatting style across a broad range of syntaxes.
I absolutely love the tree-sitter library, I use it in a number of projects. One of those projects is to create syntax-aware embeddings. Currently the rules in that systems are still query based and lack flexibility when it comes to defining context. I'm actually thinking of taking some architectural ideas from Neatify's Rhai-bridge to make my embedding extraction more flexible as well.
The trick is that sometimes developers use a hybrid approach, AI + Human / IDE, and in this case, we use the language formatter (for example, rustfmt).
For example: For my AI Agent / CLI, the dev can add a sub-agent (non-AI) that just runs cargo fmt, and I can definitely see the value in including this as part of the default flow. But my issue is that it won't really follow rustfmt.
Am I missing something?
Anyway, this is great. And btw, I have been thinking about using tree-sitter for "context extraction / optimization" for code indexing, but I did not have time to explore this further.
I’ve spent the last 20 years building tools across a dozen languages, always adhering to a handcrafted personal style. But as the "AI era" takes over, my workflow has shifted. Coding is becoming less about writing every character of syntax and more about guiding LLMs—evaluating their output, intervening when they get stuck, and refining algorithms.
This shift created a new problem for me: I suddenly have a massive volume of code in languages I’ve used for decades, alongside languages I barely know. And frankly, it looks like a mess.
I tried existing formatters, but I kept hitting two walls:
- Lack of broad language support within a single tool.
- Too opinionated: most formatters give you a few toggles, but if you don't like their core philosophy, you're stuck.
So in the spirit of the age, I set out with AI to create a new formatter tool with a core written in Rust (for raw speed), Tree-sitter for AST (for its broad support) and Rhai scripts for dynamic formatting rules.
The system is set up to allow any language supported by Tree-sitter and any formatting (or linting) rules you want with the scripting interface.
Current Progress:
It’s already self-hosting (formatting its own Rust and Rhai code). I’ve also implemented initial support for Java, TS/JS, Markdown, CSS, SQL, Vue, HTML, and JSON.
Fun part? There is "fragment" formatting - for example, it can reach into Markdown and format the code blocks within the text with the matching syntax formatter.
It is true that the current neatify scripts to not aim to replicate rustfmt. My personal goal is cross-language standardization, where reading Java, TypeScript, or Rust all follows the same visual "layout".
Of course, I totally understand that people often have very different ideas on formatting, depending on which tool they are generally used to. That's why I made the scripts pluggable.
If someone wants to build a rustfmt compatible formatting script in neatify, they can. The real power comes from being able to apply those same formatting rules to other languages to get a consistent result across a polyglot stack.
The age of MCP is not unlike that of microservices where the primary feature was polyglot implementations. Except now there is the added angle of AI generation.
The goal is to allow absolute freedom in formatting style across a broad range of syntaxes.
I absolutely love the tree-sitter library, I use it in a number of projects. One of those projects is to create syntax-aware embeddings. Currently the rules in that systems are still query based and lack flexibility when it comes to defining context. I'm actually thinking of taking some architectural ideas from Neatify's Rhai-bridge to make my embedding extraction more flexible as well.
Very interesting approach.
The trick is that sometimes developers use a hybrid approach, AI + Human / IDE, and in this case, we use the language formatter (for example, rustfmt).
For example: For my AI Agent / CLI, the dev can add a sub-agent (non-AI) that just runs cargo fmt, and I can definitely see the value in including this as part of the default flow. But my issue is that it won't really follow rustfmt.
Am I missing something?
Anyway, this is great. And btw, I have been thinking about using tree-sitter for "context extraction / optimization" for code indexing, but I did not have time to explore this further.
I’ve spent the last 20 years building tools across a dozen languages, always adhering to a handcrafted personal style. But as the "AI era" takes over, my workflow has shifted. Coding is becoming less about writing every character of syntax and more about guiding LLMs—evaluating their output, intervening when they get stuck, and refining algorithms.
This shift created a new problem for me: I suddenly have a massive volume of code in languages I’ve used for decades, alongside languages I barely know. And frankly, it looks like a mess.
I tried existing formatters, but I kept hitting two walls:
- Lack of broad language support within a single tool.
- Too opinionated: most formatters give you a few toggles, but if you don't like their core philosophy, you're stuck.
So in the spirit of the age, I set out with AI to create a new formatter tool with a core written in Rust (for raw speed), Tree-sitter for AST (for its broad support) and Rhai scripts for dynamic formatting rules.
The system is set up to allow any language supported by Tree-sitter and any formatting (or linting) rules you want with the scripting interface.
Current Progress:
It’s already self-hosting (formatting its own Rust and Rhai code). I’ve also implemented initial support for Java, TS/JS, Markdown, CSS, SQL, Vue, HTML, and JSON.
Fun part? There is "fragment" formatting - for example, it can reach into Markdown and format the code blocks within the text with the matching syntax formatter.
Link: https://github.com/neatify-tech/neatify