
Announcing Rust 1.0 Alpha - steveklabnik
http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html
======
kibwen
Congrats to everyone involved (and there sure are a lot of you)!

The TL;DR of the alpha is basically this:

1\. The concept of a six-week release cycle begins today, with the first beta
coming in March.

2\. Breaking changes will basically cease, with the exception of a list of
libraries that are still unstable and features that may be tweaked
([https://github.com/rust-lang/rust/wiki/Anticipated-
breaking-...](https://github.com/rust-lang/rust/wiki/Anticipated-breaking-
changes-during-1.0-alpha)).

3\. Given the aforementioned degree of remaining instability, users should
still probably stick to the nightly releases in order to help keep their code
up to date and weed out bugs in the compiler.

As ever, it deserves to be reiterated that the 1.0 release does _not_
represent the language being "finished" in any way, only that things will stop
breaking. The language will continue evolving rapidly after 1.0, and even the
1.0 release will contain several known (and sometimes rather unfortunate)
restrictions that will be backwards-compatibly lifted over time.

Post-1.0, I expect there to be a large community outreach to determine which
work to prioritize (for example, I foresee a great clamor for making macros
more usable). With developer help I intend to publish a blog post before then
detailing exactly which deficiencies Rust 1.0 will contain, and the use cases
that they currently either prevent or make awkward.

~~~
Animats
Finally! I hadn't used Rust for two weeks, and when I downloaded the nightly
last night, code from two weeks ago was breaking. Feature stability will help.

~~~
eterm
Yes, this is a big deal. I tried looking into Rust a couple of months ago, but
the speed of change meant that blog posts and tutorials from just weeks before
were sometimes completely broken.

Getting to 1.0 means that the ecosystem has a chance to grow properly which
means "lesser" coders such as myself have a chance to learn and get involved.

~~~
jacquesm
Tutorials should at a minimum be dated and if possible include the version of
rust used when making the tutorial.

~~~
eterm
And most are dated and versioned, but a changing API still meant that the
corpus was not expanding and knowledge was being lost. Tutorials got out of
date so quickly it was hard to get a foothold when trying to learn.

The evolution is important and I don't want to seem like I'm saying it
shouldn't have been done the way it was, it was very well managed from what I
saw from keeping an eye on the project. I am just happy that it will now be
stable letting the ecosystem grow and feed off itself.

------
iamdanfox
Coincidentally, I used Rust for a little board game solver this week and have
been delighted by its performance and typechecker feedback!

My Scala v1 was was very concise but took ~3 seconds to simulate a whole game.
The naive Rust rewrite did it in 0.7 seconds and my current version churns
them out at 0.015s each!!

[http://github.com/iamdanfox/qwirkler](http://github.com/iamdanfox/qwirkler)
if you're curious.. This language is really fun!

~~~
kibwen
Performance is an area where Rust still has a lot of low-hanging fruit to
pick, so I'm happy to hear that you managed to make your version fast. Did you
have to make any design compromises to that end? We're very interested in
optimizing the typical use cases.

~~~
iamdanfox
I have currently got some bit-swizzling [1] going on to fit the concept of a
Piece into u8. (one of 6 colours and one of 6 shapes). I'd like to turn this
back into a nice enum if I can!

Introducing laziness by writing an iterator was actually one of the biggest
single improvements (I couldn't figure out the syntax for a while, but
lifetimes worked much better than I was expecting)!

[1]:
[https://github.com/iamdanfox/qwirkler/blob/master/src/piece....](https://github.com/iamdanfox/qwirkler/blob/master/src/piece.rs)

~~~
nightpool
FYI both kaoD and Kibwen's post seem to be dead because they included a link
to a URL shortener (seems a little melodramatic on HNs part...) so I'll
reproduce it here w/o the URL shortlink and see if that helps

>Hm, an enum like `enum Color { R, O, Y, G, B, I, V }` is represented by a u8
at runtime (see for yourself here[1]), which means that you're only saving a
single byte in your `Piece` struct by doing that manual optimization. What was
the magnitude of the speedup that you saw?

[1]: [http://play.rust-
lang.org/?code=%23%5Ballow(dead_code)%5D%0A...](http://play.rust-
lang.org/?code=%23%5Ballow\(dead_code\)%5D%0Aenum%20Color%20%7B%20R%2C%20O%2C%20Y%2C%20G%2C%20B%2C%20I%2C%20V%20%7D%0A%0Afn%20main\(\)%20%7B%0A%20%20%20%20println!\(%22%7B%7D%22%2C%20std%3A%3Amem%3A%3Asize_of%3A%3A%3CColor%3E\(\)\)%3B%20%20%2F%2F%20size%20in%20bytes%0A%7D)

~~~
iamdanfox
Ah that's good to know, looks like I should switch it back! The manual u8
stuff was pretty marginal. (It was also before I discovered the `PartialEq`
and `Copy` traits, so please forgive my Rust inexperience!)

------
gnuvince
Wow. Anyone remembers Rust pre-0.1? When it had typestate, ML syntax, garbage
collection, etc.? So nice to see how the language slowly evolved and was
molded to fit as best as possible the problem they were trying to solve.

~~~
listic
> the language slowly evolved and was molded to fit as best as possible the
> problem they were trying to solve.

Which is...? Wikipedia says [1]

> "to be a good language for the creation of large client and server programs
> that run over the Internet"

and that looks too vague to me.

[1]
[http://en.wikipedia.org/wiki/Rust_%28programming_language%29...](http://en.wikipedia.org/wiki/Rust_%28programming_language%29#cite_note-
infoq2012-19)

~~~
steveklabnik
Memory safety without garbage collection.

------
eslaught
I've been incredibly impressed by the willingness of the Rust team to take a
step back and re-evaluate old decisions. I think this 1.0 release will be much
better for all the iterations put into e.g. dynamically sized types and other
things that never quite fit in their first half-dozen iterations of the
design. Congrats all!

~~~
steveklabnik
Thank you. Personally, I try to have strong opinions, weakly held. :)

~~~
nickik
> strong opinions, weakly held.

I like that, its mine now.

~~~
ricardobeat
[http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinio...](http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinions.html)

------
TylerE
The one thing that would put rust over the top right now is something along
the lines of gofmt - something simple, with zero configuration, that can be
run on commit or even save.

~~~
__david__
Ugh. I hate gofmt. It's a good idea in principle, but even with "go" there are
times when you want things spaced out to align columns, or hide a distracting
error handling case on one line (instead of making it take 3 lines of precious
vertical screen real estate).

I find gofmt to be too opinionated about certain things and I will never use
it for my go programs.

~~~
ptx
Why is it a good idea in principle then? Automatic reformatting of the source
code always seemed like a bad idea to me for precisely the sort of reason you
describe.

~~~
mhd
It's good enough when you can configure it and apply it selectively. If I want
to clean up a function in my code base, I can e.g. select it and run
"perltidy" over it, which has a configuration dot file for the company code
standard (or CPAN guidelines etc.).

Or just clean up some nags so that version control behaves better. But if the
only option is not running it at all or having all the code automatically fit
to whatever the people On High have deemed to be visually pleasing? Yeah...

~~~
flogic
It's irksome when the auto formatter does something ugly. Though, I think the
issue is far worse with Perl tidy. With, gofmt my view is more "I don't like
this bit but fuck it." Probably because, Go has much simpler syntax.

~~~
mhd
Both languages (being bastard children of C) often run into exactly the same
problems, where the syntax doesn't differ greatly. If you e.g. are accustomed
to having indentation without tabs, margins within function calls or prefer
non-tabular variable declarations, you can have that in C, Perl, Pike, Java,
etc..

------
jfaucett
I feel like this is the moment that so many devs who have observed rust over
the past couple of years have been waiting for. I for one am looking forward
to diving in.

------
vruiz
> The core libraries are feature-complete for 1.0.

Can someone well informed about Rust give some impressions on the standard
library? It is as comprehensive as in python or Go for example?

~~~
steveklabnik
Core team member here.

The standard library is _not_ "batteries included," on purpose. Given that we
have Cargo, and it works well, tying package updates to the language version
has quite a bit of downside, and very little upside.

That said, the Rust team itself maintains and provides a number of packages on
Crates.io ourselves. Many of these were pulled _out_ of the standard library
over the past few months.

~~~
kibwen
The upside to a batteries-included stdlib is, of course, that you _don 't_
have to go fishing around for the best lib to do $WHATEVER_PARTICULAR_TASK,
and you also don't have to wonder whether whatever lib you eventually choose
will be abandoned by its developer next month.

At such a young stage of language development, I agree that it makes more
sense to let the community develop libraries in order to foster competition
and quality. But eventually (read: no less than a year or two from now) I
think it will be up to the project maintainers to officially endorse certain
third-party packages and commit to their maintenance. At a certain point, the
advantages of a library that's well-known, well-maintained, and well-
documented outweigh the disadvantages of de jure ossification.

~~~
steveklabnik
It's been my experience that the standard library is _never_ the place for the
best lib to do $WHATEVER_PARTICULAR_TASK, but different folks have different
preferences. We'll see how it all shakes out!

~~~
binarycrusader
I think Python and Go are two examples where the standard library has very
much proven invaluable.

Without it, it's difficult to be confident in the portability of components,
and it quite frankly makes the language less attractive for use.

Like the other poster mentioned, I'm happy for the RUST folks to take a "wait-
and-see" approach, but at some point, I believe "blessed" components are going
to be expected and strongly desired.

~~~
Ao7bei3s
Python is a prime example of a rotten standard library.

Take urllib/urllib2 (use requests instead), unittest (use py.test or nose), os
(too low-level, hence arcane usage) or time as examples (use pytz for anything
serious), and of course Tkinter.

Take all of the modules that solve minor/niche tasks that could easily have
been put in a seperate library (e.g. wave), that are usually a bad idea to use
(e.g. pickle), that contain some copy/pasteable functions the authors deemed
useful _as comments_ (itertools), have documented bugs with copy/pasteable
workarounds (csv).

Oh, and the way they do exceptions is a mess.

Oh, and don't try to read the Python standard libraries source code. It's
ugly.

No, standard libraries should constrain themselves to providing a good
foundation for library designers.

(I still like Python, and use it a lot.)

(Since you mentioned Go. One thing that I love about Go is that everything
interaction with the underlying OS goes through the syscall package. Also,
their designer went for more minimalism. And they didn't have to worry about
design mistakes they made 25 years ago. Python _is_ old. I'm not a fan of Gos
compatibility promise: it means Go 1 will rot away too. But they're in a much
better starting position.)

~~~
apendleton
It all depends what you're using it for. If I'm writing code that's going to
be around awhile and can tolerate some dependencies, I'll totally use, say,
requests. But I use urllib2 from the repl _all the time,_ especially if I'm on
a machine that isn't mine. The fact that any Mac already has the tools on it
to grab some JSON from an API, parse it, and do something useful with it from
the command line, without having to download or install anything, is immensely
useful, even if the API is a bit suboptimal. The same applies to quick and
dirty things I'm shoving into a Gist to share with colleagues. Not all things
have to be elegant to be useful.

(That said, those kinds of usecases aren't really in Rust's wheelhouse, so I
still think in Rust's case having batteries not included is probably the right
call.)

~~~
natrius
It's possible to achieve the best of both worlds. We could introduce the
concept of a standard distribution instead of a standard library. A release of
Python should ship with specific versions of requests, nose, and other
packages that have a broad community consensus. Those packages could be
individually upgraded later, but every install of Python 2.7.9, for instance,
would have requests 2.5.1 or greater installed. That would avoid the
stagnation packages see when they enter the standard library, and would
maintain the benefits of universal availability.

Every language ecosystem should work this way.

------
snake_case
Being a game developer, inheritance is a really important language feature.
I'm not one to abuse the power. Currently, for school I've been working on an
OpenGL game engine in C++. It's a component based system. The only real
inheritance situation that's important to me, is to allow the user of the
engine to create any object and make it inherit from GameObject (example: Duck
would inherit the members and methods from the GameObject class). Everything
else is a component that plugs into GameObjects (Mesh component, Transform
component, etc.)

Over Christmas break, I played around with Rust and I'm really enjoying it.
However, I can't figure out a nice way to inherit members from other structs.
My current idea, like many others, is to keep a pointer to a "parent" object.
So, Duck would have a GameObject, rather than be a GameObject.

Does anyone have any recommendations for better ways I can achieve what I
would like to do? I will also accept the fact that inheritance is _not_ needed
in a language, but it does make a few situations easier.

~~~
yoklov
I'm a game developer and I don't use inheritance a lot, and when I do use it
it's almost never for virtual dispatch. (I wouldn't mind it being added to
Rust, but I don't expect I would use it).

Anyway, if you're already doing a component based system, why do you need
inheritance? Just do a normal ECS. You don't subclass GameObjects in most
implementations of ECS (and this is a good thing).

~~~
snake_case
I guess I should do some more research regarding that. Although, I just liked
the idea of inheriting from a base "empty" game object. It makes it easy to
have lists of GameObjects. Also, all of my components inherit from a Component
class which makes it possible to AddComponent() and GetComponent(). That way,
a user of the game engine could create a new type of component and easily add
that to any game object. However, I may be over complicating that as well...

~~~
yoklov
Honestly, it sounds like you are over-engineering this... Forgive me if I'm
wrong, but the impression I'm getting here is that you're writing the engine
before the game.

Never do this. Just don't. What you should do instead, is write a game, and
while writing that game, write its engine. At the same time (Or even, write a
game, and then refactor the engine out as you go).

Then, after you're done, that engine can then be extracted and made to be more
generic. This is basically how every engine used in the game industry was made
(although in many cases the game the engine was written with never shipped).

Trying to make a generic engine from the start will be worse in basically
every measurable way. It will take longer to write, take more code, use more
memory, and be slower...

Again, sorry if I misjudged your comments. Anyway. On to what you said
specifically:

Having an empty base object so you can have lists of GameObject (presumably
lists of `GameObject*` in reality) is basically going to destroy performance
and the cache. A reasonable rule of thumb is that a read from memory will take
about 100 times longer than, say, a float multiplication, unless you know it
will be in the cache. Then, to operate on these game objects, you'll probably
use virtual methods. Another rule of thumb is that vtables are basically never
in the cache (and they're also unpredictable branches).

Really what you want to have is several flat arrays of the data each part of
the engine needs to operate on. This is also good from an encapsulation
standpoint, because then each part of the engine only can see what it needs,
and not necessarily the whole game object. Then, the way you'd implement a
component system in this style is that you'd make that array the canonical
place the data lives.

This can work well for some games but isn't worthwhile for every game.
(Generally I actually think the biggest benefit is that it makes gameplay and
tools for non-developers easier to write.)

~~~
snake_case
> Forgive me if I'm wrong, but the impression I'm getting here is that you're
> writing the engine before the game.

Your impression is a little wrong, see below.

> Never do this. Just don't. What you should do instead, is write a game, and
> while writing that game, write its engine.

I'm not making a game. We have an OpenGL Game Engine class in my Game
Programming program at college. I'm creating my game engine with the idea that
someone could simply include it as a library and then use its features to
develop a game. This Game Engine class is now over, however, I'm still
developing my engine purely for personal learning purposes. Yes, I am creating
demos to test features of my engine, but I'm not writing anything that would
be considered a game.

Regarding the rest of your comment, I totally agree and understand what you
are saying. This actually makes sense, however, it's just not the way that
we've been taught so far in my program. Being a student, we are familiar with
the practices that our teachers use. This makes us somewhat close minded, but
it's really nice when people (like you) give a completely different way of
doing something.

Thanks for the help! I'll look into these different methods of structuring my
engine.

~~~
yoklov
Examples != a game, and given that scenario, I would recommend trying to make
a game at this point, but I'll leave it be.

And that's fair. I didn't think this way until after working in industry for a
while, and my code from when I was at school was very high level and OO.

If you're interested, Mike Acton (lead at insomniac, and one of the smartest
people in the industry) had a good talk in CPPcon that you can find online
about Data Driven design[0], which is basically what I'm talking about (he's a
bit more extreme than I am). I'd also recommend looking at his 'Typical C++
Bullshit' slides[1] for a shorter and more amusing take on the issue.

[0]: [http://youtu.be/rX0ItVEVjHc](http://youtu.be/rX0ItVEVjHc)

[1]:
[http://macton.smugmug.com/gallery/8936708_T6zQX#/gallery/893...](http://macton.smugmug.com/gallery/8936708_T6zQX#/gallery/8936708_T6zQX/593426709_ZX4pZ)

~~~
snake_case
I guess I should mention... I did write a maze game for a final project in a
different class with it. This semester, I was one of the few that actually
_wanted_ to work hard on my engine. I just find it really fun because there's
so many problems you have to think about when developing an engine, and even
more solutions. It's very rewarding for the brain.

This semester, I used an app to keep track of how much time I put into every
class.

\- game engine: 106 hrs

\- AI: 10 hrs

\- physics: 10 hrs

\- ogre: 12 hrs

As you can tell, my game engine was the thing I worked nearly every day on,
mostly late at night. If I took an assumption about my class average on hours
put into their game engines, I'd say a safe guess is around 15 hours if we
don't include my time and the 2 others who also put an insane amount of time
into their engines (it was pretty much a competition between 3 friends to
outdo each other).

Back to making my maze game... We had the entire semester to work on either a
solar system or a maze game. I pumped out the maze game in 3 hours with my
engine on the day it was due. The thing is, I was confident with my engine. I
put so much work into it, and I understand how it worked under the hood, that
I knew I could produce something very fast and easily with it.

The game itself was simple. Have a first-person camera walk around the maze,
pick up a key, and then go to the maze exit and open the door. Even though I
did it in 3 hours, I also included the ability to pick up a gun, attach it to
the camera like an FPS; added a skybox; added a simple sin wave twirl for
objects sitting on the ground; and a few other small details here and there.

Anyways, sorry I went on for a little bit there. I'm just really happy with
how much my engine is progressing, but it still needs a lot of work and
polish. I'm way more open minded now after this discussion. I feel confident
about not needing inhetitance now, especially since I feel like in a couple
months I might port everything to Rust.

I also realize that it was very risky leaving that project until the last
minute. If I ran into an issue, it could have severely messed up my mark.
Making a game at the same time as an engine does indeed help with the engine
development, I see the benefits of doing so. When I get a chance to continue
working on it, I will probably continue developing the maze game along side
it.

Anyways, thanks for those links, I'll be checking them out tonight!

------
speg
Stupid question, but how can a web developer relate to Rust? I had to look up
'systems programming' and Wikipedia basically told me it is writing software
for certain hardware components.

Will I ever be writing a web application in Rust?

~~~
gchp
My background is primarily web development, however I've been writing a text
editor in rust for a few months now. Prior to that, I had never written any
software outside of the web.

Honestly, its not such a big change once you get into it. I'd encourage you to
just give it a go, build something just for fun with it. Be it a command line
tool, game, whatever. My experience has shown me that just because you've only
been involved in web development, by no means limits you from systems/low
level development!

~~~
MrBra
To me it's more like s/he asked if they could build web apps with it, not
about their chance to like it considering they come from web apps.

------
jnbiche
Congrats to the Rust team on all their hard work paying off.

Looking forward to watching Rust expand into almost every corner of the
development world: web, applications, systems, embedded, safety-critical,
games, hard real-time, on so on!

------
im2w1l
Great news! Have been waiting for 1.0 to jump into rust. Anyone knows when the
final 1.0 will come?

~~~
steveklabnik
TL;DR: twelve to eighteen weeks. Possibly more six-week increments after that,
depending on how we feel during beta. Full details: [http://blog.rust-
lang.org/2014/12/12/1.0-Timeline.html](http://blog.rust-
lang.org/2014/12/12/1.0-Timeline.html)

~~~
slowmovintarget
Congratulations! I look forward to seeing the ecosystem expand now that core
has solidified. Very exciting.

------
JeremyMorgan
Well here we are. I think this is what a lot of folks were looking for,
anything before Alpha just seems too bleeding edge. Will be interesting to see
what the next year holds for this language.

------
valarauca1
Congratulations to the rust team. I've been having fun for a while in the
language can't wait to start developing serious tools now that we have a
stable release :)

------
listic
Is the Book up-to-date? [http://doc.rust-
lang.org/1.0.0-alpha/book/](http://doc.rust-lang.org/1.0.0-alpha/book/)

~~~
tshepang
most of the stuff; there are some notes when stuff is outdated

------
tete
Pretty nice! I mostly used Rust Nightly till now. The language, the ecosystem,
etc. seems really mature now. I've been following language development for a
while now. I've never seen something that is really a _new_ language and is
that far before 1.0 or in such a short time.

The language developed rapidly, without sacrificing reinventing things,
changing opinions a lot. I am not sure how they did that, but it's really
impressive. Usually languages lack documentation, stability, performance,
etc., have lots of rough edges, no users or libraries, but none of that is
true for Rust.

I am really curious about how this was achieved. Maybe someone involved could
describe how that was possible. I am sure I'm not the only one interested in
this.

A year ago there was an article about using Rust for an undergraduate class on
operating system development. Rust was 0.7 back then and _very_ different and
way more mature.

[https://news.ycombinator.com/item?id=7009414](https://news.ycombinator.com/item?id=7009414)

~~~
M2Ys4U
I'm sure that developing a large application (Servo) in parallel with the
language helped quite a bit.

~~~
nightpool
To be fair, rustc is also a pretty huge application that they (and any self-
hosted language) developed in parallel with Rust :D

(I'm pretty sure I remember hearing that rustc has more code at this point
then servo does, but don't quote me on that)

~~~
larsberg
If you just count *.rs files, rust and its in-tree libraries are around 400k
lines, and Servo and its immediate dependencies are around 310k lines.

Caveat: use of 'find' and 'wc' is almost invariably totally misleading :-)

------
mlitchard
Well, there's been some buzz about rust in the haskell community, which piqued
my interest. And now it's time to give it a look.

~~~
steveklabnik
Lots of us Rust people really like Haskell too. What's the Haskell community
say? Have any links I can check out?

------
ChuckMcM
Awesome job! I so want to port it to the VAX so I can say "I put Rust on some
old Iron" :-)

Time to start exploring it again.

------
swetland
Is there a way to parallelize the build?

I just checked out the github repo on a quad core 3.4GHz i7 with 16GB ram, and
make -j8 took 37 minutes -- the c/cpp stuff (like llvm) built in parallel, but
all the rust stuff did not, such that 7 cores (HT) of 8 were idle for the bulk
of the build.

------
jumanji
Are there any plans for ARM-support? Last time I looked, it did not seem to be
supported.

~~~
jnbiche
ARM is well supported, and has been for quite some time. Where did you read
that there was no ARM support?

~~~
odroid-user
I attempted to install Rust on my ODROID-XU3 (which is running Lubuntu 14.04.1
LTS) just now by running:

    
    
      curl -s https://static.rust-lang.org/rustup.sh | sudo sh
    

The resulting output was:

    
    
      rustup: CFG_CURL             := /usr/bin/curl (7.35.0)
      rustup: CFG_TAR              := /bin/tar (1.27.1)
      rustup: CFG_FILE             := /usr/bin/file (5.14)
      rustup: CFG_SHA256SUM        := /usr/bin/sha256sum (256sum)
      rustup: CFG_SHASUM           := /usr/bin/shasum (5.84)
      rustup: 
      rustup: processing sh args
      rustup: 
      rustup: CFG_PREFIX           :=  
      rustup: CFG_DATE             :=  
      rustup: 
      rustup: validating sh args
      rustup: 
      rustup: error: unknown CPU type: armv7l
    

What should I do?

~~~
kibwen
Rather than trying to run the compiler itself on a given platform, I'd
recommend cross-compiling binaries from a known platform. I'm not an expert in
this aspect of Rust, but here's some example Rust code that targets the PSP:
[https://github.com/luqmana/rust-psp-hello](https://github.com/luqmana/rust-
psp-hello) (AIUI the magic is in the psp.json.in file, which communicates a
target specification to the compiler).

Feel free to come ask in #rust on irc.mozilla.org if you need some experts to
consult!

~~~
odroid-user
I have a VPS running x86_64 Debian unstable so I installed Rust on it now.

I compiled an hello world on the VPS, the content of which is:

    
    
      fn main () {
        println!("hello world");
      }
    

using

    
    
      rustc main.rs
    

and the resulting binary ran on the VPS and said

    
    
      hello world
    

I went to the example Rust code you linked that targets PSP and had a quick
look at it but it was kind of a lot at once so I went looking for alternatives
and found
[https://github.com/japaric/ruststrap](https://github.com/japaric/ruststrap)
which seemed promising but the README was not very clear and the archive
hosted by that person is from 2014-12-17. I cloned it to my VPS and attempted
to run the ruststrap.sh which it didn't want to unless it was root so I let it
be root but it ended with

    
    
      + apt-get install -qq g++-arm-linux-gnueabihf
      E: Unable to correct problems, you have held broken packages.
    

So I'm not sure if I was supposed to run that on x86_64 or not or if maybe I
was supposed to run something else first. My VPS is a bit of a mess so that
could be the reason also.

I am going to go back now to the example Rust code for PSP you linked and look
more at it, it seems to be the most promising at this point (though it will be
a bit inconvenient for me in the long run to do any development on the VPS
instead of locally.)

Thank you for your comment and the link.

------
cottonseed
What the status of Rust for Android/iOS?

~~~
steveklabnik
Every commit is tested against Android. We just merged a PR that improves our
iOS support.

~~~
cottonseed
Thanks for clarifying. I checked the FAQ and there was a question about
Windows support, but not mobile platforms.

For others who are interested, there are instructions here for building Rust
for Android and iOS, see "Platforms":

[https://github.com/rust-lang/rust/wiki/Docs](https://github.com/rust-
lang/rust/wiki/Docs)

------
svraghavan
Congrats to the whole Rust team. Awesome work. Time to jump in.

------
builtwithrust
Hi everyone, Have you guys already had any cool projects and want to share
with us? I just quickly made a site here where I would love to showcase your
Rust project. [http://builtwithrust.com/](http://builtwithrust.com/). Thanks
all,

------
Exuma
Great job rust team! I've been playing around with this lately and it's a lot
of fun.

------
akavel
Does anyone know of the Rust Book is available in epub format?

Or, if not, but if it's still possible to build one from source, what are the
required dependencies I have to install to be able to build the epub?

~~~
gascloud
It would be more useful in a format which works on Kindle, since that's by far
the most common. It wouldn't hurt to support both and also pdf. If there was a
single page view of the book it would be quite trivial to export it to a
single ebook file.

~~~
kasabali
Open source tooling for creating mobi's are nowhere near epub's and Calibre
does a good job of converting epub to mobi, so I don't mind when projects
offer only epub, although I'm a heavy mobi user.

------
MrBra
Quick poll: what's your favourite features in Rust? What's the core reasons
for you are going to use it soon?

------
azdle
So that's why I'm suddenly getting all these "warning: use of unstable item"
after doing a rustup.

~~~
steveklabnik
Yes, though you will get fewer tomorrow: [https://github.com/rust-
lang/rust/pull/20786](https://github.com/rust-lang/rust/pull/20786)

~~~
heinrich5991
That won't get you less warnings, it just won't turn these warnings into
errors for doc tests.

~~~
steveklabnik
Oh right.

------
KenoFischer
Congratulations to the rust team! Committing to 1.0 is a scary step :).

------
ibnukamy
Congrats and thank you guys for all the hard works.

------
arenaninja
Just downloaded, I'm excited for this

------
alouanchi
Finally time comes to have a look at it.

------
weatherlight
This is Super Exciting!

------
namelezz
Congratulations!

------
Eleutheria
Stupid question...

Why not 'let' and 'var' instead of 'let' and 'let mut'?

It's just so ... weird.

~~~
steveklabnik
One reason is that let takes a pattern, so you can do things like:

    
    
        let (x, mut y) = ...
    

Another reason is that we feel 'mut' more cleanly communicates mutability than
'var.' Another reason is that we prefer immutability by default, and let/var
doesn't communicate that as nicely as let and let mut.

There are some discissions about this on the ML archives, RFC repo, or
discuss, if you're interested.

~~~
Eleutheria
let (x, var y) = ... can easily express the intention.

Also, communication is in the ear of the beholder. Var: variable, that varies.
'Let' would be immutable by default.

Thanks for the response anyway.

~~~
bjz_
Well then it would be:

    
    
        let var x = ...
    

the `mut` or `var` is part of the pattern match.

~~~
Eleutheria
No.

    
    
        let x = 100 // constant
        var y = 200 // variable
        
        x = x + 1 // error
        y = y + 1 // 201

------
adultSwim
Wake me when we get there

------
mopo2000
How can you have an alpha without generics?

~~~
nercury
You can read up here: [http://doc.rust-
lang.org/book/generics.html](http://doc.rust-lang.org/book/generics.html), as
well about "output" generics here: [https://github.com/rust-
lang/rfcs/blob/master/text/0195-asso...](https://github.com/rust-
lang/rfcs/blob/master/text/0195-associated-items.md), and explore usage in
collections here: [http://doc.rust-
lang.org/nightly/std/collections/](http://doc.rust-
lang.org/nightly/std/collections/).

~~~
12423gsd
Are "Traits" basically C++ Concepts?

~~~
adrusi
Somewhere between C++ concepts and Haskell typeclasses with a hint of Java
interfaces.

But yes, their primary usage is to require that type parameters exhibit a
certain set of properties.

