> And don’t tell me about Bytes crate—it should not be a separate crate I'd be interested to hear the author's reasoning behind this, if it does what they want then why not use it? It's small and well written, so I don't think vetting it should be a problem. The rest of the article seems quite sensible, that comment just strikes me as a little odd.
Rust: Not So Great For Codec Implementing
101–110 of 283 posts
Re: Rust: Not So Great For Codec Implementing
#102Earlier quoted context omitted.
A little copying is better than a little dependency. https://go-proverbs.github.io/ As a developer at a large software company, every dependency that is not part of the language runtime itself is a pain because legal paperwork and evaluation has to be done for each individual component before I can use it / ship it. NOTE: I am not referring to copying I would be doing, but to the crates thats have little dependencies…
> A little copying is better than a little dependency. https://go-proverbs.github.io/ I really disagree with that quote. Copying is how you get bugs sticking around in software for all time (for example, doing binary searches in a way that avoids overflow is surprisingly tricky, and the endless copying of naive binary search code is why this bug is so difficult to eradicate). Honestly, that quote is just an excuse to…
Re: Rust: Not So Great For Codec Implementing
#103Earlier quoted context omitted.
A little copying is better than a little dependency. https://go-proverbs.github.io/ As a developer at a large software company, every dependency that is not part of the language runtime itself is a pain because legal paperwork and evaluation has to be done for each individual component before I can use it / ship it. NOTE: I am not referring to copying I would be doing, but to the crates thats have little dependencies…
"Dependency" doesn't imply "third-party library." There are plenty of crates that are maintained by the Rust organization itself. You could think of them as a "non-standard library." (This isn't uncommon; it's also true in, say, Elixir: there are a few useful Hex packages owned by the elixir-lang GitHub org itself. And I believe it's true in Haskell as well.)
Re: Rust: Not So Great For Codec Implementing
#104Earlier quoted context omitted.
Is it hard to implement such primitives for distinguishing ownership of subsections of an array? Or to extend Rust to do do that?
It's pretty easy to do it in unsafe code, or to use an existing safe function (implemented internally with unsafe code) like the standard library function split_at_mut to do it. Here's a doc on how to write such a function yourself, and includes the (actual) source code for split_at_mut: https://doc.rust-lang.org/nomicon/borrow-splitting.html As others have mentioned, there's nothing special about the standard librar…
Re: Rust: Not So Great For Codec Implementing
#105Earlier quoted context omitted.
Nice to see IPFS links popping up
I agree! Are you running a local node? I was thinking that a browser extension that automatically redirected URLs like ".*/ip[fn]s/\w+" to the local daemon address would be pretty useful.
Re: Rust: Not So Great For Codec Implementing
#106Earlier quoted context omitted.
I believe they mean, each time a source code is downloaded and used that contains a LICENSE file, a legal review must occur. So if it's bundled into one licensed work "Rust With Lots Of Crates Bundled", then that's one form to fill out, but if it's "Rust" and then "Download And Use Crates", that's one form per addon to fill out.
But you're bound by the license even if you copy and paste the code into your project instead of using Cargo.
Employees take shortcuts around bureaucracy all the time. Sometimes (often?) that bureaucracy is for legal reasons.
Re: Rust: Not So Great For Codec Implementing
#107Earlier quoted context omitted.
How is copying better than dependencies in this regard? You presumably need legal signoff either way. I wasn't referring to copying that I would do myself, but copying that other crates would do. That is, if a crate only needs a little bit from a little dependency, then copying it into their crate can make everyone else's life easier (obviously taking licensing into consideration when doing so). In short, the context…
> so that I don't have to worry about it. What would you be worrying about?
A component that instead references its dependencies and that have their own release schedule/versions, etc. requires a legal review for that component and each of its dependencies.
This has been true at multiple employers I've worked for, so seems unlikely to be a consideration unique to my current employer.
Re: Rust: Not So Great For Codec Implementing
#108Earlier quoted context omitted.
Nice to see IPFS links popping up
I agree! Are you running a local node? I was thinking that a browser extension that automatically redirected URLs like ".*/ip[fn]s/\w+" to the local daemon address would be pretty useful.
https://chrome.google.com/webstore/detail/ipfs-station/kckhg...
Re: Rust: Not So Great For Codec Implementing
#109Earlier quoted context omitted.
> A little copying is better than a little dependency. https://go-proverbs.github.io/ I really disagree with that quote. Copying is how you get bugs sticking around in software for all time (for example, doing binary searches in a way that avoids overflow is surprisingly tricky, and the endless copying of naive binary search code is why this bug is so difficult to eradicate). Honestly, that quote is just an excuse to…
I believe they mean, each time a source code is downloaded and used that contains a LICENSE file, a legal review must occur. So if it's bundled into one licensed work "Rust With Lots Of Crates Bundled", then that's one form to fill out, but if it's "Rust" and then "Download And Use Crates", that's one form per addon to fill out.
Re: Rust: Not So Great For Codec Implementing
#110Earlier quoted context omitted.
> so that I don't have to worry about it. What would you be worrying about?
The short version is that a component distributed with an embedded copy of its dependencies means a single legal review since it's a snapshot in time of a particular version of that component and its dependencies. A component that instead references its dependencies and that have their own release schedule/versions, etc. requires a legal review for that component and each of its dependencies. This has been true at mu…