Hacker News Reader

Thanks for all your hard work on this amazing project. I am currently learning it and liking it a lot!

If I could, make a little suggestion?

Focus on building a community around the language, the way Go did, which was masterfully executed:

Newsgroups, conferences, videos, tutorials, more videos, talks, speeches, more tutorials, books, articles, blogs, docs. All of that, churning non-stop.

It's tedious. It's just as much effort as the language itself. I realize that. But it's truly why I even bothered with Go, which is, IMO, arguably a not-as-exciting language as Rust, yet already has amazing library/community involvement and support.

Being a project that Mozilla is invested in; I bet this is going to happen pretty well. Mozilla does community growth very well, and they care a lot about it.

(Also: these things already happen to a degree, and I hope they start happening even more now that 1.0 is out!)

Even though a solid package manager was enough to get me on board, I deeply agree with you in that building a community around it will make all the difference.

I'd also like to think it will be a bit less difficult for Mozilla to accomplish this because, well, Mozilla's values inspire loyalty, even love in my case, I love Mozilla.

No worries. All forgiven :)

Thank you ever so much for the hard work done by yourself and the rest of the Rust developer community. It has been an absolute pleasure seeing the language evolve, and now that it's hit 1.0, I look forward to the incredible opportunities it makes possible.

It takes great courage to go against the grain in terms of the core language (e.g. abandoning GC, M:N scheduling, etc. as core parts of the language), but the end result promises some truly exciting times. Thank you again and thank you also to you and the others for commenting here on HN despite the heavy criticism at times and being ever so helpful for those of us on IRC. It's been a fantastic ride and I look forward to it getting even better.

> It takes great courage to go against the grain in terms of the core language

So, what I like to say is this: If you look at Rust by mission statement, it hasn't changed at all. If you look at it by feature list, it's a completely different beast.

The focus of Rust has always been a safe, fast, concurrent systems language. It just took a while to figure out exactly how we wanted to accomplish that goal.

And I'm grateful that you took your time to let the language mature.

If Rust fulfills it's mission statement, it might become widely adopted. While that's generally good, it also makes changes to the language hard, see C++.

So, let's hope you got the things right that you can't change without breaking compatibility.

Curious here: would Rust be a better language for writing the VM of an M:N-scheduled platform? Like, would rewriting Erlang's BEAM in Rust be a win?

So, in general, Rust should be good for writing VMs. If you want a JIT, though, Rust may not have any super huge advantage with it, specifically, as it would basically be all unsafe anyway.

There was a really great blog post about writing a Scheme implementation, including a GC: http://fitzgeraldnick.com/weblog/60/

I'm pretty sure even when building a JIT Rust would provide advantages. The only unsafe part of JITing is allocating the underlying instruction buffer and marking the memory as executable to the OS. You could still leverage Rust in building compilers from IR -> Instructions.

Yeah, it's only for part of it, maybe the SpiderMonkey people I was talking too are more focused on the unsafe part than the other parts.

The point is that whenever you do "IR -> Instructions" you are opening the possibility for logic errors to become memory errors. E.g. emitting opcode 9 instead of opcode 8 might (on some system) allow an attacker to execute arbitrary code. And these sorts of bugs cannot be prevented by pure memory safety alone, once you have (intentionally) opened the door to writing executable memory. You would actually need a full theorem prover to check the correctness of your code for you (which obviously Rust does not provide).

That raises the question of whether any major features that contribute to safety have been there the whole time?

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 :-)

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 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.

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

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.'

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)

Look at it this way: You beat Perl 6 to market. :)

It seems like just yesterday I was getting all misty-eyed over losing my friend the `~` sigil.

rust-story builds on 1.0, though, so I think I'll be able to forgive you. ;^)

Congrats on the release!

That's funny, because I started hacking Rust just because the `~` sigil and friends were gone. :-)

Before that, so many sigils in Rust scared me and kept me from learning it. Rust still has a bit many sigils nowadays, but it's definitely cleaner than before!

>so many sigils in Rust scared me and kept me from learning it.

I had just started seriously learning rust a few months before they started moving owned pointers into `std`.

So I felt somewhat betrayed by the removal of the sigils. It seemed like all the hard work I had spent learning the various pointer types would end up being useless!

Of course that fear was ungrounded. I very quickly came to understand that what I had actually spent time learning was ownership; and _that knowledge_ is still perfectly relevant, even today in rust 1.0.

All that was really changing was the removal of some arcane syntax which had only served as a stumbling block in my quest to learn Rust.

> It seemed like all the hard work I had spent learning the various pointer types would end up being useless!

I always joke about this being "programmer Stockholm syndrome": When you've mastered something that's actually not good at all, don't want that time and effort to have been for nothing, and become a champion for crap. It happens a lot and usually unintentionally - the champion feels genuine joy about the intricacies of what they're pushing and just wants to share it with others. You can see this happening a lot around poorly thought-through and/or overly complex technologies.

This is why Rust's progressive trimming and slimming over the last 1-2 years has been really impressive and gratifying to watch - it really takes a lot to reevaluate and let go. Critics will point out that Rust still is plenty complex, of course, and I think that's healthy skepticism too.

When I hear Stockholm syndrom, I always think javascript and css ^^

People hate me for this, but that's pretty much how I feel about emacs and vi

So true ! I am a vim user from time to time, and the only advantage is it hurts my fingers less than sublime text.

That was my reaction as well: not just the sigils, but in general Rust used to have a much larger language, and dropping the sigils was part of a shift towards having a much smaller language and larger library. That seems like a feature, not least of which because libraries can be improved and replaced.

Yep, the dropping of the sigils was a big help in my actually giving the language a chance. It's been on my radar for a while, but went through a pretty ugly period for a while before coming out much better than before.

There was also just a sense of "OK, I get what these things do, but when should I us an @ vs an ~ vs a & in my API", and now I feel like it's much more clear what you use the different reference types for.

Thanks for your work on Rust, a very cool language. And although the massive 3k poem was removed Rust-created binaries, and it initially pissed me off when I discovered it, thanks to Brian Anderson for sharing.

https://github.com/rust-lang/rust/issues/13871

Congrats on 1.0! If you thought language design was hard before wait until you try to keep doing it without breaking anything. :)

Any plans to take Rust to the big data arena? Oh how I wish I had Spark Rust API... lower memory footprint, no GC, yet it will be pretty straight forward to migrate Scala / Python jobs to Rust (with a small memory management / borrowing concepts learning curve I assume).

I think that if there is a place where people can sympathize and forgive you for over confident time estimates it must be on HN.

All forgiven. This is great news.

Great, congratulations! Also let's mention Servo (browser engine) - the project has a symbiotic relationship with the Rust programming language, in which it is being developed (also from Mozilla).

https://news.ycombinator.com/item?id=9541138 (two days ago on HN) and its website: https://github.com/servo/servo