benjreinhart

> This is not an anti-AI stance. This is an anti-idiot stance. Ghostty is written with plenty of AI assistance and many of our maintainers use AI daily. We just want quality contributions, regardless of how they are made.

Love this, +1

Love the history you weave into these posts!

It's crazy how much of the world still relies so heavily on FTP and SFTP for critical day-to-day operations.

Related, but for us at Mocha, this past year was the first time in a while that I had used SSH and we were doing so programmatically for a few things. These protocols have survived the test of time!

Woo super excited for this. Is anyone working on the official vscode extension so we don't have to build and hook that up ourselves, or is that up for grabs still?

We're still in the very early stages of rolling this out (alpha), so I'm not going to overthink it right now given we have a solution to disabling it. But I think your proposal might be a good idea once we come out of alpha, so I'll put that in our roadmap.

Very much appreciate the feedback

Super interesting combination of tech, well done!

Hey all, I'm one of the authors. We've been using this to build a few different applications and it's been a joy to work with. Needless to say, we're very excited about this and happy to answer any questions or help however we can!

Hey Chris , can you further qualify performance?

Before I share some thoughts on this, let me just say that our primary motivators for Axilla have much more to do with bringing better AI tooling to an otherwise flourishing ecosystem rather than shaving milliseconds off an arbitrary task or request. Given that, I'm not sure how fruitful a performance discussion will be.

If by performance you meant maturity of third party packages for AI-related functionality, then yes JS/TS is lacking. This is what is motivating us :). We want better tooling for AI applications in TS.

If you're referring to performance for CPU-bound tasks, then yes JS would not be as good as lower-level languages like Rust or Go. If you're referring to JS compared to Python, then I don't know how true that is. Python doesn't have a great concurrency story either (at least not today). JS may be single threaded for the most part, but with web workers and WASM (+ WebGPU!), we now have tools at our disposal for dramatically speeding up CPU-bound tasks while not blocking the main thread. Assuming we get the interfaces right, we can swap out a subset of the implementation with a WASM-based implementation later if justified.

There is nothing about Python the language that makes it especially well-suited for AI/ML-related functionality. It is just the language whose ecosystem has the most maturity when it comes to that functionality. We hope to chip away at that over time.

Yes, we largely agree with you on that. The APIs are high-level enough that wrapping really doesn't add much value in many circumstances.

We chose to do this for our first module to take a stab at integrating RAG pipelines in a coherent manner, but we don't plan on following this pattern in all modules within our framework. There is possibly one exception here, which is that an interface that allows composable middleware for things like logging, error handling, or redirecting of requests may justify wrapping in some places.

The next steps for us involve lower-level functionality. One need we see again and again is more robust data extraction and processing. Most people we talk to who use other community projects (e.g., langchain or llama) find that data loading and chunking are among the most valuable parts of those libraries. We agree, but would like more robust functionality for these tasks, so this is one thing we're working towards next.

Beyond that, we're working on infrastructure. Easy model serving from Node (for OSS or proprietary models), monitoring, and pipelines for fine-tuning based on production inference results.