This is an oft-expressed refrain. But there are good reasons to not want to use Chinese models (or models from any adversary for that matter).
1. They may be trained, in theory, to inject subtle back-doors into certain kinds of generated code.
2. They may be also trained to include back-doors when deployed in public-facing services where user can provide text or image input.
3. Chained with (2) they may be also trained to exploit their inference environments, which though a big feat, not outside the capability of nation-state hackers.
* How many lines was the result? Considering how much err != nil and line splitting needs to be done in Go, did you at least reach 30k SLoC?
* How was sloc counted here? includes comments, blank lines or not? (something like cloc will give a good answer).
* Performance characteristics of resulting rust, was there an improvement? It maybe appealing to say Rust is Always faster than Go.
As usual these AI coding posts tend to be loose on actual measurements. Don't like it. Granted you can't do too much experimentation with prompting techniques since you're paying per token. But at least you can assess the code that was produced?
Thanks for the feedback. My main goal was to present the idea with an intermediate representation, I didn't payed much attention to the specifics of this translation, it would vary wildly depending on code bases.
65k LoC of Go without comments resulted in roughly 60k LoC of Rust witout comments (code column of the cloc tool).
The error handling is not so different between Rust and Go, in both cases I cannot panic to avoid the data loss. So it boils down to if (failure) return something for graceful degradation. And generally errors in my case (a text editor) are rare, only disk IO, which is encapsulated in one VFS module, everything else, like non-closed brackets in code is expected behavior.
The biggest differences were in third party libraries, UI, markdown parsing — completely different API and paradigms.
> Performance characteristics of resulting rust
I haven't measured. I don't think there's any significant difference between Go and Rust if app doesn't do allocations on a critical path. The reason I started this project was mainly to experiment (now I use similar approach to refactor much bigger legacy code base), and tree-sitter support is better Rust so it seemed like a good fit.
It would help to clarify these things in the post. Your software is atypical of common Go software in the wild. The purpose of Go -> Rust rewrite would be usually the efficiency of rust.
It's laughable to suggest few people can change OpenAI's destiny by not using uv. Even if Astral goes bottom up, nothing happens OpenAI. So it's not like using ChatGPT.
CGit being a html-generator with arbitrary combinations seems particularly vulnerable.
I am in a similar situation - I have a hobby web tool hosted on AWS lambda's free tier behind cloudfront which is quite economical (I usually stay below limit).
But over last 2 months I am getting many thousand requests a day. In theory there aren't many crawlable pages in my site but these bots are hammering the search endpoints with arbitrary queries which are somewhat related to the subject matter (must be powered by some weak LMs because they're not valid queries, just generated in a plausible way).
I have seen quite a few websites put behind anubis or some other sort of verification system in last 6 months or around. This satire from Krazam [1] was on point.
> I’m not packaging this application up. If you want it, just screenshot this section of the post and give it to Claude. It’ll build something useful. You see where I’m going with this.
This pretense that the entire value of source code is the "spec" / "requirement" is alarming.
The value of the code is how well-formed the spec is + how well tested it is in the real world. So prompt / mockup cannot replace code.
Don’t forget operations and maintenance. You can have a box of vibe coded custom tools and services, but they’re all going to slowly rot as the underlying dependencies - network APIs, platform APIs, auth handshakes, reverse engineered file & DB schemas - change their behaviors and availability.
Sure, an LLM can fix it, but that assumes your original spec sufficiently described the user requirements and wasn’t just a transcript of the original session trying to figure out how how to interface with all those dependencies in the first place.
How do we know they don't? Who is going to read the source for all these micro packages?
You might assume we are able to detect all malicious behavior at runtime. But "stuxnet" and more recently, the xz compromise say otherwise. What if a not-so-popular crate deep in the dependency chain subtly introduced a LPE in it's code?
1. They may be trained, in theory, to inject subtle back-doors into certain kinds of generated code.
2. They may be also trained to include back-doors when deployed in public-facing services where user can provide text or image input.
3. Chained with (2) they may be also trained to exploit their inference environments, which though a big feat, not outside the capability of nation-state hackers.