Our great sponsors
-
Cranelift is not used for debug builds by default. I think that's probably a goal (although I'm not actually 100% sure about that just because I'm not dialed into what the compiler team is doing). Even the OP mentions this:
> We were able to benchmark bjorn3's cranelift codegen backend on full crates as well as on the build dependencies specifically (since they're also built for cargo check builds, and are always built without optimizations): there were no issues, and it performed impressively. It's well on its way to becoming a viable alternative to the LLVM backend for debug builds.
And the Cranelift codegen backend itself is also clear about it not being ready yet: https://github.com/bjorn3/rustc_codegen_cranelift
(To be clear, I am super excited about using Cranelift for debug builds. I just want to clarify that it isn't actually used by default yet.)
-
`cargo build -j11` will limit parallelism to eleven cores. Cargo and rustc use the Make "jobserver" protocol to coordinate their use of threads and cores, even when multiple rustc processes are running (as long as they are part of the same `cargo` or `make` invocation):
-
InfluxDB
Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.
-
ripgrep
ripgrep recursively searches directories for a regex pattern while respecting your gitignore
I originally posted this on reddit[1], but figured I'd share this here. I checked out ripgrep 0.8.0 and compiled it with both Rust 1.20 (from ~5.5 years ago) and Rust 1.67 (just released):
$ git clone https://github.com/BurntSushi/ripgrep -
I've started liking evcxr (https://github.com/google/evcxr) for REPL. It's a little slow compared to other REPLs, but still good enough to be usable after initial load.
-
For the branch-switching usecase you might get some milage out of sccache [1]. For local storage it's just one binary and two lines of configuration to have a cache around rustc, so it's worth testing out.
-
> you could try to make OpenSSL memory safe by rewriting it in Rust
Or just write a better crypto stack without the many legacy constraints holding OpenSSL back. Rustls (https://github.com/rustls/rustls) does that. It has also been audited and found to be excellent - report (https://github.com/rustls/rustls/blob/main/audit/TLS-01-repo...).
You're suggesting writing this stack in a GC language. That's possible, except most people looking for an OpenSSL solution probably won't be willing to take the hit of slower run time perf and possible GC pauses (even if these might be small in practice). Also, these are hypothetical for now. Rustls exists today.
