Smaller target directory size would be such a lifesaver. Hoping the best for you, and Rust!
This!<p>There's a recurring meme here and in other social media about rust being slow to compile, but anyone who's worked with Rust know that target dirs are a much more annoying papercut in practice than the relative speed of the compiler (which isn't appreciably worse than any other toolchain out there for the most common workflows).
It would help, yes. Here's one of my projects, that uses different subdirectories in target/ based on compiler options pre-commit runs:<p><pre><code> $ du -hcs target/
190G target/</code></pre>
<i>> It's easy to understate how big of a deal this is for the compiler. This work resolves a major piece of technical debt that a lot of compiler developers dreamed about for years.</i><p>No kidding. I’ve been waiting for the solver at least half that decade now. Hopefully it and Polonius unblock specialization which has been in purgatory for years.
Pretty wild to see how different people’s experiences can be within the same industry but under different applications and circumstances, here is someone joyful about the future of a language whereas not long ago we had a Ruby gem maintainer in deep dissatisfaction and frustration with the future of it.<p>Not implying to compare Rust and Ruby, just mainly observing how these two things came out near each other in the present day.
The best way to get a rust job is get a regular job and just write rust
Rust is not very relevant anymore when you can write it in C and once in a while run an LLM over it to catch any memory issues...
I don't understandy why, but all submissions of this post so far had incorrect title. When I posted the correct one, it still got reassigned the wrong title and I had to edit it (and it didn't allow me to do that yesterday, only today).
[flagged]