NCoC
byteorder
Our great sponsors
NCoC | byteorder | |
---|---|---|
6 | 5 | |
1,622 | 921 | |
- | - | |
0.0 | 5.7 | |
almost 3 years ago | about 1 month ago | |
Rust | ||
The Unlicense | The Unlicense |
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.
NCoC
-
An newbie programmer makes an annoying "bump" comment on his bad PR...and tags the 350,000 people who follow the repo. If you have access to the Unreal 4 source code, you may want to unsubscribe from this PR asap.
It's the same with the NCoC. We are not all adults unless we're forced to be.
- Rust Moderation Team Resigns
-
What's with all these 'Code of Conduct' documents?
The only Code of Conduct that I support.
The only good CoC is the NCoC, presented here in its entirety:
byteorder
-
Fedora to disallow CC0-licensed code
Ditto, I guess? :P (But obviously with the position on the Unlicense flipped.)
To address your indictment head-on: you suggesting the 0BSD as a better alternative is really missing my point. The 0BSD is not an alternative for my use case. The Unlicense is one of the very few overt "political" acts that I inject into the software I produce. Its purpose is to make a statement. The 0BSD doesn't do that IMO, so it's not actually an alternative that meets my advocacy goal.
You and Rick Moen seem to have the same apparent blind spot for this. See my conversation with him that started here (which might also clarify some aspects of my own position): https://github.com/docopt/docopt.rs/issues/1#issuecomment-42...
And finally, note that my dual licensing scheme is exactly a response to the "problems pointed out by quite a few people": https://github.com/BurntSushi/byteorder/issues/26
- Rust Moderation Team Resigns
-
Why does rust change the byteorder of integer types if I print them as hex
Of course in C you can get a pointer to the value and iterate over the raw bytes in memory to print them one at a time, but that's above and beyond just using %x. The easiest way to do this in Rust that I can think of is by using the byteorder crate.
What are some alternatives?
serde - Serialization framework for Rust
team - Rust teams structure
xgb - The X Go Binding is a low-level API to communicate with the X server. It is modeled on XCB and supports many X extensions.
wingo - A fully-featured window manager written in Go.
regex - An implementation of regular expressions for Rust. This implementation uses finite automata and guarantees linear time matching on all inputs.
bitvec - A crate for managing memory bit by bit
ripgrep - ripgrep recursively searches directories for a regex pattern while respecting your gitignore
html5ever - High-performance browser-grade HTML5 parser
r-source - Read-only mirror of R source code from https://svn.r-project.org/R/, updated hourly. See the build instructions on the wiki page.