On Fri, Oct 2, 2020 at 8:05 AM Dylan Baker <dy...@pnwbakers.com> wrote: > > I have serious concerns about cargo and crate usage. Cargo is basically npm > for rust, and shares all of the bad design decisions of npm, including > linking multiple versions of the same library together and ballooning > dependency lists that are fetched intrigued from the internet. This is both a > security problem and directly in conflict with meson's design off one and > only one version of a project. And while rust prevents certain kinds of bugs, > it doesn't prevent design bugs or malicious code. Add a meson developer the > rust community has been incredibly hard to work with and basically hostile to > every request we've made "cargo is hour you build rust", is essentially the > answer we've gotten from them at every turn. And if you're not going to use > cargo, is rust really a win? The standard library is rather minimal "because > just pull in 1000 crates". The distro people can correct me if I'm wrong, but > when librsvg went to rust it was a nightmare, several distros went a long > time without u pdates because of cargo.
(I am not currently advocating for cargo usage, but...) The standard library is large compared to what we currently allow for Mesa dependencies (libexpat, libz, libdrm basically). First thought I had was that my hash table/set is garbage compared to theirs, and we could probably just wrap rust's with my C API and get a win for compiler perf. Having to write u_dynarray-using code makes one wish we had Vec<>. util/os_socket.c? We write all sorts of stuff to work around how we have no standard library worth speaking of currently, and time we spend optimizing hash_table.c and fnv1 (or oh wait xxhash32 or is that one actually best...) is time that we're not getting to spend on making graphics code better. If you're worried about cargo deps, introduce a cargo lockfile, even though we're a library. Lockfiles are for rust code used as a rust library, I see no reason not to lock when our library has a C interface. Then you don't have the multiple deps or random versions thing, it's up to us what we want to use, even if you're downloading git of that hash off the internet. Yes, there's the "if you blindly uprev, you can pull in malicious deps" thing. I feel pretty good about that given the rate of dependency compromise attacks I've seen detected in npm/cargo/etc., compared to the rate of CVEs we could generate if we chose to aim a fuzzer basically anywhere in our codebase. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
