Based on all the negative comments, and being a non-expert, I had an LLM generate an article for that same title. I suspect it was more approachable and more technically accurate than this. In fact I asked it to compare its article with this one and the negative comments.
The author of any technical blog post should be using an LLM to vet things before posting to find gaps or inconsistencies.
Have there been any successful attempts yet of translating 'idiomatic' C++ to 'idiomatic' Rust for a large codebase that has been developed over 30 years? What does the output look like? Does the code look maintainable (because mechanical solutions to translate from other languages into Rust exist, the result is just not what a human would write or ever want to work on). Are the prompts to guide the LLM shorter than the actual code base to be translated? Etc etc... eg the idea to use LLMs for migration is quite 'obvious', but the devil must be in the details, otherwise everybody would be doing it by now.
Models and agents have progressed significantly in the last few months. Migrating projects to rust can definitely be a thing in the coming years if there is sufficient motivation. But oftentimes c/c++ devs have aversions to the rust language itself, so the biggest challenge can be an issue of motivation in general.
Idiomatic C++ allows too much "freestyle" and duck-typed code. Rust language basically doesn't support half of the things that C++ allows because there is no type or memory safe ways to achieve them. When translating things into Rust, borrow checker forces you to invert the logic or completely redo the architecture. Oftentimes it requires trying multiple things and evaluating the performance cost, generated machine code quality and interface flexibility. It is quite difficult without an actual person to translate things.
Yeah that's why I'm very sceptical about any 'LLM will magically fix all the things' claims. The mechanical translations basically work by compiling the source language down to LLVM bitcode and then translating that back to another language, it works but is basically assembly code written in a highlevel language, it loses all 'semantics' and is entirely unmaintainable.
About 70% of the programming I'm doing right now is in my own language. But like, my full time work is programming language research so I accept that's an uncommon use-case.
It doesn’t follow that a language server written with JavaScript and run via node will bloat the binary by hundreds of MB. Are they bundling a node runtime too?
Maybe if they are embedding dozens of language servers and runtimes it could bloat the binary, but I assumed the extensions and language servers would be downloaded on demand.
But a rust binary by itself shouldn’t be that large. LSP is just a simple json protocol, so parsing it doesn’t require hundreds of MB.
When I opened a Rust project I think the status bar said it was downloading Rust support, which supports your hypothesis. (Also it doesn't make much sense to bundle these things when they are all making new releases at different schedules.)
Hey, Zed developer here. Indeed we do not bundle the LSP binaries into the final binary for the reasons you've stated; and I do agree that the binary is kind of big, though at present .dmg compression gets us a long way (as the .dmg itself is ~115Mb).
Right now we ship an universal binary, so half of that size is essentially unused:
Never learned awk or committed esoteric cli incantations to memory. Don’t get me wrong, I can get around on the cli, but sed, awk, etc just didn’t seem like a good cost/benefit investment. I’m also not a sysadmin.
Thankfully I waited long enough and LLMs can write them for me better than I ever could.
The author of any technical blog post should be using an LLM to vet things before posting to find gaps or inconsistencies.