depot
librunecoral
| depot | librunecoral | |
|---|---|---|
| 1 | 1 | |
| 0 | 5 | |
| - | - | |
| 10.0 | 10.0 | |
| about 1 year ago | almost 2 years ago | |
| Nix | Rust | |
| - | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
depot
-
Scaling Rust Builds with Bazel
hmm. this migration would have been possible with staying with nix and developing a rules_rust equivalent (maybe it already exists) - see https://github.com/ghuntley/depot/tree/trunk/nix/buildGo for example but for golang. provides a simple dsl over nix and hides nix.
librunecoral
-
Scaling Rust Builds with Bazel
> "yeah this was written for a Google project, that other use case didn't apply to our project"
Not only is that a very narrow set of use cases (Read: they only deploy statically linked binaries on mostly unix-y environments), Even the fixes for those very basic use cases take for ever.
Eg. This 7 year old issue is still open: https://github.com/bazelbuild/bazel/issues/1920 . To be able to create a statically linked library, we had to use: https://github.com/hotg-ai/librunecoral/blob/master/runecora... . Had to use some weird hack to build shared libraries too. Overall, it was just annoying.
What are some alternatives?
opentelemetry-cpp - The OpenTelemetry C++ Client
bazel-example-rust - An example repository demonstrating Bazel rust_binary and rust_library build targets.
bazel - Correct, reproducible, and fast builds for everyone.
bazel-ex-20230324
rules_jvm - Contributed Bazel rules that make working with java projects more pleasant
envoy - Cloud-native high-performance edge/middle/service proxy
buck2 - Build system, successor to Buck