Hacker News Reader

Comment by ChuckMcM | Hacker News Reader

It is an excellent achievement, congratulations!

For what its worth Java had an even longer gestation period and it wasn't until Eric Schmidt declared that we had to have 1.0 in Bert Sutherland's desk by 1/1/95 or "else" did it actually get to that point.

I'm really excited to start trying it out in earnest.

This is a bit disconcerting though:

   ls -lh
   total 588K
   -rwxrwxr-x 1 cmcmanis cmcmanis 8.4K May 15 13:02 hello_world
   -rw-rw-r-- 1 cmcmanis cmcmanis   83 May 15 13:02 hello_world.c
   -rwxrwxr-x 1 cmcmanis cmcmanis 565K May 15 13:01 main
   -rw-rw-r-- 1 cmcmanis cmcmanis   42 May 15 13:01 main.rs

I'd love to write a safe embedded system in rust and that is going to mean much smaller footprint for a 'hello world' level of program :-)

View on HN

As you can already read in this thread (see [1]), this is due to static linking of the whole standard library. This limitation is known and solutions are being worked on.

[1] https://news.ycombinator.com/item?id=9552468

Only one component of the three is really even being worked on, the other two are there: use LTO or dynamically link. Not linking to the standard library itself is behind a feature gate for now, but it should be relatively easy to stabilize in the future.

It might also help to have the option of using libc's malloc rather than jemalloc.

Custom allocators are certainly a thing that's coming in the future. :)

So when I port the compiler to use newlib nano this goes away?

As steveklabnik (see [1]) stated, there are 3 things missing: dynamic linking, link-time-optimization and the possibility to not link to the standard library. Each of these techniques will be able to reduce the size of Rust binaries.

[1] https://news.ycombinator.com/item?id=9553366

My target is a Cortex M microcontroller so its always statically linked :-)

Does Golang support dynamic linking? I think a Hello world binary in Go is about the same size? I know I'm sort of comparing apples with oranges here.

Go hello world is larger, but it's static and includes the native Go libc equivalents instead of depending on glibc.

  $ size hello
     text    data     bss     dec     hex filename
  1329045   25256  102376 1456677  163a25 hello

That's a stripped Go 1.4.2 hello world (1941480 bytes unstripped).

Yes, you can dynamically link by compiling Go with gccgo (https://golang.org/doc/install/gccgo).

How? do you have tutorial/info about it? (The link above doesn't explain how.)

I'm not sure what you're doing:

(go here to address some other comments):

    ls -s1h hello*
        1.9M hellogo
        4.0K hellogo.go
         12K hellors
        4.0K hellors.rs

rust-code:

    cat hellors.rs
    fn main() {
      println!("Hello, world!");
    }

go-code:

    cat hellogo.go 
    package main

    import "fmt"

    func main() {
        fmt.Println("Hello, world!");
    }

Compilers:

    rustc --version
    rustc 1.0.0-beta.3 (5241bf9c3 2015-04-25) (built 2015-04-25)
    go version
    go version go1.4 linux/amd64

Flags for rust (inspired by[1], which may or may not be similar to what cargo build --release does...):

   rustc -o hellors -C prefer-dynamic -C opt-level=1 hellors.rs

[ed: to add: If I strip the binaries, hellors ends up at 5.8k, hellogo at 1.3M. I built hellogo with just: "go build hellogo.go" -- I'm not sure if there are any flags that would make sense? ]

[1] https://github.com/rust-lang/cargo/blob/c874e37fbe195e86d6dc...

Not that it matters but the go binary should be smaller if you use 'println()' instead of importing fmt.

Ok. That code is from the go-lang homepage (except for changing the text, so the two programs are mostly identical), so I'm guessing (hoping) it should be considered (more) idiomatic?

Would using naked println be similar to using putc in C?

Anyway, just tested, and stripped a version without fmt is 414k.

I thought println was like puts in C but it appears to be capable of printing multiple types and support a variable number of arguments(?). It has zero dependencies (in theory) and is just a little bootstrapping/diagnostic tool and might even eventually be removed [0]. Importing fmt seems to import the package which adds a lot of bloat to hello world.

But realistically anything more complex than hello world is going to be at least a few MB in go, and eventually you might have to use fmt.Println() and most production code probably does.

Edit: and yes fmt.Println() is idiomatic. I was just mentioning that it is possible for helloworld to be a bit smaller in go than other go programs.

[0] http://golang.org/src/builtin/builtin.go?s=10600:10626#L240

Doing basic imports is a valuable addition to hello world, as it demonstrates the tool-chain is working :-)

I just found out that my rustc-arguments probably were wrong (for most uses, anyway). Or rather, they link dynamically to the rust standard library -- which while "equal" to C, won't hold most of the time. All (non-embedded) systems will have libc for the foreseeable future -- assuming that they have rust libstd is probably not a good assumption to make.

I found this out after I upgraded to rust-1.0, and the lib/libstd-<hash?>.so files changed names.

So while:

    rustc -O -C prefer-dynamic -o hello hello.rs

works, that produces a really dynamically linked little binary. One probably wants:

    rustc -O -o hello hello.rs

This statically compiles in the rust std lib, and leaves a binary that's ~332k after stripping.

(Btw, -O is equivalent to -C opt-level=2)

If you are targeting ARM microcontrollers, you may be interested in http://zinc.rs/, which includes only libcore and results in libraries of a few kB (or, hundreds of bytes for just a blinky).

Ok, now we're talking! Made a 'fork' of this repo to start playing with it in parallel. This is exactly my question/investigation which is can you make a nice "safe" embedded OS for bare metal hardware. My thesis is that if you can then a bunch of stuff like embedded routers and IoT things will be safer. And that is a key requirement for this brave new world of 'everything is a computer.'

One is dynamically linked and the other is not, so the comparison tells us nothing.

I'm waiting for this and the dependencies on glibc/libgcc to be sorted out. I keep hearing it should be possible to build lightweight binaries, but the last several times I tried, none of the recipes I found for such a thing actually worked.

Reply on news.ycombinator.com