I've moved from Rust to Go for most things because in the era of agents, being able to iterate quickly on a project is a huge advantage and Rust is way, way slower than Go for compilation. There are times when Rust is more appropriate, but for the vast majority of things Go is perfectly fine.
I nearly did this, but then I swapped to writing native desktop apps and egui - Rust is still worth it.
I've stopped using Tauri and gone with 100% egui. It's cross platform and excellent, and if you give it design constraints it will look beautiful.
Check out my 100% adobe clean room reimplementations:
<a href="https://github.com/storytold/drawcraft" rel="nofollow">https://github.com/storytold/drawcraft (going to rename this vectorcraft)
The #1 thing for the Rust project to do is make Rust faster to compile.
Rust is the agentic AI language. It just needs to lean in and go faster.
Rust doesn't let you write an impl a trait that wasn't declared in your crate for a type that wasn't declared in your crate. At least one of the two needs to be locally declared. This makes splitting projects into multiple crates harder than it could be, but on the other hand it makes the crates ecosystem less brittle than it otherwise would be.
Some people propose relaxing this rule for "workspaces" (local projects with multiple crates that are not published individually). I haven't researched whether that would be technically feasible.
If you built two impls, your compiler wouldn't know which to pick. Or to phrase it differently, if you wanted to be able to choose the right one, it wouldn't be 'orphan impls', it would be 'orphan impls plus some selection mechanism'. E.g. Scala implicits. And once you have Scala implicits, non-orphan impls probably start looking like a pretty sweet alternative!
btw. That could actually make it slower to compile. The compiler uses the orphan rule to short circuit some checks IIRC.
Nevertheless, people in the project are trying to figuring out a way to relax the rule while still maintaining coherence, so this might happen some day.
there are good reasons, obviously, but it's my #1 PITA, #2 is comptime type introspection (it looks like @yara-blue is making some progress, so fingers crossed)
Very cool projects! I agree, desktop apps are one of the areas that Rust beats Go. It's too bad though, since I feel anything with a heavy GUI like this can benefit from a rapid iteration cycle which is painful with Rust.
It is right there in the 5 GL language, unless you want to convince us that all your PR come with the corresponding Assembly that the compiler generated, while doing all the compiler passes with PhD level knowledge from everyone that has worked in LLVM since 2003.
Checked out your GitHub profile. This is an insane amount of LLM usage. You created 7 full-blown apps, and each of them is very recent. The earliest commit was only 2 days ago.
I'm normally against fully vibe-coded apps, but at this point, I'm just impressed.
Be impressed when professionals actually test them and find them competitive. Maybe these apps are good, maybe they aren't, absent real data just being vibe-coded doesn't imply quality and a claim like "I one-shotted Photoshop" should cause alarm even if you're all in on GenAI.
At some point we have to move on from amazement at what these models can do to actually caring about the quality of the product.
I don't really understand why Rust seems to be the go-to language for llms. Yes sure it has a good type system, but in practice llms seem to trip over it as much as I do, and given how fast llms are at writing code, that just makes compile times a much larger bottleneck.
Rust is built on the idea that code that compile must be correct, to the best of its abilities. LLMs are fast and sloppy, Rust keeps them in check by not letting them get away with preventable bugs.
Of course, Rust can't do anything for spec bugs, like making the stop light green when it should be red, but it can help with crashes and vulnerabilities.
Another thing I might add is that Rust is a relatively popular language, with a culture of writing high quality code. Many people, starting by those of Mozilla chose Rust to write security-critical, efficient software. They wouldn't chose it for throwaway, low skill, non-critical code, as there are languages that are more appropriate for this.
The result is a large amount of high quality code a LLM can train on. Compare to Zig for instance, which is a fine language, but not as popular so lacking in volume for good training. You then can understand why Anthropic ported Bun from Zig to Rust if they intend to vibe code. Languages like PHP, while actually quite decent today, have a long history of terrible code, so not great for a LLM as most of its training dataset is poisoned.
The unfortunate part is that it may not last. If Rust becomes the de-facto language for LLM production, overall quality may decrease. It is a common problem with many machine learning techniques including LLMs: feeding them their own output tend to decrease quality.
Go is full of footguns and LLMs still cannot be trusted to follow the rules they themselves conjured up out of thin air. Unlike humans, they don't need to be taught the language (which is the hardest part of using Rust, by far), so they get more benefits out of it than many humans do.
LLMs do trip up when they generate Rust code, but they also do when generating any other language. The big difference is that the Rust compiler refuses to compile broken code faster, whereas Go will just let you SIGSEGV on edge cases without warning.
The recent TLA+ hype here on HN shows that Rust may just be the beginning here. There are valid, safe Rust programs that will crash, the language isn't perfect. The older languages with more math and validation behind them (Ada?) are probably even better suited for generated code, but they don't have the hype culture to capture mainstream attention (and even fewer people have the ability to really review that code).
There's an alternative solution of course: use platforms like JS/.NET/JVMs/Python to run code that cannot violently crash because of the language runtime around it. That comes with a performance overhead but it's good for prototyping without as many stability footguns and with faster compilations.
> because in the era of agents, being able to iterate quickly on a project is a huge advantage and Rust is way, way slower than Go for compilation.
Incremental changes in a normal project shouldn’t cause massive compile times. Even for my large projects, the compile times are trivial compared to the duration of an LLM turn.
Very large projects should be broken into logical modules so only the changed part is incrementally compiled. If linking is taking a long time there are alternate linkers that can be used.
If you’re using work trees a lot, set up compiler caching to avoid rebuilding everything from zero on every new work tree is important.
I know these things are frustrating to new Rust users who just want everything to be automatic and easy, but if we’re talking about LLM development anyway then these optimizations would have come up the first time you asked your LLM what could be done about improving compile times. LLMs are very good at setting up these optimizations.
What kind of work are you doing where the LLM turns are only taking "seconds" and it's recompiling all the time?
This morning so far my LLM rounds have taken between 10-15 minutes. An incremental compile happens a couple times at most.
Even on the largest Rust codebases I've been working with (OSS projects), incremental compiles are not taking multiple minutes unless I do something that triggers a full recompile.
slowin · · focus · HN ↗
echelon · · focus · HN ↗
I've stopped using Tauri and gone with 100% egui. It's cross platform and excellent, and if you give it design constraints it will look beautiful.
Check out my 100% adobe clean room reimplementations:
<a href="https://github.com/storytold/filmcraft" rel="nofollow">https://github.com/storytold/filmcraft
<a href="https://github.com/storytold/photocraft" rel="nofollow">https://github.com/storytold/photocraft
<a href="https://github.com/storytold/drawcraft" rel="nofollow">https://github.com/storytold/drawcraft (going to rename this vectorcraft)
The #1 thing for the Rust project to do is make Rust faster to compile.
Rust is the agentic AI language. It just needs to lean in and go faster.
tcfhgj · · focus · HN ↗
#0 get rid of the orphan rule
Quitschquat · · focus · HN ↗
estebank · · focus · HN ↗
Some people propose relaxing this rule for "workspaces" (local projects with multiple crates that are not published individually). I haven't researched whether that would be technically feasible.
echelon · · focus · HN ↗
Workspaces are a great way to architect larger projects and monorepos, and they'd at least be internally consistent.
mrkeen · · focus · HN ↗
panstromek · · focus · HN ↗
Nevertheless, people in the project are trying to figuring out a way to relax the rule while still maintaining coherence, so this might happen some day.
cztomsik · · focus · HN ↗
BTW: cheers, we should grab a beer some day :)
panstromek · · focus · HN ↗
the_sleaze_ · · focus · HN ↗
slowin · · focus · HN ↗
xutopia · · focus · HN ↗
jlahijani · · focus · HN ↗
mixmastamyk · · focus · HN ↗
Also it says egui is immediate mode, does that use a lot of {C,G}PU or have any other issues?
nonethewiser · · focus · HN ↗
echelon · · focus · HN ↗
Going to do Toon Boom and a few others too and build them as a suite.
pjmlp · · focus · HN ↗
echelon · · focus · HN ↗
pjmlp · · focus · HN ↗
shirol · · focus · HN ↗
I'm normally against fully vibe-coded apps, but at this point, I'm just impressed.
krapp · · focus · HN ↗
At some point we have to move on from amazement at what these models can do to actually caring about the quality of the product.
[deleted] · · focus · HN ↗
[deleted]
Bolwin · · focus · HN ↗
GuB-42 · · focus · HN ↗
Rust is built on the idea that code that compile must be correct, to the best of its abilities. LLMs are fast and sloppy, Rust keeps them in check by not letting them get away with preventable bugs.
Of course, Rust can't do anything for spec bugs, like making the stop light green when it should be red, but it can help with crashes and vulnerabilities.
wannabe44 · · focus · HN ↗
[dead]
GuB-42 · · focus · HN ↗
The result is a large amount of high quality code a LLM can train on. Compare to Zig for instance, which is a fine language, but not as popular so lacking in volume for good training. You then can understand why Anthropic ported Bun from Zig to Rust if they intend to vibe code. Languages like PHP, while actually quite decent today, have a long history of terrible code, so not great for a LLM as most of its training dataset is poisoned.
The unfortunate part is that it may not last. If Rust becomes the de-facto language for LLM production, overall quality may decrease. It is a common problem with many machine learning techniques including LLMs: feeding them their own output tend to decrease quality.
jeroenhd · · focus · HN ↗
LLMs do trip up when they generate Rust code, but they also do when generating any other language. The big difference is that the Rust compiler refuses to compile broken code faster, whereas Go will just let you SIGSEGV on edge cases without warning.
The recent TLA+ hype here on HN shows that Rust may just be the beginning here. There are valid, safe Rust programs that will crash, the language isn't perfect. The older languages with more math and validation behind them (Ada?) are probably even better suited for generated code, but they don't have the hype culture to capture mainstream attention (and even fewer people have the ability to really review that code).
There's an alternative solution of course: use platforms like JS/.NET/JVMs/Python to run code that cannot violently crash because of the language runtime around it. That comes with a performance overhead but it's good for prototyping without as many stability footguns and with faster compilations.
mkesper · · focus · HN ↗
dmead · · focus · HN ↗
Aurornis · · focus · HN ↗
Incremental changes in a normal project shouldn’t cause massive compile times. Even for my large projects, the compile times are trivial compared to the duration of an LLM turn.
Very large projects should be broken into logical modules so only the changed part is incrementally compiled. If linking is taking a long time there are alternate linkers that can be used.
If you’re using work trees a lot, set up compiler caching to avoid rebuilding everything from zero on every new work tree is important.
I know these things are frustrating to new Rust users who just want everything to be automatic and easy, but if we’re talking about LLM development anyway then these optimizations would have come up the first time you asked your LLM what could be done about improving compile times. LLMs are very good at setting up these optimizations.
asutekku · · focus · HN ↗
Aurornis · · focus · HN ↗
What kind of work are you doing where the LLM turns are only taking "seconds" and it's recompiling all the time?
This morning so far my LLM rounds have taken between 10-15 minutes. An incremental compile happens a couple times at most.
Even on the largest Rust codebases I've been working with (OSS projects), incremental compiles are not taking multiple minutes unless I do something that triggers a full recompile.