This sort of thing is why packages should always be namespaced. Just "base64" without any additional qualifiers makes it seem more official and definitive than it actually is.
I don’t like this crate either, it’s frustrating to use… but you don’t win any prizes for having a go at open source maintainers.<p>Create an alternative crate if you care enough, or pick a different crate to use. You can even literally pin to a previous version of this crate.<p>I have zero sympathy for folk coming along to a closed issue, which has been clearly closed and explained and trying to tell the maintainer they know better.
I don't see the problem here at all. What prevents somebody from writing a 5 line helper wrapper that provides the easier API either in their project or as a small crate if they want to share the helper between projects?<p>That's the benefit of having a more explicit API. Doing it the other way and making a generic API on top of a simplified one is harder.
UI/API rule number one: the thing you do most frequently should be the easiest thing to do.<p>There’s a reason that words like “the” and “it” are not 60 characters long in any spoken language.<p>If you’re making it super verbose to do very common tasks, you’re fucking up your interface.
I actually like this design choice. Having dealt with these kind of bugs, only to have to switch to the URL-safe base64 encoding, makes me really appreciate it.<p>It forces the developer to consider which configuration they want, and in that, actually realize that there is a difference between URL-safe and the standard version.
That was a breaking change, and was a medium-sized headache, in that it broke some crates. As an original design decision it would not have been too bad, but as a breaking change, it was.
I don't disagree with the idea that a relatively complicated base64 API seems painful but...<p>> Normally I agree with explicit being better than implicit, but I don't see the harm here. If there's no specific interoperability requirements, explicitly choosing a configuration isn't particularly important.<p>Pretty much the entire point of base64 is interop, so there would <i>always</i> be specific interop requirements.<p>And since a base64 library tends to be reflexive, a library's default tends to either "way too strict to consume any base64 you can find in the wild" or "so loose you can get a carrier strike group through" e.g. Ruby and Python will strip out any invalid character from the input before attempting a parse, python requires padding to be present but I'm not sure there's any way to make ruby's decode64 fail as long as you give it a string since it does not.
It does seem unfortunate that what's apparently (given its name) the 'default' base64 crate for Rust can't expose a simpler interface. Most people don't need optimally efficient base64 encoding. It should suffice to expose 'encode' and 'decode' functions that take some parameters configuring the encoding. That's not to say that the more complex design of this library is necessarily bad, just that it seems to be motivated by goals that won't be relevant to most people who just want to encode a smallish blob.<p>Maybe this illustrates why it's good to have base64 in a language's stdlib. That way 90% of people can just use a couple of simple functions, while libraries like this can still exist for those who really need them.
> This has already been discussed extensively elsewhere. I am not sympathetic to concerns over useing a trait. Rust is not the language for you if you don't like traits. Feel free to collect a full refund on your way out.<p>Without weighing in on the merits of the comment, the delivery feels very Poettering-esque.
I really wish people would drop the "explicit is better than implicit" mantra.<p>What "explicit" means vague. Does it mean you want the code to be verbose? Noisy? Because that's silly, and Rust doesn't even have a history of doing that. We went from try! to ?, we went from impl Future to async/await. I'd rather people talk about what they really mean than just repeating that line over and over again.<p>edit: also it's really weird the OP seems to keep wanting to post this thread. If you don't like their library, fork your own?