semver-trick
rust-base64
semver-trick | rust-base64 | |
---|---|---|
15 | 9 | |
414 | 575 | |
- | - | |
2.8 | 7.3 | |
25 days ago | 5 days ago | |
Rust | Rust | |
Apache License 2.0 | 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.
semver-trick
-
Making Rust supply chain attacks harder with Cackle
Let's say crate B depends on crate A with a pinned dependency, and uses one of its types in a public interface.
Crate C depends on them both. It now can't bring in updates to A until B does, and when B updates that's a breaking change, so it better bump its major version.
Take a look at this teick, for example, for foundational crates updating their major version: https://github.com/dtolnay/semver-trick
Now imagine that being an issue every single patxh update.
-
The module system is too confusing
Rust modules require a tiny bit more definition up-front, but they neatly decouple the module hierarchy from file layout so you can reorganize code however you like in future, and they support very fine grained control of privacy (such as being able to say pub(super) and pub(crate)). In extreme cases, you can even re-export symbols from one module in another without it counting as a breaking change, so you have even more options for evolving your project without breaking existing consumers. Look at the the semver trick as an example of how powerful this can be and how much freedom it gives library implementors. (And even if you're only a library consumer, wouldn't you rather be consuming libraries by implementors that had more freedom and power?)
-
My first year with Rust: The good, the bad, the ugly
A library author concerned about this can use the semver trick. TL;DR: if your current version is 0.42, you can do a 1.0 release, then do a 0.43 release that depends upon your 1.0 release and re-exports all the symbols.
-
Does Rust have any design mistakes?
I mean for all the parts of the standard library that do not change, one could presumably use the semver-trick.
-
Rust is hard, or: The misery of mainstream programming
The semver trick can help with libraries at least when they go to unify the ecosystem. Release new versions that replicate previous APIs in a compatible way while moving to the standard library implementation.
-
Roadmap
Because you still run into the problem that's been seen when various important crates upgraded and either didn't use the semver trick or had downstream crates specifying Cargo.toml version requirements too narrowly for it to be effective.
- The Rust SemVer Trick (2019)
-
This Year in Embedded Rust: 2021 edition
It's called the "semver-trick" [1].
[1]: https://github.com/dtolnay/semver-trick
- The Semver Trick
-
The chip shortage keeps getting worse. Why can't we just make more?
The JVM is 114MiB on my machine. A near-minimal ggez program in debug mode is about 100MiB,¹ and ggez is small for a Rust application library. When you start getting into the 300s of dependencies (i.e. every time I've ever got beyond a trivial desktop application), you're lucky if your release build is less than 100MiB.
Sure, I could probably halve that by forking every dependency so they aren't duplicating versions, but that's a lot of work. (It's a shame Rust doesn't let you do conditional compilation based on dependency versions, or this would be a lot easier. As it is, we have to resort to the Semver trick: https://github.com/dtolnay/semver-trick/ — not that many people do that, so it's functionally useless.)
¹: I can get it down to around 8MiB with release mode, lto etc., but that significantly increases the build time and only about halves the weight of the intermediate build files.
rust-base64
- Rust is not the language for you if you don't like traits
-
Base64 Implementation in Rust
It would be interesting to compare your implementation and the most popular implementation for Rust+base64: https://github.com/marshallpierce/rust-base64
- Rust-base64: restore {encode, decode} convenience functions
-
Question in Rust about Base64 encoding for xmlrpc
I am writing a CLI util in rust that utilizes xml-rpc-rs to talk to an rtorrent server and I would like to be able to add torrent files. OK according to the python implementation, which some of the rtorrent developers have said is good, of xmlrpc-client it uses this base64 format: https://datatracker.ietf.org/doc/html/rfc2045.html#section-6.8 I base64 encode /some/file/foo.torrent and send it up. OK!
-
Announcing uuid-simd, hex-simd and base64-simd!
Funny that you claim base64 forbids unsafe code while linking a PR where the current maintainer of the crate explicitly agrees that unsafe for the purpose of SIMD-acceleration is a-okay. Did you by any chance meant to link https://github.com/marshallpierce/rust-base64/pull/114 instead? ;)
-
Fast Rust Builds
> It does need to be in the standard library
When I say that something “has to be in the standard library”, I mean that it can’t be implemented outside the standard library. That’s certainly not the case here. You’re using an outright bad definition of “need” here—subjective opinion rather than objective requirement.
> because everyone needs it
This is factually wildly wrong. I wrote a fair bit more here but decided it wasn’t helpful. Précis: web stuff tends to load it indirectly (though amusingly most of the time actually not use it, so that Base64 code won’t actually end up in your binary), but it’s not terribly common outside of internet stuff to reach for Base64.
I’ll leave just one more remark about Base64: once things are in the standard library, breaking changes can no longer be made; the base64 crate is still experiencing breaking changes (<https://github.com/marshallpierce/rust-base64/blob/master/RE...>, 0.12 and 0.13 were last year and 0.20 is not released), largely for performance reasons.
Please don’t just call the thin-std approach “problematic” without acknowledging that the alternative is at least as problematic, just with a different set of caveats.
-
Stable versions of most important community crates
Many of these have their own tracking issues on the path to v1.0. For example see this one for base64.
-
Debian discusses vendoring again
I see base64. If the standard library has base64 encoding, go ahead and use it. But as a third-party dependency? Again, base64 encoding and decoding is trivial. I've written this a few times myself. It's not worth a dependency.
What are some alternatives?
lang-team - Home of the Rust lang team
unicode-xid
cargo-llvm-lines - Count lines of LLVM IR per generic function
itoa - Fast integer to ascii / integer to string conversion
Thruster - A fast, middleware based, web framework written in Rust
portable-simd - The testing ground for the future of portable SIMD in Rust
rust-quiz - Medium to hard Rust questions with explanations
ulid-rs - This is a Rust implementation of the ulid project
serde - Serialization framework for Rust
getopt - POSIX getopt() as a portable header library
driver-examples - Rust example programs for many of my hardware device drivers running on STM32F3 Discovery, STM32F103 "Blue Pill", RaspberryPi and micro:bit boards
abseil-cpp - Abseil Common Libraries (C++)