TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Rust is not the language for you if you don't like traits

83 点作者 shantnutiwari超过 1 年前

13 条评论

Anaminus超过 1 年前
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.
评论 #37767997 未加载
评论 #37768150 未加载
评论 #37767588 未加载
wokwokwok超过 1 年前
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.
评论 #37768267 未加载
评论 #37768019 未加载
评论 #37769307 未加载
评论 #37769229 未加载
jupp0r超过 1 年前
I don&#x27;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&#x27;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.
评论 #37767646 未加载
评论 #37769236 未加载
fallingfrog超过 1 年前
UI&#x2F;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.
评论 #37767344 未加载
WirelessGigabit超过 1 年前
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.
Animats超过 1 年前
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.
jrsj超过 1 年前
Apparently the author also thinks being respectful of others shouldn’t be a default
评论 #37769353 未加载
alex_lav超过 1 年前
Don&#x27;t read the rest of those github comments if you&#x27;d like to maintain respect for anyone involved.
masklinn超过 1 年前
I don&#x27;t disagree with the idea that a relatively complicated base64 API seems painful but...<p>&gt; Normally I agree with explicit being better than implicit, but I don&#x27;t see the harm here. If there&#x27;s no specific interoperability requirements, explicitly choosing a configuration isn&#x27;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&#x27;s default tends to either &quot;way too strict to consume any base64 you can find in the wild&quot; or &quot;so loose you can get a carrier strike group through&quot; 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&#x27;m not sure there&#x27;s any way to make ruby&#x27;s decode64 fail as long as you give it a string since it does not.
评论 #37767959 未加载
foldr超过 1 年前
It does seem unfortunate that what&#x27;s apparently (given its name) the &#x27;default&#x27; base64 crate for Rust can&#x27;t expose a simpler interface. Most people don&#x27;t need optimally efficient base64 encoding. It should suffice to expose &#x27;encode&#x27; and &#x27;decode&#x27; functions that take some parameters configuring the encoding. That&#x27;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&#x27;t be relevant to most people who just want to encode a smallish blob.<p>Maybe this illustrates why it&#x27;s good to have base64 in a language&#x27;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.
评论 #37768926 未加载
nazgulsenpai超过 1 年前
&gt; 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&#x27;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.
评论 #37769180 未加载
评论 #37768087 未加载
评论 #37770161 未加载
pestatije超过 1 年前
new language...same old dickheads...why are these people even contributing anything? they obviously dont care about the users
评论 #37767516 未加载
leshow超过 1 年前
I really wish people would drop the &quot;explicit is better than implicit&quot; mantra.<p>What &quot;explicit&quot; means vague. Does it mean you want the code to be verbose? Noisy? Because that&#x27;s silly, and Rust doesn&#x27;t even have a history of doing that. We went from try! to ?, we went from impl Future to async&#x2F;await. I&#x27;d rather people talk about what they really mean than just repeating that line over and over again.<p>edit: also it&#x27;s really weird the OP seems to keep wanting to post this thread. If you don&#x27;t like their library, fork your own?
评论 #37769304 未加载