Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For me this says more about the drawback of easy and automatic dependency management. When I write C code, adding dependencies is often a huge pain in the ass. You need to figure out how it's packaged, how it's build. Should I build a custom version or just use $distro's pre-packaged version? How do I tell my Makefile/configure/CMakeLists where to find the headers and libraries?

This is generally a bad thing. It leads to NIH, to poor portability, to difficult integration in other dev environments etc... But it does mean that you carefully consider every dependency that you must use. The quality of the packaging is often an indication of the quality of the code too, a well polished build system inspires confidence, a crappy buggy bespoke shell script less so.

Meanwhile take this example: I've re-started working on a PlayStation emulator a few weeks ago. I haven't reached the point where I need to display images or output sound, it's pure algorithmic code with no I/O so far. That's 0 dependencies.

But then I wanted to add some basic logging infrastructure to be able to do 'warn!("this thing shouldn't happen")' or 'debug!("this register has value {:x}", val")'. I could just use println! but, hey, adding dependencies is super easy and I'll end up with more flexible and expressive code, so let's do that instead. So I add these two lines to my Cargo.toml (note the simple in simple_logger):

    [dependencies]
    log = "0.4"
    simple_logger = "1.3.0"
And as easy as that I have a proper logging framework available. Amazing. Except that when I then run `cargo build` I see the following:

    Compiling autocfg v0.1.7
    Compiling libc v0.2.66
    Compiling log v0.4.8
    Compiling lazy_static v1.4.0
    Compiling cfg-if v0.1.10
    Compiling num-traits v0.2.10
    Compiling num-integer v0.1.41
    Compiling atty v0.2.13
    Compiling time v0.1.42
    Compiling colored v1.9.0
    Compiling chrono v0.4.10
    Compiling simple_logger v1.3.0
That's 12 dependencies for a glorified println! implementation. Did I vet this code? Of course not. It would be faster to just reimplement it myself. Do I trust that somebody went to the trouble of doing it for me? Not really. I just cross my fingers and hope for the best. It's wonderfully convenient but I'd be very wary of trusting any security-critical project with a dependency graph like that, and it's quite paradoxical since Rust is all about safety.

Oh and beyond that Reddit is a terrible place that manages to be the worst of 4chan and the worst of Facebook in one convenient package and should be avoided at all costs, but we already knew that.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: