
Announcing Rust 1.0 - jhund
http://blog.rust-lang.org/2015/05/15/Rust-1.0.html
======
kibwen
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. :)

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

~~~
madez
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](https://news.ycombinator.com/item?id=9552468)

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

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

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

------
azdle
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...](https://github.com/Azdle/hello-
gtk.rs/blob/master/src/main.rs)

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.

~~~
lmm
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".

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

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

------
przemoc
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](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.

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

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

~~~
steveklabnik
There is actually preliminary support: [https://github.com/rust-
lang/rust/pull/24777](https://github.com/rust-lang/rust/pull/24777)

Making this work well is a very high priority.

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

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

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

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

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

------
Arnor
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](https://www.youtube.com/watch?v=iSmkqocn0oQ)

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

~~~
burntsushi
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

------
apaprocki
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/](http://codecon.bloomberg.com/)

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

~~~
apaprocki
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](http://codecon.bloomberg.com/2015-finals)

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

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

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

~~~
mahyarm
But how does it compare to go in this case?

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

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

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

~~~
Veedrac
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](https://github.com/rust-
lang/rfcs/issues/811).

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

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

In this case, I think the term is justified.

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

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

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

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

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

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

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

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

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

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

~~~
steveklabnik
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/](http://doc.rust-lang.org/stable/style/) They haven't
yet been linked because of all the FIXMEs.

Thanks for the suggestions. :)

~~~
ngoldbaum
Just out of curiousity, why not use reStructuredText?

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

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

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

~~~
baq
those were the fastest 20 posts.

------
hillsarealiv3
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/](http://killercup.github.io/trpl-ebook/)

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

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

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

github.com/pwoolcoc/cargo-do

------
bliti
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?

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

~~~
krzysz00
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...](https://github.com/krzysz00/rust-
kernel/blob/master/kernel/malloc.rs) . The functions that start with "rust_"
are the allocator interface

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

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

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

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

~~~
wldcordeiro
Rustacean* :)

~~~
dman
Rustafarian

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

~~~
jerf
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_.)

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

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

~~~
steveklabnik
As per [https://internals.rust-lang.org/t/release-channels-git-
branc...](https://internals.rust-lang.org/t/release-channels-git-branching-
and-the-release-process/1940) , there's a branch: [https://github.com/rust-
lang/rust/tree/beta](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!

------
crudbug
I always disliked - "let and let mut".

Personally - "val and var" are more intuitive.

~~~
pcwalton
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

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

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

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

Thanks !

------
aembleton
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?

~~~
nly
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

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

------
discardorama
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!

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

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

~~~
azth
> 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?

~~~
Manishearth
"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.

------
EugeneOZ
Congrats! Thanks to all who worked on it!

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

~~~
alexnewman
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?

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

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

------
pjmlp
Congratulations to everyone on the team!

------
madez
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?

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

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

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

------
akulbe
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](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.

~~~
pnkfelix
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?

------
mariusmg
Any IDE support for Rust ?

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

~~~
hillsarealiv3
Windows only?

~~~
GarryManson
No shit. Visual Studio is Windows only.

~~~
hillsarealiv3
Vusual Studio Code runs on Linux and Mac.

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

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

~~~
ewillbefull
Also see: [https://github.com/kud1ing/awesome-
rust](https://github.com/kud1ing/awesome-rust)

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

~~~
the_why_of_y
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?

~~~
gtirloni
Is that a no?

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

------
GolDDranks
Congratulations to everyone involved!! Exciting times!

------
rjammala
Congrats!

------
alfiedotwtf
\o/

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

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

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

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

~~~
robertfw
> 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?

~~~
steveklabnik
I devoted a whole chapter of the book to Ruby/Python/node embedding:
[http://doc.rust-lang.org/book/rust-inside-other-
languages.ht...](http://doc.rust-lang.org/book/rust-inside-other-
languages.html)

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

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

------
cyber1
Super!

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

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

------
cjdrake
+1, Congratulations Rust Team :)

------
shmerl
Congratulations!

------
jedisct1
Awesome!

------
outqin
cheers LOL

