And now everyone is rewriting everything in Go/Rust left and right.
And now everyone is rewriting everything in Go/Rust left and right.
I'd argue Rust and Go are even easier to work with than Python/JS/TS. The package management is better, and static linked native binaries eliminate so many deployment headaches.
Go used to try and let you do it, but has walked back those implementations after all the bugs they've caused, in my understanding.
Sometimes people really need to follow Yoda and Mr Miyagi advices, instead of jumping right into it.
Go and Rust prove you can get most of the benefit of C/C++ without paying that complexity cost.
Especially interesting for software that are 99.9% of the time waiting for inference to come back to you. Sure, makes sense to rewrite something that is heavily relying on the CPU, or where you want an easier time to deal with concurrency, but I feel like that's not what makes Codex takes long time to finish a prompt.
With that said, I also rewrote my local LLM agent software to Rust, as it's easier to deal with concurrency compared to my initial Python prototype. That it compiles into a neat binary is an additional benefit, but could have as easily gone with Go instead of Rust.
In a different domain, I’ve seen a cli tool that requests an oauth token in Python be rewritten to rust and have a huge performance boost. The rust version had requested a token and presented it back to the app in a few milliseconds, but it took Python about five seconds just to load the modules the oauth vendor recommends.
That’s a huge performance boost, never mind how much simpler it is to distribute a compiled binary.
I agree it’s hell. But I’ve not found many comprehensive packaging solutions that aren’t gnarly in some way.
IMHO the Python Packaging community have done an excellent job of producing tools to make packaging easy for folks, especially if you’re using GitHub actions. Check out: https://github.com/pypa/cibuildwheel
Pypa have an extensive list of GitHub actions for various use cases.
I think most of us end up in the “pure hell” because we read the docs on how to build a package instead of using the tools the experts created to hide the chaos. A bit like building a deb by hand is a lot harder than using the tools which do it for you.
In my opinion, bundling the application Payload would be sufficient for interpreted languages like python and JavaScript
Even if a GC'ed language like Go is very fast at allocating/deallocating memory, Rust has no need to allocate/deallocate some amount of memory in the first place. The programmer gives the compiler the tools to optimize memory management, and machines are better at optimizing memory than humans. (Some kinds of optimizations anyway.)
Module import cost is enormous, and while you can do lots of cute tricks to defer it from startup time in a long-running app because Python is highly dynamic, for one-time CLI operations that don’t run a daemon or something there’s just nothing you can do.
I really enjoy Python as a language and an ecosystem, and feel it very much has its place…which is absolutely not anywhere that performance matters.
EDIT: and there’s a viable alternative. Python is the ML language.
"The existing code base makes certain assumptions -- specifically, it assumes that there is automatic garbage collection -- and that pretty much limited our choices."
this is next Trends
An announcement of Codex CLI being rewritten in C++ would be met with confusion and derision.
Why would you say this for Rust in particular?
The comment you linked is talking about unspecified application's runtime errors.
When I have a smallish application, with tests, written in one language, letting an LLM convert those files into another language is the single task I'm most comfortable handing over almost entirely. Especially when I review the tests and all tests in the new language are passing.
Note that most of these rewrites wouldn't be needed if the JIT language would be Java, C#, Common Lisp, Dart, Scheme, Raket.
And all of that list also have AOT compilers, and JIT cache tooling.
If this catches on, and more tools get the "chatgpt, translate this into rust, make it go brrr" treatment, hopefully someone puts in the time & money to take tauri that extra 10-20% left to make it an universal electron replacement. Tauri is great, but still has some pain points here and there.
What could it be that drives the ROI ?
Seems like confirmation bias.