Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
oil
Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
-
compiler-benchmark
Benchmarks compilation speeds of different combinations of languages and compilers.
Here’s one of the Eich commits in the prehistory repo (which is fun to browse):
https://github.com/graydon/rust-prehistory/commit/8952f420ae...
It caches things between builds, and if you use dev builds (the default) it doesn't take as long as production. For ergonomics you can install cargo-watch (https://crates.io/crates/cargo-watch) which helps a bit.
An important thing though, if you aren't doing this already, is to not wait for a full build to know if your types check out. You can use cargo-check if you prefer (https://doc.rust-lang.org/cargo/commands/cargo-check.html), but really I recommend using an IDE with responsive feedback if at all possible. rust-analyzer is one of the best, and should be supported even if you're on Vim or something.
Using Rust without snappy editor hints is fairly miserable because of how interactive the error feedback loop tends to be. If you don't rely on a full build for errors - just for actual testing - I find the build times to be perfectly fine (at least in the smallish projects I've done).
I think a problem is that programmers have little intuition about about the evaluation time of macros.
It's possible that Zig's approach helps here -- since the metalanguage is just the language, you can take some of your intuition about performance along to compile time. And the macro language is not weirdly restricted, so you can write something you're more used to, with similar idioms.
In the limit this is clear: I'm using several Python code generators C++ in https://www.oilshell.org, and it's easy to reason about the performance of Python. Doing the same in C++ metaprogramming would almost certainly be a lot slower. It would also give me less indication of code bloat; right now I simply count the lines of output to test whether my code generator is "reasonable".
e.g. I generate ~90K lines of code now, which is reasonable, but if I had 1M or 10M lines of code, that wouldn't be. But there's not that much of a sanity check on macros (except binary size).
> The D compiler is roughly as fast as the Go one...
Not according to this benchmark:
https://github.com/nordlow/compiler-benchmark
dmd performed around 1.5x to 4x faster than go.