rfc-leadership-council
hashes
| rfc-leadership-council | hashes | |
|---|---|---|
| 2 | 4 | |
| 6 | 1,686 | |
| - | 2.7% | |
| 2.7 | 8.2 | |
| 12 months ago | 5 days ago | |
| Markdown | Rust | |
| Apache License 2.0 | - |
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.
rfc-leadership-council
-
Rust has been forked to the Crab Language
This fork promises "All of the memory-safe features you love, now with 100% less bureaucracy!" Compelling, until you realise that all the commits are auto-merges of rust-lang/rust's main branch. Which means the same teams doing the same work, under a different name.
Rust is experiencing growing pains because they're still figuring out a governance structure that works for everyone. They want to simultaneously keep the current structure of bottom up development where each team (compiler, lang, crates.io, cargo) has the autonomy to make decisions for themselves, but the project as a whole can speak can come to a consensus and speak with a single voice. That's what this RFC tries to capture (https://github.com/rust-lang/rfc-leadership-council/blob/mai...). But the project isn't there yet, and is making these frustrating missteps in the interim. The lack of transparency into these missteps manifests as "bureaucracy" to outsiders like us.
If Crab lang actually attracted people doing the real work of development, they would have the exact same "bureaucracy" as teams tried to figure out how to build consensus and speak with one voice. The fact that they don't have bureaucracy is a direct consequence of them not doing any work right now. None of the people involved in regular Rust work, as far as I can tell, so they might not be aware of this.
Lastly, I want to note that the top comment in this thread is blaming the Foundation, which is simply bizarre. The Foundation very explicitly tries to stay hands off on technical decisions and does not interfere in how the teams organise themselves. You may disagree with that, but it's an inaccurate characterisation.
-
Hey Rustaceans! Got a question? Ask here (15/2023)!
Read eg. https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md as start
hashes
-
Hey Rustaceans! Got a question? Ask here (15/2023)!
If found this set of crates for other algorithms : https://github.com/RustCrypto/hashes And also found this set of crates that seem to include a lot of block cyphers : https://github.com/RustCrypto/block-ciphers Even if "des" is listed as a crate in this last link, it doesn't seem to provide the DES algorithm entirely.
- What's the crate for sha256 HMAC?
-
Hey Rustaceans! Got an easy question? Ask here (8/2021)!
Then you should note that here where they're in the process of rewriting the crate (and have already removed the unsafe block you pointed out): https://github.com/RustCrypto/hashes/pull/228
What are some alternatives?
crab - A community fork of a language named after a plant fungus. All of the memory-safe features you love, now with 100% less bureaucracy!
OpenHashTab - 📝 File hashing and checking shell extension
mimalloc_rust - A Rust wrapper over Microsoft's MiMalloc memory allocator
multi-party-ecdsa - Rust implementation of {t,n}-threshold ECDSA (elliptic curve digital signature algorithm).
rumqtt - The MQTT ecosystem in rust
rust - Empowering everyone to build reliable and efficient software.
rust-playground - The Rust Playground
codemap - A data structure for tracking source code positions, inspired by the type in rustc's libsyntax.
crates.io - The Rust package registry
hash - 🚀 The open-source, self-building database. From @hashintel
api-guidelines - Rust API guidelines
block-ciphers - Collection of block cipher algorithms written in pure Rust