Live data from Hacker News

Rust: Not So Great For Codec Implementing

codecs.multimedia.cx

101–110 of 283 posts

Re: Rust: Not So Great For Codec Implementing

#101

> 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.

I can't speak for the author of course, but probably their argument is that a systems language should be able to directly manipulate bits and bytes without outside dependencies. I don't know that I agree. A reasonable counter example is that you need library support to allocate memory in C. The argument is that it's a feature to not require C implementations to include dynamic memory allocation because not all projects allow it. My point being that what "should" be in a language usually depends on what you're using it for, and for a general purpose language keeping that very small is at least a consistent design.

Re: Rust: Not So Great For Codec Implementing

#102

Earlier 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…

I think the argument is where that line is. Maybe copy/pasting binary search code is too much, but do you need a dependency for left pad? There's a line somewhere.

Re: Rust: Not So Great For Codec Implementing

#103
post #72

Earlier 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.)

It usually does for legal review purposes, in my experience. If those things aren't part of the "standard distribution", they have to be evaluated separately. Especially if they have a different release schedule.

Re: Rust: Not So Great For Codec Implementing

#104
post #97
post #34

Earlier 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…

I meant primitives that preserve Rust's (safe) ownership model.

Re: Rust: Not So Great For Codec Implementing

#105

Earlier 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.

No, just like the idea behind it. Yeah, even a bookmarklet might be usefull. Or a single purpose site like http://isup.me

Re: Rust: Not So Great For Codec Implementing

#106

Earlier 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.

I think this is where reality meets theory. In reality, the developers are probably just taking the code as if they had written it, and the people that may know, such as immediate supervisors, don't care to point it out for the same reason the developers are stealing it, it's much easier than the alternative. The code vetting team is just left in the dark.

Employees take shortcuts around bureaucracy all the time. Sometimes (often?) that bureaucracy is for legal reasons.

Re: Rust: Not So Great For Codec Implementing

#107

Earlier 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?

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 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

#108

Earlier 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.

Check out ipfs station if you use chrome.

https://chrome.google.com/webstore/detail/ipfs-station/kckhg...

Re: Rust: Not So Great For Codec Implementing

#109

Earlier 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.

Yes, anytime source code is retrieved that isn't an existing, approved version, legal review of some sort must occur. This includes even referencing it despite what the other poster mistakenly believed I was implying.

Re: Rust: Not So Great For Codec Implementing

#110

Earlier 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…

Gotcha, thanks.
Post reply on HN