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.
With Rust, you really should just use crates. The std is meant to be limited to just the most used code and that which should not change for the sake of keeping the ecosystem stable.
Off topic, but it shouldn't be better than "even Python", because Python has a really, really broken dependency system. Far more so than Java, which has Maven/Gradle which are both infinitely better than the pip/virtualenv disaster.
People complain about things like shading in Maven being complicated. What they might not realize is that pip doesn't even try to address conflicting dependencies, it will just silently give you the wrong version! You ask for A==0.2 and it will give you A==0.1 if another dependency asked for A==0.1 first. And it won't even warn you even though it's straight up broken behavior. Virtualenv makes packaging annoying since it's almost vendoring but not quite. To totally understand the packaging system forces you into the world of eggs, wheels, disutils, conflicting versions, condas, etc.
Sorry for tangent, just thought it was funny you would hold Python up as a standard of dependency excellence when it's probably the worst overall ecosystem of major languages.
To me, this is a clear case of trying to fix a broken system whereas starting from scratch would be much better.
There are a lot of great things about Python, but dependency management is right there under the GIL on the list of things that are very painful.
Additionally, for anyone coming from almost all compiled native languages, a native environment like Rust with better dependency management than Python (which, as you say, and in retrospect, is pretty broken) is a bit of a mind screw.
Cargo should even be better than npm.
On the other hand I always asked myself if they couldn't simply use Nix?
Regardless, while it's cool and useful, it's not really actual Windows support.
Didn't take you for a Windows guy, hehe
It's due to video games... but I'm actually enjoying Windows 10.
I really liked that "dependancy as part of the language and build tool".
Of course, Go still had its own dependancy issues (versionning, availability, ...) that they now work on, but that was a step in a direction I quite liked.
You declare your crate dependencies in a Cargo.toml file. Rust does proper versioning of dependencies so having a separate manifest is desirable. Within your code you declare the existence of a crate via `extern crate` and then you can use it wherever.
> the compiler force you to remove the imports too
it warns.
It's more likely to be a part of RLS than rustfmt.
There's a separate tool called rustfix in development that can apply the suggestions given by the compiler, so it could theoretically prompt for these.
So each new crate added to your project ends up increasing the overall build time, which gets exponentially bad if you happen to add a dependency to a crate than happens to have a big dependency list.
I have a very basic word counting application with a GUI written in Gtk-rs, a fresh build straight out of "git clone" takes a few minutes, mainly thanks to Pango.
That's only a problem the first time you compile though, isn't it?
[0] - I eschew header only libraries, only if there is no technical way around them (e.g. templates).
[1] - I can AOT compile with Excelsior JET, IBM J9, JamaicaVM, PTC, , Oracle Java 9 (Linux x64 for the time being), ...
[2] - I can AOT compile with Mono, NGEN, .NET Native, CoreRT, IL2CPP, ...
Yes, it is a problem when you do a clean build, or when you have common crates across projects, because cargo doesn't have a concept of build cache.
You can try to workaround it by setting all target directories to same one via target-dir in your .cargo/config file, but there is no guarantee that the crate won't get rebuild.
1. not be malicious
2. not write a vulnerability by accident
3. not get their computer infected, their email account hijacked, etc.
4. be wise in transferring ownership
5. not add a dependency with a license incompatible with your project
All the above concerns apply recursively to the dependencies of the dependency.
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 that should consider including a copy of their little dependency instead via whatever method is appropriate for licensing.
This makes languages like Python, Go, Perl, etc. preferable over languages/projects like node.js, rust, etc. because (at least I) don't generally end up with tens/hundreds of dependencies since the standard library is rich enough for most work.
Additionally, I personally despise have many, small dependencies because it means I have more to think about and manage. Instead of just being able to think about the version of the compiler/standard library I'm using, I have to consider every individual crate.
I'm well aware of why rust chose to make certain tradeoffs with crates, but having numerous pieces of what many of us consider "basic functionality" as a third-party dependency is frustrating. Languages with richer standard libraries have spoiled us all.
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 avoid the hard work of making the language ecosystem handle dependencies properly.
> 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.
How is copying better than dependencies in this regard? You presumably need legal signoff either way.
> Additionally, I personally despise have many, small dependencies because it means I have more to think about and manage. Instead of just being able to think about the version of the compiler/standard library I'm using, I have to consider every individual crate.
This is what the "Rust platform" is designed to address. It is nice to be able to refer to a specific version of the Rust platform, but that doesn't mean you have to give up on the massive ergonomic benefit of the Cargo ecosystem relative to copying and pasting code.
Employees take shortcuts around bureaucracy all the time. Sometimes (often?) that bureaucracy is for legal reasons.
Your argument is the correct moral and legal one. Unfortunately that doesn't always matter. For another example, see the cognitive dissonance many express regarding ad blocking (not to come down entirely on one side of that issue, it's complicated).
If your company gets aquired one day, the code will probably be audited during the due diligence process. If licence violations related to copy-pasting is found, your team will be asked to remove the infringing code and your supervisor may be fired. This happened to my team in the first company I worked for (not the firing part though) : we had a lot of code which was just copy-pasted from lodash and the audit found it.
Would you rather a flawed, or later deemed incomplete internal solution be implemented and then the language is forced to support it in perpetuity, or would you rather one or more solutions get tried and the best implementation and syntax eventually accepted into core?
EcmaScript can do the same, and finally has[1], but it moves so slowly and has so many competing interests that it seems to take forever for that to happen.
1: https://www.ecma-international.org/ecma-262/8.0/index.html#s...
You can see what happens when you go too far the other way though. C has effectively no basic data structures like strings, lists, hash tables, etc., so anything you interface with has its own idea on how to handle that stuff. Library X might return an array of Things that's NULL terminated. Library Y might return an array of Thangs and a size_t output param. Or like you pointed out in JS, its standard library is full of holes so you get tiny projects that attempt to plug them, or larger projects that try to make JS into a specific kind of language (Underscore), or full on programming languages that transpile to it.
I just don't think the problem is definitively solved though. Personally I think Bytes should be in Rust's stdlib. I think bit and byte manipulation is a fundamental part of a language and there should be a standard way of doing it, especially if there are things like TCP/UDP and hash tables in there. I understand the arguments against; I really like the design of Rust's stdlib, but I feel like there's room for disagreement. That's all I'm saying :)
It's not a problem, in my view.
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 here was the bytes crate, which is fairly tiny. If rust is going to insist on not including the bytes crate, or a copy of it, in the standard library, then I would hope others that consume it would consider embedding a snapshot of it into their own crate for their own, private use so that I don't have to worry about it.
I'm well aware there's a fine line here, hence my reference to the Go proverb.
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.
This is where I actually prefer Go's "vendor" approach to dependencies. It would be great if rust / cargo eventually had the same and more authors adopted it or simply copied their little dependencies instead of having external dependencies on them.
Something like this proposed command, except for crate maintenance instead of distribution:
It's even used for releasing the official Rust tarballs as we now employ crates.io dependencies in the standard library and the compiler.
I think this thread is about copying and pasting code versus using a small library in the Go case, which might be a philosphical difference with Rust.
It might help to point out that vendored crates are compiled from source making the required review process referenced by that poster just as possible with server crates.
(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.)
Unlike a huge stdlib, a "distro"-style SDK is still factored into packages (in Erlang terms, "applications"), that can be included or excluded from any given release of your project. But it's all released monolithically, and comes as one big package. Probably helps a lot with getting legal sign-off for using the relevant packages. I wonder if that's why they (still) do it?
I can't count the number of times we've had problems with the requests library, either because of the huge tree of dependencies (both explicit and implicit) that requests has, and because of some of the assumptions made by requests.
On the other hand, when a bit more time is taken (yes, this means a few lines of boilerplate) and the code uses urllib2, it rarely has to be touched again.
But your larger point still stands.
Bytes is basically just C++'s `std::string` (kind of don't bite my head off people who've memorized the C++17 standard). Its an ARC backed array [1]. This suggests it should be a fairly fundamental abstraction.
Edit: ^^^My C++ is wrong sorry :(
Really I disagree with its purpose. In its immutable, non-threaded safe form you can create the same structure by just borrowing a value. This ofc requires making your peace with the borrow checker and `Cow<'a, T>` copy on write types.
By in large Bytes advertised purpose is network code. And for networking code its really only _super_ useful if your using a Packet Ring in Linux. As jemalloc will not return regularly re-allocated buffers.
Really this is all performance theater. How you manage/architect your socket reads/writes will have an order of magnitude larger effect then what abstraction you _store_ those bytes in once read.
[1] https://carllerche.github.io/bytes/bytes/struct.Bytes.htm