Announcing Rust 1.0 | Hacker News Reader

Announcing Rust 1.0

blog.rust-lang.org

1,363 pointsjhund306 comments

I would like to take this opportunity to formally apologize to the HN community for that time back in early 2012 when I predicted that Rust 1.0 would be released "in about six months or so", and later proceeded to proudly proclaim that 0.4 would be the last release with major breaking changes to the syntax. I hope you all can find it in your hearts to forgive me. :) But at long last, we did it, and it's almost too good to believe.

But as much work as it's been just to get to this point, the real struggle begins today. Months and years of brutal campaigning, compiler engineering, and careful language design lie ahead. If you've yet to take a look at Rust, please do, and report your findings so that we can better prioritize our efforts for the near future. If you like what you see, there's plenty of work to go around and a welcoming community should you decide to dig in and join us. And if you don't like what you see, that's fine too; Rust is not the language to end all languages! We're just here to make the world a little safer, however we can. Hopefully today is but the first page in that story. :)

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.

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?

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

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

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.

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

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)

All forgiven. This is great news.

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.

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

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

For anyone that hasn't played around with rust yet, this is why I'm excited about rust: https://github.com/Azdle/hello-gtk.rs/blob/master/src/main.r...

That is a GTK GUI application that makes HTTP requests in under 40 lines of code.

Don't get me wrong I love all the safety gaurentes and what not, but just being able to write quick simple apps that would usually be a pain to write in C is a game changer for me. A lot of this is down to Cargo (the Rust package manager, very npm-like imo) and all the great rust libraries that already exist. I'm super excited to see where this goes now that it's 1.0, people can stop worrying about breaking changes in the language and just get down to writing libraries to do everything.

I agree this is a very good thing by itself, but let's be clear that the extremly poor programmer ergonomics of the GTK-via-C stack have been superseded by nicer kit long ago (even within the GTK community).

Seems like theres no good reason for rust to do this when vala can -- and better, it just compiles to the same C

Vala has reference counted garbed collection, while Rust doesn't need that. Also, Rust verifies, among other things, the absence of data races.

That's not much good when you're just talking to ahitty GObject APIs that - guess what! - use reference counted GC and have lots of race conditions. You gain nothing

Yes, you do. Your internal logic doesn't need the overhead of reference counting and can be race-free.

This is how Mac apps tend to be fast: the high-level application logic is reference-counted and uses relatively slow Objective-C dynamic method calls, but things that are performance critical (CoreGraphics, VideoToolbox/AudioCodec, OpenGL, sqlite, the Mach kernel) are written in C and C++.

This is also a general pattern in Rust, cf. unsafe blocks: You wrap code that doesn't adhere to Rust's strict rules (e.g. because it interacts with C) in unsafe { }, disabling various compiler checks and requiring you to check it for correctness manually. Unsafe-ness doesn't bubble up, though, i.e. having an unsafe block within doesn't taint, say, a function - allowing you to silo nasty things away and enforce strict checks around it.

I haven't noticed that Mac apps tend to be faster than apps on other platforms. Can you provide a citation for this?

I didn't mean "faster than other platforms", just "not slow". Really it's a testament to the fact that front-end glue logic can often be written in whatever language you want without compromising interactive performance (as long as the implementations of those languages don't require long pauses or something like that), which is something we've known for a long time.

Heck, when doing Objective-C I'd drop down to C++ as quickly as possible just because the language is nicer. I'd be even more inclined to drop down to Rust.

Not that it's not amazing, but can't i'm pretty sure most languages can do that same thing.

Does this build with something simple like "cargo build" ? It should but I can't test right now on this PC.

If it does than I would disagree - not many other native languages can do that - having a native language with a sane build system, package management and proper modules would be a huge deal on it's own.

Yes it does. I just do a `cargo run` and it figures out the dependencies, builds, and runs.

Just tried, and it's both a little frighting and a delight to see cargo pull down and build the dependencies. For the information of those that can't test at home, the stripped release build weighs in at 722K, and worked on first try on my Debian Jessie system. Woho!

You might want to add a CC0 license to the project (or something else, but that's usually what I see recommended for "sample code").

[ed: and:

   ldd ./target/release/hello_gtk |wc -l
   59
]

Why is that exciting? You've been able to do that almost line-for-line in Python for at least 8 years, if you're not bothered about the "safety guarantees and what not".

Admittedly, I've never tried using GTK from python and that seems like it does take care of a lot of the "easy" that I'm liking here. However, it's really the combination of everything that rust offers while still letting you make short programs like this.

I really don't mean the downplay all the safety stuff, that is the main reason that I'm interested in rust. I just don't feel like the fact that you can do things so easily in rust gets enough attention.

My biggest "Oh my god, that was awesome!" moment was when I first built the project and Cargo just took care of the whole dependency tree and I never even had to think about it. I've never had that in a low level language before. I've actually been stepping out of a lot of the C that I've been doing into doing more with JS just because NPM makes it so damn easy to whip something up. I'm hopeful that rust will let me come back to a much lower level where a 10MB binary is really large.

Why are you not bothered about the "safety guarantees and what not"? Note that "what not" includes a lot of performance and portability which Python will likely never have, but Rust might.

Rust is not a replacement for Python, but a replacement for C.

It's exciting that you can have power, portability and speed competitive with C, but with syntax and safety so good that you're comparing them to Python :)

> Rust is not a replacement for Python, but a replacement for C.

I think its a mistake to view any language as simply a 1:1 replacement for an existing language. Newer languages can have the greatest strength in an area currently dominated by one older language (say, Rust with C), and still be better for some applications where another older language would generally be preferred to the first (say, Rust being better than Python at some things where Python would generally be preferred over C.)

Rust is a replacement for C++ not C

Python is great for prototyping - perhaps especially GUI. But it's not so great for distributing an app.

Huhwhat? You distribute it like any other - look at the original bittorrent client, or the HP printer tools.

Even PHP can do that

http://en.wikipedia.org/wiki/PHP-GTK#Example

Now that Rust reached v1.0, I may finally look into it without the fear of wasting time to learn stuff that will change within next months. (It's quite sad, though, that recently released Debian Jessie won't have it in its main repositories.)

Allow me to ask some questions, because I cannot easily find the answers and they're IMHO crucial for wider Rust adoption:

1. What CPU architectures/platforms Rust currently supports?

2. What's the state of cross-compilation support?

Most of devs have workstation on i386/amd64, but some of us may work with ARM, PowerPC and other architectures. Rust's memory safety seems appealing for embedded solutions, but can it be used there already?

BTW The install page is not well-thought-out.

http://www.rust-lang.org/install.html

Unless I hover on the 32-bit/64-bit links and read addresses they point to, there's no way to tell whether it's for x86 or ARM for instance. And installation via piping script that is being downloaded to shell is something that shouldn't be present at all.

1. In a sense, anything LLVM supports. Some stuff is more first-class than others, of course. We test every commit on x86, x86_64, and ARM.

2. Exists, but isn't particuarly easy. The biggest hurdle is getting a copy of the standard library for the target platform, then it's pretty easy. It's gonna be a focus in the near-term.

Thank you for such a prompt answer.

EDIT:

Quick googling revealed that Rust doesn't work with musl libc yet. It will be really nice when it will be fixed.

There is actually preliminary support: https://github.com/rust-lang/rust/pull/24777

Making this work well is a very high priority.

Alas, ARM describes a mutually incompatible family of related ISAs. Which ARM(s) is Rust tested on? V7-A, V6, V7-M, V4T?

Ah, so you know what: I thought we tested Android on ARM, but apparently it's x86 and x86_64 too: http://buildbot.rust-lang.org/buildslaves/linux-64-x-android...

There's a community member that keeps the iOS build green, I forget which ARM that is.

We do test Android on ARM. That's an x86_64 buildbot which builds a cross-compiler to Android on ARM and executes a full test suite on Android emulator using a remote testing support which even includes running gdb remotely.

The official tested support is for V7-A, but V6 support also is in tree.

Works for me on ARMv8 (aarch64): https://github.com/dpc/titanos , and I expect it to work on anything that LLVM supports.

> installation via piping script that is being downloaded to shell is something that shouldn't be present at all

The alternative is you download a binary and run it, at which point that binary can do whatever the shell script could have done.

(The other alternative is you download source, at which point the Makefile or any other piece of the build that you execute can do whatever the shell script would have done.)

As long as the script is available via https the security is equivalent to the alternatives.

> The other alternative is you download source, at which point the Makefile or any other piece of the build that you execute can do whatever the shell script would have done

Part of the problem with this is that since it's a bootstrapped compiler, and the only one for the language so far, "downloading source" mean you need a binary to compile it with, which devolves to the same problem.

Rust was bootstrapped with an OCaml based compiler. Alas I don't think it has been kept up to date, so you won't be able to use it to compile the v1.0 source. Not sure how many generations in between the last OCaml compilable rust and the current rust you'd need to compile to bootstrap, probably quite a few.

Very, very, very many. https://github.com/rust-lang/rust/blob/master/src/snapshots....

I've still thought about doing it.

A while back, somebody got Cargo running on an unsupported platform, but bootstrapping was a major problem. The compiler had to bootstrap newer versions of itself tens of times, and that was only for a few weeks of breaking changes …

Thank you so much to all of our community and contributors. It's been a long time coming, but I'm really proud of what we've done together.

I'm finally going to get some real sleep tonight, I think.

This is so huge!

Rust is going to be the first time I am going to learn a programming language from the day it is born (until now it was tough to learn Rust, given the changing APIs ;).

I see a bright future for Rust. Thanks to Mozilla and the whole community for making it possible.

I wish there could be a site started by the very beginner's to document the learning and adventures one gets from this. I wish it could have people of various expertise, from those never having learned a single language to those with several languages under their belt. I would have a fun time learning alongside them. It will be just like high school all over again.

The book "The Rust Programming Language" is really solid and everyone learning the language should read it.

Congrats to the team and thanks for your hard work! I'm not a Rust developer but it's definitely piqued my interest in doing more native development without being afraid of introducing buffer overflows and other security exploits.

Awesome! I assume you intentionally released this on a Friday just to eat up everyone's weekends :) Thanks for the hard work. As I dig in, I'm hoping that Rust will fit in the "useful and safe" sweet spot in Simon Peyton Jones's diagram here: https://www.youtube.com/watch?v=iSmkqocn0oQ

> I assume you intentionally released this on a Friday just to eat up everyone's weekends :)

Hehe, we didn't choose it for any specific reason, but when we started to do the six-week cycle, it landed on a Friday. I like shipping on Friday for a number of reasons, but there's good reason to pick any particular day.

I actually liked it for selfish reasons. I got to stay out way past my bedtime and geek out about Rust at the Boston meetup. :D

If you haven't played with Rust yet and are looking for some puzzles to help motivate you to learn, we've updated our Bloomberg CodeCon[1] site to support Rust 1.0. You can login and click the "Challenger Series" to get 17 problems of varying difficulty to solve in Rust.

[1] http://codecon.bloomberg.com/

This is cool

Wish the problems would come with a sample datasets though

For example, the first problem "gloves" says you have a limit of 1024mb memory, 2s runtime, 100,000 max dataset size

How are you supposed to test that, without going through the motions of generating the data yourself?

EDIT: I do realise you're supposed to use the online editor thing and submit the answers to your server for the code to be judged, but I loathe writing code in my browser, would be nice to test offline in my own editor!

Requires Twitter or Google+ login. (For me that gets an instant back-button, and the fact that one can't see any of the actual content of the site before logging in makes it worse. But I expect there are good business reasons for it. Anyway, I mention it here because it may save a click or two for others who share my prejudices.)

If you don't want to login you can get most of what you're looking for here -- the content used for the finals (questions) along with the solutions.

http://codecon.bloomberg.com/2015-finals

Well done! I'm generally against shoehorning languages into environments where they don't belong, but I can't wait to try using Rust for webdev.

You might enjoy http://arewewebyet.com/

No mention of non-blocking IO or a concurrency model that isn't 1:1 with OS threads.

What's the plan on those fronts if they won't be in 1.0?

That they'll be coming in later releases. IO is a library concern in Rust, not a language concern.

There are already crates that offer some of this, like mio.

>x is a library concern in y, not a language concern.

The end user doesn't really care. The line between the standard library and the language is usually invisible.

> IO is a library concern in Rust, not a language concern.

It often is a language concern: no async/await in the compiler or language-assisted yielding/scheduling means difficult or impossible concurrency model.

With Rust's borrow checker, IO (already unsafe C FFI) + callbacks are hard to write in a pleasing and safe way.

You're right, that site should be updated with those as other parts of the ecosystem that aren't yet mature.

There's work on non-blocking IO at https://github.com/carllerche/mio, which is looking like one of the more promising approaches, as well as https://github.com/carllerche/eventual which provides higher-level abstractions over it.

There has been some discussion of adding some language support for something like async/await/yield from other languages, but nothing concrete in the near future on the language front.

So, there's usable third-party libraries for it (at least, if you're on a Unix like platform), language support is in the realm of "it would be nice someday".

What's the deal with compiling Rust to JS? (That's not discussed on the website.)

Some people have gotten emscripten working, even with graphics and stuff: http://bl.ocks.org/AerialX/1041460cb9dd5876658c

My remembering is that it uses a different LLVM version than we use, which is very cutting-edge. So we need them to update before it works well.

As someone who tried it for a bit, it really is not the right use case. : P

With the large box flexibility you get with webdev, I don't know why you would want to use it except for specialized parts. Like a RAW -> jpg transcoder.

One reason: really, really low resource usage. Crates.io is reasonably complex, linking to libgit and such, and still uses roughly 25MB of RAM, constant. A Ruby process is ~30 MB off the bat last I checked, and Rails, well...

But how does it compare to go in this case?

I don't really program in Go, maybe someone who does can chime in. I'm not aware of any sort of recent direct comparison in this area.

Haven't made any direct comparisons (and that would be hard) but from my experience from working with both I would say that you probably won't notice a big difference in RAM usage (< 10% difference).

Web library maturity aside, is the language inherently less suitable for webdev than Go?

Not really suitable, more from a dev speed perspective vs Go. You have a GC for example, and the opinionated nature makes managing a large code base better. Also a GC pause isn't a big deal for web apps as far as I know.

A reason why I would choose Rust possibly is because you can prevent data races although with it's memory management model.

Two points:

- Performance is important even for web applications. For example, after migrating to HHVM, Wikipedia could buy less servers, serve pages faster, and reduce latency.[1] Rust is fast, even compared to other statically compiled languages.

- Safety is also good to have for web development. I personally find it difficult to refactor my Python web applications. This isn't necessarily an advantage of Rust solely, statically typed languages tend to have this property more or less. But Rust does provide more guarantees than ordinary languages do.

[1] http://blog.wikimedia.org/2014/12/29/how-we-made-editing-wik...

I've been porting some JSON/HTTP API servers from Go to Rust recently, and it's been a really nice experience. Rust has convenient struct serialization just like Go, and Hyper is coming along as a nice (relatively) low-level HTTP library. If you want a higher abstraction HTTP server, go with Iron that builds on Hyper.

The I/O libraries have more work to be done (mostly for the async story), but they're ok for now and the plans I can see look promising. I see a bright future for those of us who like to write robust and high performing API servers, so don't shy away from Rust in that domain!

EDIT: Forgot to say that everyone's very friendly in #rust-webdev where Hyper/Iron authors and others can be found.

Congrats! I've been excited about Rust for a while now, and this gives me a good reason to look into it a bit more. A quick question, though, if it's appropriate in this context:

It seems to me that the borrow checker disallows behavior that I (perhaps naively) wouldn't be concerned about. For example, if I have this C snippet:

  { // Safe C
    int *ptr = NULL;
    int val = 42;
    ptr = &val;
  }

Everything is hunky-dory. Translating this to Rust results in this (I think):

  { // Malformed Rust
    let ref: &i32;
    let val = 42;
    ref = &val;
  }

Now the borrow checker tells me that "val" doesn't live long enough, because the reference comes to life before the value. It seems like this should be safe behavior, because the reference isn't bound to the value until after the value comes to life.

Can anyone shed some light on this for me? I'm all for safety, but this in particular seems like something that I should be allowed to do.

I'll assume you meant 'ref = &x' in your example.

But what happens is that variables leave scope in reverse of the order in which they came in, so ref lives for slightly longer than val.

This happens so that the order of destructors can be guaranteed.

> I'll assume you meant 'ref = &x' in your example.

I did, thanks.

refs don't have destructors.

This happens because borrow scopes are always lexical. This is a bug, see https://github.com/rust-lang/rfcs/issues/811.

Bug =/= language feature that we want that hasn't been implemented or designed yet, FWIW. Right now the borrow checker is currently performing to spec, but the spec is just a little too restrictive in some cases.

"Bug =/= language feature that we want that hasn't been implemented or designed yet, FWIW."

In this case, I think the term is justified.

Honestly in my experience it's a deal-breaking bug. It's so awfully crippled compared to DDC regions.

I'm not an expert, but I think...

Your ref can't be unassigned. There are no null pointers.

You can define a binding without the value it's bound to:

    let x: i32;

But you have to assign to it before you can use it.

val ceases to exist before the reference ceases to exist, beacuse it's declared after. So after val is destroyed, the reference is invalid. Declare val earlier. Your code would be very nutty in C too.

I think I disagree with the "your code would be nutty in C" comment. Since C requires all variables to be declared at the top of the scope, and the order of declaration doesn't matter for purposes of allocation, there's no reason to worry about the ordering in this case.

(C does not require all variables to be declared at the top of the scope.) Even if you're using a version of C that does, the order of variables implies something about their lifetimes and your code could make somebody refactoring more likely to believe they can lift the pointer out to the containing scope, or put the int in a smaller scope.

Only C89 requires this. Compilers have moved on.

In C the order of declaration and destruction doesn't matter as much, because C has no destructors. C++ would have similar issues, though.

Well, your first issue is that 'ref' is a keyword, so this doesn't work. Changing to just 'r', you get a 'not long enough' message. This is because you defined them in the order 'ref then val', but they would be destroyed as 'val' then 'ref'. That would leave 'ref' dangling, if even for a moment, like here. That'd be bad.

Well, that whole "ref" thing just shows my ignorance of Rust. Thanks for the information.

> That would leave 'ref' dangling, if even for a moment, like here. That'd be bad.

I'm not sure I agree that it would be bad (except maybe from a purity standpoint). Ref is unreachable during the time it is "pointing" to the out-of-scope "val", so nothing can actually reach the out-of-scope value through ref.

In this specific instance, with these types, sure. Imagine you had two different types, with a destructor defined, which did things. Any amount of code can run between those two things being free'd.

True, but pointers don't have destructors in C++ or Rust, I think (and in C, there are no destructors at all, obvs).

These particular references don't, but many smart pointers do. The borrow checker doesn't currently do something different based on Drop.

You can argue that it would be easier if it just made this work, but at the same time, there would be more special cases. Right now, the rule is very simple.

We'll see once SEME regions and or non-lexical borrows land, though...

Yes, you're correct. One thing people want to improve is Rust's ability to detect situations like this, where there is a dangling pointer but it can't actually affect anything. The current rules are deliberately conservative, and even with these rules we have seen a fair amount of accidental unsafety in weird syntactic edge cases that had to be fixed.

It's always exciting reading Rust posts on HN, so very happy about a stable release!!

I can't help but feel the language has a very steep learning curve, however; doing something like making an event-queue-with-callbacks is very hard to write out in Rust if you're a beginner with just the current docs.

I think Rust will benefit greatly if their docs compiled some articles on how to write typical systems-related code (for me, I would love to see how to implement task queues with callback mechanisms).

Congrats Rust team, and perfect timing, got some vacation next week and plan to build some things.

I thought 1.0 was announced a few weeks ago. Am I going crazy? I mean it's awesome news I'm just confused.

Edit: looks like I'm going crazy. It seemed so vivid too like I actually started checking out the rust documentation and was looking for a book to pick up. Unless everyone is messing with me...

Several beta versions have been announced before, but this time, we're talking about the first stable version.

It went through a pretty standard alpha and beta release cycle, you must think of one of those announces.

It seems you might be suffering from the Mandela Effect. Do you remember it being the Berenstein Bears or the Berenstain Bears?

> Do you remember it being the Berenstein Bears or the Berenstain Bears?

Um.......yes? Crap.

This is blowing my mind. I remember Berenstein Bears as well.

It reminds me of a prank when one of our co-workers left her computer unlocked, one of us sent an email to her from her own account saying "This is a reminder, you were taken by aliens, I am writing this to you so you can remember." She is not technical, so se freaked out a lot. Anyways, Rust 1.0 is released today, so your work of digging into the documentation is not wasted. :)

Why have you been posting this same comment everyday for the last 12 days???

Thanks so much to everyone who contributed to this milestone. Rust is one of the few pieces of new technology that has made me want to drop everything and dig in to it.

It's also one of the few open source projects that has actually gotten me to contribute.

I'd like to give special thanks to Daniel Micay, whose contributions are a major reason Rust is even remotely tolerable.

Awesome! Now to get the STL docs up to speed and fix them up so that they're less ambiguous to newcomers!

The STL docs? And what specifically is ambiguous? (and thanks :) )

Well, when I started learning (around Beta 2, I'm by no means an expert yet but eager to get there!) a lot of the docs about both I/O and type conversions/type casting could've used some work, just to name two features...

Oh, the "T" was confusing me, you mean the standard library docs?

And yeah, there's certainly a ton of weak points. We landed a _lot_ of Rustdoc fixes that make certain things better, but there's still a ton more to write. I've been mostly focusing on the longform docs. I just wanted to make sure that I know where people are having problems, so I can know where to focus my efforts. Thanks.

Are there any ways the community can give back, and help work on the docs? A wiki maybe?

The docs are all in-tree. I love community contributed docs, that's how I got started :) Just like any GitHub project, just send us a pull request!

Docs are maintained here: https://github.com/rust-lang/rust/tree/master/src/doc

The book is in the "trpl" directory: https://github.com/rust-lang/rust/tree/master/src/doc/trpl

The standard library docs are maintained in doc comments in the appropriate places in the source: https://github.com/rust-lang/rust/tree/master/src/libstd

You can clone the repository, modify it locally, and build and test the docs (yes, the docs get tested, most of the code samples are actually executable tests), or you can just edit them online in GitHub's editor and send a pull request that way if you're just making documentation suggestions that won't need any tests.

I think the main problem with the docs right now is that most people looking at them aren't just new to the API, but also new to the lang - it can be quite hard to navigate them if you don't know much about the type system and how APIs may be composed using Rust's various facilities. That is obvious, I guess, but it doesn't stop people from trying.

Some way to conflate the two types of docs might be cool. For example, if there were high-level examples of commonly used API patterns in the std lib ("we use traits in this fashion here to achieve the following goals"), the docs could embed links to them as factoids ("this is an application of <this pattern>"). Heck, even just a ? button next to the "Traits" header linking to the book's Traits section would probably help some folks.

Linking to rust-guidelines in some way to back up the design of various APIs might be cool, too.

(Don't want to be the guy to crash Happy Day with more requests, so I'll just add: Many thanks for all your work, Rust has been tickling my brain in enjoyable ways like nothing else this year.)

Yeah, it's very true. Markdown is really weak in this area too, requiring us to a do a LOT of manual wor to link things up.

Oh, and rust-guidelines actually moved in tree: http://doc.rust-lang.org/stable/style/ They haven't yet been linked because of all the FIXMEs.

Thanks for the suggestions. :)

Just out of curiousity, why not use reStructuredText?

We had a long, hard think about it. We had a fairly significant amount of Markdown, the tooling was already written, and on a more personal note, I like the idea of reStructuredText, but I _hate_ writing it. If we'd have overwhelming reason to switch, we still would have, but basically, that's why: not enough reason to overcome momentum.

ASCIIDoc or something else might be nice too.

Steve, wouldn't it be good for the homepage of Rust to have a small news banner/sidebar, so people landing there would be presented with big news?

I do like the homepage for its simplicity, but no-one would know the significance without digging into the 'community' links. If that doesn't seem like an issue, then nevermind. Just a thought.

edit to explain: I'm at work and can't hop into IRC to chat about it.

There's a lot of stuff we'd like to do with the site, for sure. Always so much to do...

Do you deal with documentation on parts that have been moved out of std, too?

Some of the hardest parts of the documentation is the functionality hidden behind `impl SomeTrait for SomeStruct`. Eg. `impl PartialOrd for BTreeMap`. What on earth does that do? Or the fact you're meant to make a randomly seeded `ChaChaRng` with `OsRng::new().unwrap().gen()`, which is genius but impossible to guess.

In theory, yes, but I spend most of my time on what's most important, which is the stuff in-tree. I've even been neglecting Cargo, which could use a reorganizaiton at least.

Those implementations should absolutely be in the generated documentation, can you maybe point me to some specific pages? Thanks :)

The two maps with PartialOrd are

https://doc.rust-lang.org/collections/struct.BTreeMap.html

https://doc.rust-lang.org/collections/vec_map/struct.VecMap....

ChaChaRng is

http://doc.rust-lang.org/rand/rand/chacha/struct.ChaChaRng.h...

although the other implementations also need this. The main page for rand should probably have this somewhere on it, too.

Thanks for helping :).

Thanks. So, I'm not sure what _specifically_ the issue is here with PartialOrd. It has 'impl<K: PartialOrd, V: PartialOrd> PartialOrd for BTreeMap<K, V>', and if you click on PartialOrd, you go to https://doc.rust-lang.org/core/cmp/trait.PartialOrd.html, which has an explanation of what it does. Am I missing something?

ChaChaRng _does_ mention OsRng, but a code sample might help, for sure.

> I'm not sure what _specifically_ the issue is here with PartialOrd.

I know what a partial order is, I just don't know what partial order maps realize. In Python they aren't orderable.

> ChaChaRng _does_ mention OsRng

It says to use OsRng if cryptographic security is needed, not how to seed with it.

The obvious way is something like

    let osrng = OsRng::new().unwrap();
    let mut key = [0u32; 8];
    for word in key.iter_mut() {
        *word = osrng.gen();
    }
    let prng = ChaChaRng::from_seed(&key[..])

which is a pain.

Roger, I see what you're saying, on both counts.

Thank you for taking the time to spell it out to me.

Maps can be compared lexicographically. BTreeMap and VecMap have a canonical order in which they store their elements so

  iter::order::cmp(self.iter(), other.iter())

works as an ordering.

HashMap in Rust (dict in Python) doesn't have a canonical ordering of elements, so this doesn't make sense.

This has to be the fastest post to rise to #1 on HN I've ever seen!

The fastest I've seen was Steve Jobs passing away.

those were the fastest 20 posts.

Is there anywhere I can download a Rust tutorial in kindle format? I'd like to start learning Rust this weekend.

EDIT: To answer my own question: http://killercup.github.io/trpl-ebook/

Good news everyone! :) I really hope this language gets traction.

Great! I just downloaded and installed it, and my programs still worked!

No more "cargo clean; cargo update; cargo build; cargo test;" every day! At last.

install my `cargo-do` utility and it can be `cargo do clean, update, build, test` instead ;)

github.com/pwoolcoc/cargo-do

Let me begin by saying congratulations to the Rust team and supporting community. I've been following Rust when I realized it would make for a good language to try with robotic controls (due to all the safety stuff). Stupid question time: What does this release mean for the embedded / control systems community? Will you be recommending any specific boards / micros / libraries from now forward? If so, which?

The story for rust in embedded contexts is not quite finished. There are dozens of people writing kernels in rust, there's zinc for arm microcontrollers and I've seen projects for raspi and PSX, so stuff works. It's not great yet, though. Once the allocator api is added to the stdlib it'll be much easier to use the standard library in embedded contexts. There's probably other stuff I don't know about but I know for sure that this is a priority for the near future.

Thank you for the insight. I was not aware that the allocator api was not yet in the stdlib for embedded. I'll have to wait a little bit more then.

My current approach to the heap problem (I'm working on a toy Rust kernel) is to compile the allocator portions of the standard library (liballoc) with a configuration flag that makes them use a particular set of external functions as the low-level heap allocation machinery. Then, my kernel provides these functions, and all the nice stuff (Box, Vec, etc.) "just works".

IF you're curious, the relevant code is at https://github.com/krzysz00/rust-kernel/blob/master/kernel/m... . The functions that start with "rust_" are the allocator interface

Very interesting. Thank you for sharing. Would it be too much to ask for more?

I'm not sure what you're getting at. More of what?

Share more of experience with Rust. :)

That's much easier than I thought it was! I'll have to start working on my kernel again.

You can find some more {complex, idiomatic, not terribly hacked together} Rust kernels at https://github.com/thepowersgang/ .

Couldn't help but notice,

    F' as u8

is equivalent to

    b'F'

, and

    ['F' as u8, 'R' as u8, 'E' as u8, 'E' as u8]

is equivalent to

    *b"FREE"

which definitely is a lot more concise :). These are called byte string literals.

Edit: The dereference is necessary because b"FREE" on its own has the type &[u8; 4].

Very cool. Going to try to learn some basics this weekend! Exciting times watching (from a spectators points of view) the evolution of Rust to this point. Sounds like more exciting times ahead.

Congrats Rusties. I've just begun playing and it seems worth the time investment.

Rustacean* :)

Rustafarian

The community generally doesn't like that name, as it has awkward, appropriating connotations.

What, and Rustacean doesn't? When we Uplift our Cetacean friends, is this sort of awkward appropriation really how you want to meet the newly-conscious masters of 3/4s of the planet?

(Cough.)

As an ex-sorta/kinda-its-complicated-vegan, this comment makes me smile, for sure :)

The purist REST crowd also has used "RESTafarian" for years, and they're almost indistinguishable when spoken...

I parse 'Rustacean' as appropriating crustaceans, not cetaceans. I'm rather less worried about annoying them, because i eat enough prawn toast that i'm already on their shitlist.

Pretty cool name with good connotations (like Bob Marley's music).

Did any rastafarians complain about that name, or raise this concern?

On the other hand, I can't imagine there are many rastafarians lurking on tumblr.

Ferrous Oxides.

Ironborn!

Griswolds

Rustics.

It mentions the rust 1.1 beta, but doesn't link to it. Where is the list of changes in 1.1?

As per https://internals.rust-lang.org/t/release-channels-git-branc... , there's a branch: https://github.com/rust-lang/rust/tree/beta

I don't think we currently have a changelog or anything: we were mostly focusing on this new, stable branch this time around. You're right that making a changelog now would be super helpful, I'll add that to the list for next release. Thanks!

I always disliked - "let and let mut".

Personally - "val and var" are more intuitive.

The reason is that "let" takes a pattern, and mutability is an attribute of each pattern binding, not the let statement.

    let (mut a, b) = (..., ...); // a is mutable; b is not

Makes sense, but my brain fires wrong visual signals when I see "mut".

If the whole point is to name a memory address - mutable or immutable. Why not have a special name for the address itself ?

e.g: a = immutable, #a = mutable.

That would make refactoring painful I suppose and it's unlike anything in the language. In general the rust devs have tried to get rid of as many sigils as possible anyway so your proposal is very unlikely to gain traction.

I know, just a suggestion.

I should design an "uber-lang" to sit on top of JVM / CLR / LuaJIT / Rust ! :)

Your brain should fire wrong signals when you see mut. I think part of the design of mut is to discourage you from abusing mutable variables. (Personally, I prefer F# forcing you the type mutable).

I'm glad they didn't give it a special prefix because not only would it add unnecessary noise, it would make refactoring tedious. I'd rather give the compiler my intent once, and let it figure out if I violated my own intentions.

One thing I like in the F# toolset is the syntax highlighters will highlight mutable and reference variables different colors. It's a matter of time before Rust developers have that (If they don't already).

"Discouraging Mutability" with the added "mut" would be a positive way to look at it.

Thanks !

Why does a simple "Hello World" create a 578KB binary?

Is it packaging a lot of extras that aren't needed for such a simple program?

It statically links the entire standard library by default.

Hello world in C++ is 1.3 MiB when linked statically.

    $ cat helloworld.cpp 
    #include <iostream>

    int main()  {
    std::cout << "Hello world" << std::endl;
    }

    $ g++ -std=c++14 -Os -static helloworld.cpp 
    $ size a.out 
    text    data     bss     dec     hex filename
    1294232   29692   92936 1416860  159e9c a.out

The majority of this is bloat from GNU libc though, using diet libc would yield better results

    $ cat helloworld.c 
    #include <stdio.h>

    int main()  {
    puts ("Hello world");
    }
    $ gcc -std=c99 -Os -static helloworld.c 
    $ size a.out 
    text    data     bss     dec     hex filename
    725706    7572    9080  742358   b53d6 a.out

As I've pointed out in a previous thread, virtually all of it is from a) iostreams and b) glibc. If you don't statically link glibc (as is the case the vast majority of the time) it's much smaller.

Edit: You made my point for me in your edit :) Leaving my original comment for posterity.

It is possible, with a little manual hacking of the linker and some trickery with storing strings in ELF headers, to get Rust to produces 151-byte executable.

Yes, a simple "Hello World" winds up statically linking a fairly sizeable standard library, in particular anything dealing with strings has to involve a certain amount of UTF-8 manipulation and the formatting and I/O have a lot of features and thus likely fairly large code size. But for the most part that's just fixed overhead, and you can opt out of using the standard library if you want and produce smaller executables.

Rust does static linking by default, because it's more bulletproof and hard drives are cheap.

If you want tiny binaries using dynamic linking then you can use "rustc -C prefer-dynamic".

Thanks, that brings it down to 9.1KB which is much closer to what I'd expect.

I'm happy it does static linking by default because like you said hard drives are cheap and it's safer.

rustc -C prefer-dyanmic.

Congratulations to the team; it is nice to be around when a language is born. I remember when Ruby was born, and most people (that I knew) were like "Huh? Why Ruby, when we have Perl?".

I haven't followed Rust much, but as a total n00b: what are some practical reasons why one would choose to learn Rust? What features does this language have which others (pick: C, C++, D, etc.) don't have? What does it do better than the aforementioned languages? (Please don't take these as a challenge, but as a desire to learn more). Thanks!

> What features does this language have which others (pick: C, C++, D, etc.)

The shortest answer is 'memory safety without garbage collection.' C and C++ don't have 1, D doesn't have 2. D is working on 2, but then it won't have 1.

Secondary reasons: newer, better, more standard tooling, (in some cases, not others: IDE support, not nearly as good. Build system and sharing code? Way better.) Similar concepts in a more orthogonal package. Lack of legacy baggage. Easier (hopefully) for non-systems programmers to get into, as the compiler is there to help. It really depends.

Reasons those languages are better than Rust: adoption, ubiquity, more tutorials and a bigger community.

The introduction in book (linked in announcement) actually explains exactly this, very nicely.

It sounds like this:

Rust is a systems programming language focused on three goals: safety, speed, and concurrency. It maintains these goals without having a garbage collector, making it a useful language for a number of use cases other languages aren’t good at: embedding in other languages, programs with specific space and time requirements, and writing low-level code, like device drivers and operating systems. It improves on current languages targeting this space by having a number of compile-time safety checks that produce no runtime overhead, while eliminating all data races. Rust also aims to achieve ‘zero-cost abstractions’ even though some of these abstractions feel like those of a high-level language. Even then, Rust still allows precise control like a low-level language would.

Rust manages to fight neck-to-neck with C++ on speed and runtime overhead ("fast" and "effectively none") whilst giving both safety and some really nicely made abstractions.

The one everyone mentions is that Rust gets memory safety without garbage collection. But there are cooler things, like being able to implement units in the type system. Rust also gets safety right in the sense that its defaults are good - its primary random number library has ChaChaRng and IsaacRng instead of a Mersenne Twister, for example.

The sensible library design goes everywhere, from Rust's functional roots, high-quality zero-overhead iteration protocol (none of the mess that C++ gives you) to simple things like a well-designed composable hashing standard.

Even stuff like comparing C++'s move, copy and constructor semantics are much nicer in Rust, and in most cases even lower overhead: everything is a memcpy and is implemented automatically.

I can go on. Rust is one of the few languages that IMHO gets string handling right, and has good unicode support from the outset. It's easier to write error-proof filesystem code than any other language I've used. Threading isn't a mess.

There are disadvantages, such as Rust being one of the hardest languages to learn. Generics are both pervasive and difficult - they're clean unlike in C++ but they're also uncomfortably explicit. There are lots of nonlocal typesystem effects, largely due to the thirst for safety.

But it's a good language. Definitely one of the most exciting I've seen in a while.

> Generics are both pervasive and difficult - they're clean unlike in C++ but they're also uncomfortably explicit.

Maybe it's because I'm used to it, but do you have an example of why you think this? I think with type inference being pervasive, I've never been annoyed by generics. Additionally with type aliases a lot of pain can be avoided.

One of the ugly parts is that call-site type parameters, when given explicitly, have an ugly (but consistent) syntax. This is probably unfixable. Another annoying part is the lack of anonymous return types, which makes some types annoying to read or even impossible to express, but work is being done to improve this now.

Your second paragraph basically lists the difficulties. It's definitely a compromise.

Well, not really, I was just stretching my brain to think of criticisms you might have been alluding to. I still don't know what is overly explicit about Rust's generics.

Would you not call this uncomfortably explicit:

https://github.com/rust-lang/rfcs/pull/105#issuecomment-6410...

Type inference does make such things easy inside function bodies, but there are a lot of functions so it's not a complete solution.

Even some of the uncomposed iterator signatures are uncomfortable. An example:

    fn partition<B, F>(self, mut f: F) -> (B, B) where
        Self: Sized,
        B: Default + Extend<Self::Item>,
        F: FnMut(&Self::Item) -> bool

D gives you

    Range partition(alias predicate, SwapStrategy ss = SwapStrategy.unstable, Range)(Range r)
        if ((ss == SwapStrategy.stable && isRandomAccessRange!(Range))
                || (ss != SwapStrategy.stable && isForwardRange!(Range)))

which, if changed to only support stable partitions (like Rust), would be

    Range partition(alias predicate, Range)(Range r)
        if (isRandomAccessRange!(Range))

Note that I'm _not_ saying D's solution is better. I'm saying I find it more comfortable.

So it's lack of abstract return types. Thanks for clarifying.

> Another annoying part is the lack of anonymous return types, which makes some types annoying to read or even impossible to express

Out of curiosity, impossible to express how? Can't one just store the return value in a variable, investigate its type, then copy-paste that as the function return type?

"Annoying to read" can be solved with typedefs, but there are types impossible to express.

At the moment I think closures are impossible to express as named types.

Aside from many of the other common reasons, Rust is a fun language to code in (once you understand it well). The language design has learned a lot from other languages, and the tooling has been influenced by many other successful ecosystems (npm as a big example) and trendy workflows (the community seems a bit centered around github, which works for me).

A few examples just off the top of my head: the language doesn't hide performance tradeoffs, namespacing makes sense, "zero-cost abstractions" are beautiful and common through the ecosystem, cargo is a wonderful tool for building, creating docs, testing, etc. I've had a lot of fun using Rust to build things I really didn't need it for.

Congrats! Thanks to all who worked on it!

A real game changer although I wonder if there's still some minor breaking changes I'd like to see

Consider how nice it would be is if when you matched (a,a,a) it checked to make sure they were equal. Probably can't do that for (_,_,_)

It's a breaking change, but who would mind?

Well, do you mean equality by value or by memory location?

I also hope they are not too conservative in the beginning, because we might have to pay for mistakes for a long time.

Yea perhaps it's just not as easy as haskell. But I was trying to make the meta point that not breaking compatibility between releases can be a bit subjective.

Even if equality was by memory location in the case where the tuple contains pointers, one would still have to work out how equality would work for tuples of non-pointer types. For example, would (NaN, NaN) match (A, A)? If the implementation makes use of ==, then it wouldn't, and if it uses bitwise equality it would.

It's not a breaking change.

Why would that be a breaking change?

Congratulations to everyone on the team!

I think the release of the first stable version is an appropriate time to ask how the collaboration with packaging teams from major distributions is going.

Can you give us some information on that?

There is a Rust package in Arch Linux's community repo, but it's still on the beta version, and there is no cargo package yet.

Rust is nice, but… Why can't anybody made a language with the exact syntax of Python, but compiled? It doesn't need extreme safety features or other buzzwords.

It's ridiculous of them to downvote you instead of providing an honest answer. This is a good question that I think a lot of Python fans might wonder about.

One of the many great things about Python (and other "dynamic" languages) is how flexible it is in so many ways. Instead of forcing you to be more explicit, make more decisions, and lock more things down in advance, it lets you get away with telling it to figure out a lot of things for itself while the program is running.

This kind of flexibility isn't free. It does a lot of things indirectly, it makes decisions for you and, if they turn out to need changing, it makes those changes as, and so on, while it is running, which requires a lot of computation.

You actually could compile Python, but keeping the "exact syntax" presumably means keeping all of Python's capabilities to be flexible at runtime, so compiling would require essentially building a lot of the Python interpreter right into your compiled app. This, in itself, would just change the packaging and wouldn't buy you much in terms of performance. A lot of clever people are looking for ways to speed up Python without removing features, but it will probably never be possible to make Python as fast as Rust will eventually be, nor to make Rust as convenient as Python.

Have you looked at Nim, perhaps? I haven't used it, but at first glance it certainly seems more Pythonic than Rust.

You might be pleasantly surprised to learn that python by default caches the parsing results between runs. If it makes you feel better, you can think of it as ~partially compiled :) But there is an inherent trade-off between having a lot of flexibility at runtime, and having aggressive code specialization and optimization at compile time. Well, I suppose you could combine those into one language, but you couldn't do both on the same piece of code...

Because syntax isn't that big of a deal to most people, I guess. They are more concerned with actually useful things, like safety features and other buzzwords. ;)

But like mentioned, there is Nim. Which at least have the indentation-thing going for it.

I'm on a Late 2013 Retina MacBook Pro, running 10.10.3, with the latest stable toolchain. It would not compile.

http://pastebin.com/bifK665u

I set --prefix=/usr --enable-debug

No dice. I also tried to build from source in a VM on that same machine. 32-bit Ubuntu 14.04.2 (3GB of RAM), latest stable toolchain. Again, didn't compile. Core dump.

That is strange; I bootstrap regularly with `--enable-debug` and have not seen an arithmetic overflow during bootstrap (at least, not for a long time).

It would probably be best to carry on a conversation on a formal bug report; did you file one at the url it listed?

Any IDE support for Rust ?

Vim + rust.vim works pretty well ;)

There's also Racer[1] (semantic completion engine), and it sounds like Valloric is open to making it work with YouCompleteMe [2].

[1] https://github.com/phildawes/racer [2] https://github.com/Valloric/YouCompleteMe/issues/1297

https://visualstudiogallery.msdn.microsoft.com/c6075d2f-8864...

Emacs has a rust-mode IIRC.

Pair it with racer for auto completion https://github.com/phildawes/racer

Hi! You are in luck! Today, this was posted: http://blog.piston.rs/2015/05/14/Visual-Rust-0.1/

Windows only?

It's a Visual Studio plugin. Not really a Rust IDE.

No shit. Visual Studio is Windows only.

Vusual Studio Code runs on Linux and Mac.

It's also completely unrelated in all but name, and thus doesn't run Visual Studio plugins.

Visual Studio Code really has nothing to do with Visual Studio except that they share part of a name.

Unfortunately, yes :/. Why don't you take a look at this? https://github.com/oakes/SolidOak

I haven't given it a try, but it looks as it provides basic functionality. Since Rust is such a young language, I don't really expect much until at least a few months have passed. We will probably start seeing plugins for Eclipse and other big IDEs in some time.

In addition to the other answers, there is also RustDT https://rustdt.github.io/ if you like using Eclipse, and SolidOak https://sekao.net/solidoak/ .

Sublime Text 3 has a plugin: https://packagecontrol.io/packages/Rust

I've been using Subblime + https://github.com/jhasse/sublime-rust

I was looking to see what UI and database bindings were available as crates and came across the crates.io web site.

It would be useful for people new to Rust to see what existing libraries are available and one way would be to have a link on the www.rust-lang.org site's font page pointing to crates.io site.

Also see: https://github.com/kud1ing/awesome-rust

Would it be possible to achieve near-Rustiness with modern C++14 and tons of warnings/errors enabled?

Mozilla has several million lines of C++ code. Do you think they would invest substantially in creating an entirely new language with a new ecosystem and from-scratch Servo rewrite if their C++ code could be made secure with C++14 and tons of warnings?

Is that a no?

Very exciting! I've worked through the tutorial in the past and enjoyed Rust very much but since then have just been passively following progress on HN. Looking forward to actually building something with it now.

Congratulations to everyone involved!! Exciting times!

Congrats!

\o/

Congrats! This is awesome. Been waiting for 1.0 to really start digging into Rust. Now's the time :)

Just today I looked at beta release , congratulations and looking forward to using Rust

Can somebody explain for what kind of use cases would this be helpful to use?

Any time 'it matters'.

There's lots of stuff that we build, and we say things like, "Language X is slow, but it doesn't matter." "Language Y uses a lot of memory, but it doesn't matter." This is very, very often true. But every once in a while, it really matters.

That's when you want something like Rust. When the details are important. When you need full control, but you'd like a compiler to help catch your mistakes. When a garbage collector has too much overhead. When you need to write something inside of Language X or Y, instead of a C extension, you can use Rust.

Basically, anywhere you'd use C or C++, Rust is a great fit. Elsewhere? Maybe, maybe not. Depends.

> When you need to write something inside of Language X or Y, instead of a C extension, you can use Rust.

Are there any examples/discussion/information for interacting with rust from python, like you would a C extension?

I devoted a whole chapter of the book to Ruby/Python/node embedding: http://doc.rust-lang.org/book/rust-inside-other-languages.ht...

A Ruby gem in Rust was one of our earliest production uses.

There's a wonderful presentation on this topic: https://www.youtube.com/watch?v=3CwJ0MH-4MA

    Rust is a systems programming language that runs blazingly fast,
    prevents nearly all segfaults, and guarantees thread safety.[1]

So, if you care for low memory usage, execution speed or safety guarantees especially for hard-to-debug kind of errors, then Rust might be interesting for you.

It offers low-level access like C or C++ but excels with vastly improved security. So, I'd take that step, and say that where C or C++ is used right now, you might want to use Rust in the future.

[1] http://www.rust-lang.org/

It's as 'blazingly fast' as Java:

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

or go:

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

Here's what it's not as 'blazingly fast' as:

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

We haven't paid any attention to those benchmarks in a long time. When we did, we even beat C and C++ sometimes.

Are you paying attention to some other benchmarks that you could share when responding to these questions?

Just trying to dismiss measurements that are publically available, without putting forward something you consider better, is kind-of…

No, as optimizing performance hasn't been a focus, shipping good language semantics has been.

Humbly suggest the "optimizing performance hasn't been a focus, shipping good language semantics has been" message needs to be repeated louder and clearer.

The expectation that has been created is - "Rust is a systems programming language that runs blazingly fast" - and that may lead to disappointment.

Just because there may have been a regression on a particular benchmark doesn't mean that Rust is not generally fast.

imo it would be helpful to you all, to set a clear expectation that performance will be a priority in some future version but has not been so far. (As that's what you seem to have just said.)

That's all. No reference to "a particular benchmark", or whatever you take "generally fast" to mean.

http://www.areweblazingfastyet.org is free - you'd better grab it before I do :). If you don't take it, I'll just make it return those pieces of the language shootout.

Give it some time to mature. Today is the day of the language specification, not the finalization of the toolchain.

The Rust language offers low-level access with amazing security guarantees, and is working on an optimizing toolchain.

Let me take Python as a comparison. It has fundamental[1] roadblocks for being fast on current and probably future hardware, because its dynamic nature requires many indirections which are problematic for CPU cache efficiency.

Will Rust always be faster than C? Probably not, but that is not needed to be blazingly fast. What is important is that there are no fundamental difficulties to be as fast as C.

[1] I know, you can work around some of those indirections.

> Will Rust always be faster than C?

(By 'always' did you mean 'ever'?)

That may be so, but their advertising gives the wrong impression. They should keep their claims muted until they can back them up.

If you consider that robust and memory efficient parallelization is way more easily achieved in Rust than in C, Rust might already win today for some applications if you limit the developer time. In C it's hard to fulfill the requirements at all.

Anyone succesfull getting any glfw stuff on windows to build dependebly yet?

Super!

Great job. I look forward to coding something over the weekend!

Congratulations to the Rust team. I have been waiting for this.

+1, Congratulations Rust Team :)

Congratulations!

Awesome!

cheers LOL

Reply on news.ycombinator.com