5 ms·

For libcurl - easy linking to any C/C++ code is very good reason. And standalone curl is lighweight with minimal system dependencies.

• tptacek 10y ago
  I understand libcurl well (I've used it before on projects), and don't dispute its utility. I also understand the value of a very small C-based HTTP fetcher for system bootstrapping (I'm not sure that's really what curl is). What I don't get is why the most widely used general purpose command line HTTP fetcher is a giant C program that we're still finding UAFs in in 2016. I respect the enormous effort that goes into maintaining curl (though I have my differences with the way security is handled). But it's past time curl is replaced by a Rust or Go program.
  • tomcam 10y ago
    You're a pretty smart guy. Why not just knock out that little baby yourself?
    • tptacek 10y ago
      I'm hoping someone else already is.
      • JoachimSchipper 10y ago
        You might want to consider OpenBSD's ftp. It does a lot more than FTP.
  • shakna 10y ago
    A statically linked curl for ARM64 is 205kb. A statically linked hello world in Rust for ARM64 is 680kb. Curl is used for a ton of embedded hardware, and is probably in your router. Until Rust can solve its massive binaries, that is somewhere on their roadmap, it just isn't appropriate for use in the embedded world, where kilobytes still count.
    • ekiru 10y ago
      But there's also no reason why the most widely used HTTP fetcher in embedded software should be the same piece of software as the most widely used command line HTTP fetcher on workstations and servers, most of which do not care much about shaving kilobytes.
      • shakna 10y ago
        And no reason that the most widely deployed kernel in embedded and server worlds should be the same. But it is, and written in C. Its called GNU/Linux.
        • saghm 10y ago
          Not taking a side on the whole Linux vs. GNU/Linux thing, but the kernel is decidedly not called GNU/Linux; it's just Linux.
        • pcwalton 10y ago
          This is in fact a strong argument against your hard-line "every kilobyte matters" stance above. Linux is not a particularly small kernel. If code size in the embedded world were really as paramount as you claim, we'd see a lot less Linux and a lot more random RTOSes.
    • pcwalton 10y ago
      > Until Rust can solve its massive binaries, that is somewhere on their roadmap, it just isn't appropriate for use in the embedded world, where kilobytes still count. A demo written in Rust [1] won a 64kB demo competition against C and C++ competitors. It is already solved if the binary size is a problem for you. You can easily get down to 160kB without a whole lot of effort (i.e. avoiding libstd) [2]. [1]: https://www.reddit.com/r/rust/comments/597hhv/logicoma_elysian_1st_place_trsac_2016_pc_64kb/ https://www.reddit.com/r/rust/comments/597hhv/logicoma_elysi... [2]: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...
      • 10y ago
  • sapphire_tomb 10y ago
    I love the delicious irony that the install instructions for Rust on linux (from https://doc.rust-lang.org/book/getting-started.html https://doc.rust-lang.org/book/getting-started.html) specify : "curl -sSf https://static.rust-lang.org/rustup.sh https://static.rust-lang.org/rustup.sh | sh"
    • tptacek 10y ago
      That's not ironic. Tools bootstrap other tools all the time.
  • tinus_hn 10y ago
    So, when are you getting started?