3 ms·

> A static library is a whopping 2.4 MB. The comparable number for C are 4K and 800 bytes respectively. It is possible to significantly optimize that number [0

• johncolanduoni 10y ago
  The article you linked is doing all of this with a binary. Last time I tried something like this with Rust, there were a lot more obstacles to cutting down this overhead with a library than a binary. Also note that towards the bottom he cuts out libstd, which loses any form of dynamic memory allocation, as well as a significant chunk of Rust's usability advantage. The biggest factor however is that you have to read through that whole page, use unstable features (alloc_system) that condemn you to the nightly, and download and compile musl. This is a huge, brittle pain at the moment, and far from obvious to anyone who comes upon Rust and is thinking of building a C-compatible library using it.
  • steveklabnik 10y ago
    > as well as a significant chunk of Rust's usability advantage. What bits are you thinking of here? Just curious, as I do a lot of no_std work, and don't feel that way, and am probably blind to it :) Rust 1.10, coming out later today, has a new crate type that removes Rust-specific metadata for dynamic libraries, by the way, making them a bit smaller for this kind of case.
    • johncolanduoni 10y ago
      Unless I'm mistaken, no_std means no built-in non-manual dynamic allocation (Box, Rc, etc.), unless you use "extern crate alloc", once again requiring the nightly. Some fundamentals one expects from a modern language like Vec are also missing in either case. This is fine if you're using no_std for something where these are anathema anyway (writing bare-metal OSes comes to mind) but a huge limitation for a humble user-space library. As it stands if you want to take advantage of Rust's safety you're going to need to reimplement at least Box, probably Vec, and Rc if your program requires that kind of thing. This isn't a huge time suck, but if I were feeling out C-compatible languages before writing a library it would be a major turnoff. I really like Rust for low-overhead binaries but it is missing a lot when it comes to writing non-rlib libraries.
      • steveklabnik 10y ago
        Ah I see. There's two things here: first off, I'm using it in an OSdev context, so I don't expect any allocation to exist, since I haven't actually implemented that yet. And second, I took your comment to mean the language itself, which doesn't lose anything with no_std, but you mean the convenience of the libraries, which makes sense. By the way, you _can_ reintroduce just those things if you want to. no_std means "don't include std", but you can then require them: #![feature(alloc)] #![feature(collections)] #![no_std] extern crate alloc; extern crate collections; use alloc::boxed::Box; use alloc::rc::Rc; use collections::vec::Vec; pub fn foo() -> Box<i32> { Box::new(5) } pub fn bar() -> Rc<i32> { Rc::new(5) } pub fn baz() -> Vec<i32> { let mut v = Vec::new(); v.push(5); v } Of course, as you can see, the facade crates are largely not stable, so doing this on _stable_ rust isn't quite there yet, which is a thing that matters, as you originally pointed out. I expect as Rust grows for this stuff to stabilize, after all, the std versions are re-exported, so this example is de-facto stable, other than maybe the 'use' lines, which is an easy fix in the future. Thanks for elaborating :)
        • johncolanduoni 10y ago
          Yes, my issue is just that creating a small library with a C API requires a lot of machinations that are going to turn off anyone who isn't really set on going with Rust. For OS development, standalone binaries, or Rust libraries, I think Rust is in excellent shape as it is.