Posted by trickypr 9 hours ago
We have discussed this briefly on last All Hands, the problem will probably be dealing with compiler errors, when they happen in builds that already emitted metadata. I believe this was the reason why it wasn't merged in the first place.
I view this as speculative execution/compilation and just throw out any errors from a crate that depended on another crate that ultimately errors out. It has the same outcome (same errors are printed in both cases) you just have a chance of having totally wasted some cpu time (that was otherwise just sitting around though).
Incremental compilation is not cleaned up. Older deps pile up and don’t get cleaned.
Run out of disk space? Oh it’s just the 200+ GB codex-rs target folder.
Forget about doing worktrees.
Rust has a lot of work to do.
Sometimes we really can have our cake and eat it too.
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:
https://github.com/storytold/filmcraft
https://github.com/storytold/photocraft
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.
#0 get rid of the orphan rule
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.
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.
Workspaces are a great way to architect larger projects and monorepos, and they'd at least be internally consistent.
Also it says egui is immediate mode, does that use a lot of {C,G}PU or have any other issues?
OpenAI also hands out free subscriptions to open source maintainers: https://developers.openai.com/community/codex-for-oss They're time limited for now, but they've been pretty generous about who gets them. Anyone who can show Rust contributions would have been able to get one before.
Or in software terms, BigCorp sponsors you to develop an open source tool fulltime. If you make the tool more useful for them while making it more complex or worse or ignoring things for others, they might fund you next year as well. If you don't develop things that help them, they might stop and send that money elsewhere and you will need to get a normal job instead and drop your tool work to part-time. Even though they aren't dictating anything, what are you incentivised to do?
The only times this actually happened are C++ and CORBA as far as I remember. Both of them were bureaucratic design by committee efforts from the start, the people doing it weren't users but implementors looking to stop competition, and it all happened before the open source era.
>I’m still writing all my own code and text, because (a) that’s paramount, and (b) the project policy requires it, but I had useful LLM analysis assistance on several of the PRs mentioned in this post.
from the article
https://forge.rust-lang.org/policies/llm-usage.html#experime...
What you suggest may thus be more or less already happening.
Rust is the best language to serialize agentic LLM output to. It's native, well constructed, low-defect due to design. It's also easy for humans to read and debug if necessary.
The biggest problem with Rust is the compile times. The cycle has to get faster. And we need to start thinking about making the artifact cache non-blocking so multiple agents can work simultaneously - that'll be a big task, but essential if we want to speed up work on one machine rather than spinning up clusters of agent sandboxes (the alternative, perhaps superior solution).
What is the performance killer?
If you want something like Rust that offers guarantees and checks and cross-checks by the boatload, it adds up. Macros, monomorphization, implicit code generation with traits and all those other things add up too. And you can't always get O(n) or O(n log n) code to implement those checks. Maybe it can be sped up and maybe there's tricks here or there, but at the Pareto frontier, a language that has more checks will be slower to compile than one that has fewer.
And that's not a bad thing or a deficit in Rust, it's just the nature of the beast.
Instead of Go, you could have reached out to complex languages with fast compilation times like D, OCaml, Haskell, Ada, Delphi, C++.
All of them have alternative implementations with fast compilation times.
D, use dmd for fast development workflows, gdc or ldc for the ultimate performance at the expense of compilation times.
OCaml, use the REPL or bytecode interpreter for fast development times, the full blow compiler for ultimate performance.
Haskell, use the REPL, GHCi for the fast development cycles, GHC for the release build.
Ada and Delphi, have had fast implementations since forever, although Ada/SPARK is indeed somehow expensive.
C++, yes it isn't a mistake. Use Live++, VS hot reload, coupled with binary libraries, or a REPL like CINT (nee ROOT), binary libraries for dependencies, incremental compilation and incremental linking for the development workflow.
The problem with Rust isn't the language itself, rather the ecosystem currently lacking such kind of options being available.
C++ game engines also don't need Bevy like tutorials, because most studios aren't compiling them from scratch, and tools like Live++ or VC++ hot reload are relatively easy to use.
but hey, just add subsecond and switch to cranelift. problem solved :)
Many studios have delivered games with little to no changes to the underlying C++ code.
[0] - https://dev.epicgames.com/documentation/unreal-engine/using-...
but when you do have to compile c++, it can be real slow. maybe not as slow as rust, but it's not in the same league as eg. go, c#, zig, etc.
ue5's hot reload is by no means perfect either - many gameplay code changes require recompiling the editor. exposing c++ properties on a blueprint? recompile. modify a constructor? recompile. changing parameters, return types, or adding/removing UFUNCTION or UPROPERTY macros? recompile. you can simply search the web to read the experiences of thousands of ue devs complaining about slow compile times and workflows. it's the same with unity btw, search "reloading domain unity".
also verse is not in unreal engine. no studio is using verse for ue games. not sure why you threw that in.
i get you love c++ and dislike rust, but you aren't really making a good case for c++ when you group it in with other languages that have fast compile times ootb, make arguments that involve not using c++ (like blueprints, lol), and rely on brittle third-party hot-reloading solutions.
I'd love something halfway. Go is maybe a bit radical in some regards, but also, with the news of the new SIMD package for Go, it has occured to me just how little I missed having things like, say, autovectorization.
(I know also that some people have tried halfway, but the big thing is figuring out how to keep a relatively simple type system that can still support a borrow checker. Even if there is some middleground, is it truly worth it? As nice as it sounds, I've been more skeptical. Go seems to exist in a very narrow space where its simplifications barely can be made to work.)
So the focus on Rust compile time is misplaced. It's not a big deal in terms of overall productivity.
Some ideas to speed up compilation by not evaluating items that are not used might pan out significantly for big crates in your dep tree (that behavior might never be stable because that would allow items with compile errors in a crate that would still let your application compile, which is against the Rust approach). The same work to do that would also allow overlapping of crate evaluation between different rustc instances called by cargo, as it would require partial evaluation of crates (to do name res only and gather the symbols needed from its deps).
Another thing is that stable rust doesn't treat macros as idempotent (because that wasn't a requirement from the start, there are crates that do dynamic IO to generate types), but if they are then incr comp can be faster by not evaluating them unnecessarily.
I know people are working on a bunch of different strategies to improve both first and incremental compile times, and I'm looking forward to the fruit of their labor.
Compile times are rarely the bottleneck for me, but that doesn't mean I won't welcome any improvements on that front.
Is that still true with modern linkers like `wild`? Seems like it can link Chromium in 1-2s.
> Another thing is that stable rust doesn't treat macros as idempotent
This seems absolutely insane to me given how pervasive macros are in Rust (I wonder how much of incremental compilation time is just repeated serde derives?). Obviously we can't just blindly treat all macros as idempotent, but an opt-in attribute on a macros that pinky-promises that it is seems like it ought to be pretty easy to implement?
Maybe somebody's looked into it and it doesn't help much? But I've heard (unverified) rumours of the opposite.
Wild improves things significantly, but it really depends on the kind of project. For some a third of the time can be linking. And not everyone configures their environment to use a different linker. Another thing that can easily improve performance is changing the global allocator, but I've seen teams that measured 10% perf improvements in their own metrics decide against going with anything other than the "default".
I fully expect that if wild delivers an effective incremental linking architecture, then rustc will be able to produce the patches directly (instead of wild having to produce patches from two versions of the object files), which would mean both that rustc is producing less LLVM bytecode and that wild gets to do what it (will) do best and make linking as fast as mechanically possible.
> This seems absolutely insane to me given how pervasive macros are in Rust
There was some work done on this front, but I haven't kept up to date on the current status of that. There was a PR showing promise https://github.com/rust-lang/rust/pull/129102 (later landed as https://github.com/rust-lang/rust/pull/145354, 10% on a specific serde-heavy crate, reports of 32% improvements in the original PR). The tracking issue doesn't have any updates https://github.com/rust-lang/rust/issues/151364, but you can try out nightly with -Zcache-proc-macros to see what the effect could be on your projects.
Part of the problem I see is that crates will have to opt-in (and we might be able to change the default over an edition boundary) to get the perf benefit, and it might require a granularity lower than "a crate" (which would complicate implementation). I haven't seen additional discussions around these design considerations (needed to stabilize), which will need to happen before people can see progress.
Sadly, Rust is, like many open source projects, a show-up-o-cracy: you need a motivated (group of?) individual(s) to deliver a feature to fruition, and if the person driving a feature is fine with using nightly for their purposes, and only needs a subset of a feature, they will drive the feature to that state (lets say 80% completion), and then the feature will linger (until someone else with enough motivation to see the other 80% through shows up). This is exacerbated because the project is unwilling to have 80% solutions on stable unless the state is very clearly not going to preclude other future work, or the path to completion is 100% visible (but if that were the case, then it would have been completed already). So we end up with situations like the Allocator APIs.
> Another thing that can easily improve performance is changing the global allocator, but I've seen teams that measured 10% perf improvements in their own metrics decide against going with anything other than the "default".
Yeah, although I think there's more of a trade-off there. Alternative allocators can add significant amounts of compile time. Whereas, modulo maturity, I think a faster linker is more of a pure win. I would imagine we will make wild the default linker at some point if development continues on the trajectory it seems to be on.
https://github.com/rust-lang/rustc_codegen_cranelift/issues/...
In unoptimized builds often the linker is the bottleneck. Rust/Cargo can parallelize most of the build, generating tons of code and debug info, but then the poor linker has to consume all of it at once. The object/exe formats were designed in ancient times, so they're hard to build incrementally or in parallel (some linkers are trying).
At least for the fully static binary part of rust, there should be some optimizations there w.r.t. compilation. Sure you're not going to interface with shared libraries well but maybe a small experimental feature for fully owned projects? Idk.
Both are kind of outside the Rust compiler's influence. Macros can be almost arbitrarily complex: you pay for what you order. Codegen is LLVM, and that's a fixed choice. You can use Cranelift to get around it, but then you pay elsewhere.
Also, generics and monomorphization regularly come up in these discussion, while common wisdom seems to be that cost for the additional static analysis over other languages like C++ is no a major contributor.
Regardless, it's nice to see performance improvements in the compiler, even if you have to cooperate to benefit from them (e.g. by keeping your macros light and use less generics).
Now, is rustc slower than e.g. clang? by how much? why?
Those are different (and complicated) questions. It really depends on what you're compiling, but I'd say rustc can be 1-5x slower (maybe more at times?).
The reasons are many and varied, but in general rust compilation is slower because the compiler is doing way more things compared to C (monomorphization, complex trait resolution + type inference, borrow checker..)
[0]: Also I'd argue that "slow" without a concrete point of reference is a meaningless term in this context.
Well, if it weren't "slow" for some definition of "slow", nobody would bother speeding it up, would they?
Zig and Go are similar on that front.
What do you mean by this?
Some tooling ideas go all the way back to when C++ vendors started adopting ideas from Smalltalk and Lisp, e.g. Energize C++ or Visual Age for C++ v4.
Or build systems like ClearMake from ClearCase, where the object files and binary libraries are shared across everyone on the cluster with the same views (ClearMake speak for what files/branches are selected).
Generics/monomorphization and how iterators work results in a lot of compiler bytecode that has to be churned through. More bytecode = longer compilation. It increases the size of the (debug) binaries, the debuginfo in general, causes performance issues with debug binaries in some situations unless you bump the optimization level, causes more IO, etc.
All three of those words can mean "just like Rust" but equally "Not at all like Rust" for different languages.
Two examples to contrast: In C++ the iterators are basically a pointer analog (in some cases they're just literally pointers) and that's a very difference "feature" but it's still definitely iterators. In Ginger Bill's Odin, the iterators are a function, possibly generic, which returns a pair, the next item and a boolean telling you whether the iterator was exhausted.
On top the borrow checker and other features are non-existent in these languages.
Most projects my fleet works on are in other languages (TS, Go, Elixir) and can comfortably handle 10+ agents working in parallel, but not rust. I had to cap the fleet to 5 workers and build a dedicated resource monitor to step in and tidy up every time the disk almost filled up
That and general progress on building is far slower, with far more time spent building and testing than any other language I use.
Ended up rebuilding in Go, the perf gains weren't worth it
There's a new project called kache https://github.com/kunobi-ninja/kache that takes this even further and handles more edge cases with worktrees, but it's newer.
If you were pulling the entire project fresh and rebuilding everything in every worktree all the time without any caching then it would be frustrating. You could have asked your agent to set up basic caching and solved most of your problem in minutes.
Rust is what you use when you want to maximize on the runtime performance. It will build software that requires significantly less memory and maximize the CPU that will save time and energy. It's a system language for writing software meant to access the hardware.
Cargo run/test/nextest/run only, check/fmt etc should be excluded.
This avoids contention/oversubscription of the CPU which makes builds up to 300% slower from what I measured.
I can't find that talk again, but it was quite interesting: the rust compiler is fast, but often times it has to perform a lot of unnecessary checks because crates contain more stuff than needed. By stripping unnecessary work, the makepad team made building pretty fast.
Splitting out a project into multiple crates reduces what needs to be recompiled during development. I tend to break out areas of my application that aren't going to change regularly so I'm only having to rebuild the main application.
In a production scenario where you're probably building your application in some CI environment, unless you cache the release build artifacts to re-use when applicable, the entire project will be rebuilt every run.