
Announcing Rust 1.8 - steveklabnik
http://blog.rust-lang.org/2016/04/14/Rust-1.8.html
======
Perceptes
It's not mentioned in the post, but 1.8 also includes support for installing
additional versions of the stdlib for other targets using rustup/multirust[1],
which is huge for cross compilation:

    
    
      $ rustup target add x86_64-unknown-linux-musl
      info: downloading component 'rust-std' for 'x86_64-unknown-linux-musl'
      13.77 MiB / 13.77 MiB (100.00%) 1.47 MiB/s ETA: 0s
      info: installing component 'rust-std' for 'x86_64-unknown-linux-musl'
    

Which allows:

    
    
      $ cargo build --target x86_64-unknown-linux-musl
    

You can get a list of available targets with `rustc --print target-list`.

[1] [https://www.rustup.rs/](https://www.rustup.rs/)

~~~
hsivonen
Are official rustc and cargo releases to be expected for running natively on
the tier2 platforms (e.g. official rustc for Linux on ARMv7 that targets Linux
on ARMv7)?

~~~
kibwen
It's probably not out of the question, though are there a lot of people out
there who want to actually develop on e.g. Android rather than just targeting
it?

~~~
crzwdjk
My laptop is armv7 linux, and not being able to run rustc on it has been
annoying. Well, I did find some binary of some old version somewhere, but it's
of limited usefulness since it's old, and it didn't come with cargo, which
also wants to bootstrap itself from a native binary. The last time I tried it,
I couldn't even cross-compile an ARM rustc from x86_64, because the build
scripts wanted to run the binary they were building. This is literally the
only reason I've been using C and not Rust (which would have been a much more
suitable language) for my latest project.

EDIT: Huh. I guess they do have binaries for arm linux now, at least for
nightly and beta versions, as of literally two days ago.

------
ultramancool
They should probably change their terminology away from "RFC" for referring to
Rust RFCs rather than IETF ones. Maybe RRFCs or REPs something?

In this document is a perfect example of the problem, they list several Rust
RFCs by RFC number, then talk about IP RFC based loopback detection, expecting
everyone to know that RFC 6890 refers to an IETF one and not a Rust one. I
mean, most of us can infer that just by length of the number, but it is pretty
ambiguous especially when they're used in the same document like this.

~~~
sambe
I always thought RFC was generic (and/or predates IETF). Is that not true?

~~~
wyldfire
It is generic and does predate IETF but it's ambiguous to which reference
material if the number ranges intersect.

------
webkike
I've been using Rust more and more for my personal projects. Frankly, I could
not give a hoot about the memory management; it's pretty cumbersome to deal
with. What I love about Rust is that it's a low overhead language that uses
interfaces. I love interfaces! I honestly think that they're the best way to
program.

~~~
pcwalton
I'm glad you like it :) I'm happy to see more emphasis on the productivity-
related aspects of Rust. I talk about memory safety a lot because people ask
questions like "what one feature makes you different from C++11?", but the
productivity-boosting features like traits and Cargo are just as important in
my mind.

~~~
drbawb
The importance of Cargo / crates.io cannot be understated, I think.

I've found myself using Rust for little one-off tools and scripts lately
because it's so darn easy to type `$ cargo new --bin foobar` on any of the
three operating systems I use daily.

There's already a pretty nice ecosystem of web servers, graphics libraries,
crypto libraries, etc. -- Not to mention the bindings to existing libs.

At the end of the day I always end up with wicked fast binaries that I can run
on Windows, Mac, or Linux with fairly minimal fuss.

\---

I really haven't found a language that hits this niche the way Rust does,
which is really strange to me considering Rust's mission statement.

No shell scripting language is that easily portable barring something like
MinGW.

I've never had what I'd call a pleasant experience using Ruby, Python, or
Javascript on Windows. Not to mention if the language runtimes / stdlibs don't
demand it: many of the 3rd party libraries assume a *nix toolchain to build
all the C extensions.

Go and Java probably come the closest to writing easily portable software, but
I personally find writing Rust to be a more fulfilling endeavor.

\---

The other day I wrote a tool to deduplicate my image library in Rust. The
first binary to compile worked perfectly on both Mac OS and Windows, ran
wicked fast (on my SSDs anyways), and it was really a pleasure to write. --
Rust's iterators alone really make for some beautiful code.

\---

This was a really long-winded way of saying I love Rust, and thanks for all
the hard work ^^,

~~~
Zikes
Out of curiosity, what methods did you use for image dedupes? Simple file
hash, or something more complex to find e.g. watermark vs no, different
crops/scales, etc.?

~~~
drbawb
At the moment it is just hash based, which actually remedied most of my
immediate problem. (I have 8 drives in my workstation. Many of them are donors
from computers long gone. [Portions of] my image library have just been copied
around many times without much rhyme or reason. Now it's centralized and
properly backed up.)

I did think about comparing images by similarity but ultimately tabled it for
a later evening because:

\- I quickly realized I had a lot of reading to do

\- Resolving "similar images" conflicts is a fuzzier, more time intensive
process since: (a) maybe the comparison is just plain wrong?, (b) maybe it's
not strictly a worse crop, but rather two common aspect ratios which you'd
like to keep, (c) maybe it's not actually "watermark" text but rather it's a
meme or image macro, etc.

\- Personally: my real problem with images of varying sizes is that I download
thumbnails by mistake. That's just PEBKAC and no amount of software can fix
that.

(Now that I think about it: it might be nice to have a script which iterates
over low resolution images and tries to find a large resolution version w/
Google Image Search.)

------
thewhitetulip
I never got around to use Rust, maybe I'll get some good answers here on HN,
how does Rust compare with Go/Python/Java?

~~~
mike_hearn
They aren't really comparable. Rust is a lower level language that primarily
competes with C++ (finally! C++ badly needs the competition). C++ is still
around because it is one of the few languages that has a pay-as-you-go model
to features and is not GCd, so, you can reasonably do things like write
embedded software for micro-controllers, or kernels, etc.

Go, Python and Java (or any JVM language) are all high level garbage collected
languages that focus on developer productivity. You pay certain costs just as
the price of entry, like garbage collection, and the requirement for a fairly
hefty runtime. In return you get various useful features.

Examples:

You would not use Rust to write a large complex webapp as part of a corporate
team, that spends most of its time talking to databases or message queues. The
best tool for this from your list would be Java.

You would not use Rust to write a small script to do system administration
tasks or quickly prototyping a new idea. The best tool for this from your list
would be Python.

You would not use Rust to write a small, simple command line tool that
nonetheless could benefit from being garbage collected. You could use Go for
that (I hesitate to say it's the best tool but plenty of people use it in that
way).

~~~
abritishguy
I'm curious as to what makes you think that Java is preferable to Go for a
large webapp that "spends most of its time talking to databases or message
queues".

I would have thought that the Go's concurrency model would give it an edge.

~~~
allan_s
> I'm curious as to what makes you think that Java is preferable to Go for a
> large webapp that

because your large webapp is made by a large team, over a large time span. The
same as you don't deploy on power8 but on x86, because x86 is more common than
power8 and cheaper.

One of your java programmers leave ? replace him is easy Need to find java
programmers ready to do shitty and boring debugging ? easy Your large webapp
is in maintenance mode and nobody internally wants to touch it, so you decide
to find a cheap company abroad to outsource the maintenance ? easy

Hard to find these three with Go (or rust, and I love both) because right now
it's taught in no large scale university nor a lot of people have been exposed
"accidentaly" by it. SO if you have been exposed to Go (or rust) and decide to
stik with it it's because you actively decide to, not just because of market
force. Hence so you don't belongs to those who will want to do shitty bug
fixing 8 hours ago, nor to the price of a developer people hire just to have
two more hands, nor the kind who will accept a job under-payed for a
outsourcing company.

Java, permits your management to feel they can scale the development

~~~
steveklabnik
Not that this invalidates your point, but there are two university classes
being taught in Rust right now; I had the pleasure of guest lecturing at
Penn's yesterday, in fact. Here's hoping to more of those in the future.

I certainly agree this is a big plus for Java.

~~~
allan_s
ah great to know ! I also hope to see more in the future.

here I was playing the devil's advocate, but to have been at both seat (having
hard time to hire as a CTO and needing to fallback on PHP in one company /
trying to push Rust in my current one) I now see why chosing a stack is not
only about tehcnical merits.

------
manaskarekar
Anyone know of any real world applications using Rust?

EDIT: [https://github.com/kud1ing/awesome-
rust](https://github.com/kud1ing/awesome-rust)

I'm loving the pace of the release cycle! I don't think I can hold off the
temptation to try it out - it's too shiny!

~~~
steveklabnik
I gave a talk at a conference this week called "Rust in Production". Some of
the companies I highlighted included Dropbox, Skylight.io, and well, Firefox
;)

We're hoping to do more showing off of our production users in the future.
Getting more production Rust in the wild is a big personal goal for me this
year.

~~~
nachtigall
I think "Rust in Production" should be added to the FAQ. It does not seem to
fit in with [https://www.rust-lang.org/faq.html#how-does-mozilla-use-
rust](https://www.rust-lang.org/faq.html#how-does-mozilla-use-rust) or the
following question regarding large rust projects.

Q: Which companies use rust in production? A: Dropbox, Mozilla, Skylight,
OneSignal, etc with links to the relevant tech blog posts.

I think there once was such a Q but it seems to have gone or I can't find it
anymore.

~~~
steveklabnik
Website stuff related to this is coming, don't worry.

------
nickpsecurity
Congratulations. Particularly, I think the Tier 1 i686 might get Rust more
adoption by Windows C/C++ crowds in commercial sector. Improvements for large
files in Linux might aid adoption in backup/archive and streaming servers.
Just curious, did Dropbox's feedback have anything to do with that?

~~~
kibwen
The large file improvements were only needed on 32-bit platforms, and I'd
assume that Dropbox's servers are all 64-bit.

~~~
nickpsecurity
Alright,thanks. I was just curious if a single deployment on their level led
to bugfixes or new features.

~~~
kibwen
The Rust team has been in constant contact with the Dropbox team (I should
know, I coordinated and attended the original meeting), and I can say for
certain that feedback from Dropbox has helped to prioritize and inform the
stabilization of several features.

~~~
nickpsecurity
Cool, cool. I figured that would be the case. Tge idea behind the questions is
kind of my exploration into the many eyes idea. It mostly covers feedback from
widespread, random use. Howevet, I figured a small number of smart, industrial
users stress-testing a new language/compiler might provide higher than average
quality feedback than even twice as many casual developers. So my advice was
to try to get such testers soon as key stuff is stable.

Was the prediction accurate in that case? Sounds like it so far.

------
cm3
Any word on linux-musl builds so that you can use official rust builds on
alpine or void linux? Same question for FreeBSD builds.

~~~
steveklabnik
Regarding BSDs: [https://users.rust-lang.org/t/psa-rustc-cargo-can-now-be-
ins...](https://users.rust-lang.org/t/psa-rustc-cargo-can-now-be-installed-on-
arm-linux-netbsd-and-freebsd-using-rustup-multirust/5383)

We are still working on musl as a host, it's not there yet, in my
understanding. Cross-compiling to it should be easy, but that doesn't help
much if you're on Alpine.

~~~
cm3
Wait, is this a different rustup than rustup the shell script?

~~~
steveklabnik
Yes. I might as well take the time to elaborate on the history here.

In the beginning, there was rustup. And it was good. Then, Rust matured, and
we started the release channels. Now there wasn't just "Rust 0.9", there was
Rust stable, beta, 1.0, 1.1... so many versions. rustup.sh wasn't really built
to handle that.

And so, multirust was born. mutlirust was/is a bash-based shell script that
wraps up rustup and gives you the ability to manage multiple installs of Rust.
And fun things like "this project uses rust stable, but this project uses Rust
1.1" and "please update every Rust I have installed". Stuff like that.

But it was a bash script. Nobody knew that this whole Bash in Windows thing
was happening. And we already have a perfectly good, general purpose
programming language that runs on all the platforms Rust supports: Rust! So
the multirust-rs project was begun, to re-write multirust in Rust.

Once that started to become closer to being finished, we took a step back,
looked holistically at all of this, and thought "If we started from scratch,
what would we do?" [https://public.etherpad-mozilla.org/p/rustup-new-
experience](https://public.etherpad-mozilla.org/p/rustup-new-experience)

And so, "rustup" was born. It's pretty much multirust.rs, but without trying
to mimic the old multirust itself. There's still lots of stuff to do before
it's ready to become the default way you manage rust installations:
[https://internals.rust-lang.org/t/beta-testing-rustup-
rs/331...](https://internals.rust-lang.org/t/beta-testing-rustup-rs/3316) and
[https://github.com/rust-lang-
nursery/rustup.rs/issues?q=is%3...](https://github.com/rust-lang-
nursery/rustup.rs/issues?q=is%3Aissue+is%3Aopen+label%3A%22initial+release%22)
And of course, many people will want to use their system package manager too.
Choice is good. They also play together. But that's for another post, this one
is already getting long.

You can find rustup here: [https://www.rustup.rs/](https://www.rustup.rs/)

~~~
cm3
Thanks for the backstory.

It's always much preferable to have as few dependencies for bootstrapping a
platform as possible. Therefore, this is a good development.

Similarly, I'm hopeful the Python requirement in the new Rust based build
system for rust itself will be removed sooner than later. Building Rust
already requires Rust, so what's more logical than replacing the Python part
with Rust. It will definitely be easier to get going than having to install
some Python modules first. Same improvement should happen in servo's build
system which since a few months or a little longer depends on virtualenv.

------
harveywi
Does anyone have any information about when/if we will see support for higher-
kinded types in Rust? There is the RFC thread on Github
([https://github.com/rust-lang/rfcs/issues/324](https://github.com/rust-
lang/rfcs/issues/324)), but I haven't been following the trajectory very
closely, and a quick synopsis would be wonderful and appreciated.

~~~
kibwen
Higher-kinded types are a far-future enhancement. There are several language-
level features that I would expect to be prioritized far above HKT; off the
top of my head: specialization (an early prototype implementation of this is
in nightly), placement-new, type-level numerics, stabilized syntax extensions,
and non-lexical borrows. Of those, all but the last is for the sake of runtime
efficiency, whereas HKT is just about genericity and expressiveness (neither
of which Rust extremely prioritizes, at least not relative to languages like
Haskell).

------
0X1A
I haven't quite looked but is there a timeline for when compiler plugins will
be stabilized? Interested in using serde but would prefer using macros

~~~
steveklabnik
Not an exact timeline, but it's something that's being actively worked on.
There's even an RFC: [https://github.com/rust-
lang/rfcs/pull/1566](https://github.com/rust-lang/rfcs/pull/1566)

------
quotemstr
Does Rust still abort on OOM? I won't use it by choice while it does that.

~~~
steveklabnik
That's the standard library, not the language. You can use whatever semantic
you want if you don't use the standard library, which is very easy to do.

~~~
quotemstr
And since most programs in any language will use that language's standard
library (since that's the point of having a standard library), Rust systems in
practice will not tolerate memory exhaustion. This property renders the whole
system unacceptable to me.

~~~
steveklabnik
There is already an ecosystem of packages for OS development even, and we
statically know if you use the standard library or not. Many libraries that
don't require it have an option to turn it off.

I understand your skepticism, but we care about this use case and are working
to make it easy.

------
optforfon
A few days ago I posted a comment with my problems with C. Can you use Rust as
a better C/cross-platform-assembly?

does it have native support for

\- vectorization/SIMD

\- hinting at likely branches

\- prefetching memory

\- forcing or blocking inlining

and all the magic in gcc C extensions

~~~
alkonaut
Manual SIMD intrinsics is getting there, not sure how far it has come by now:
[https://github.com/rust-lang/rust/pull/27169](https://github.com/rust-
lang/rust/pull/27169) I'm sure LLVM does a fair bit of vectorization under the
hood too of course, but not sure whether better knowledge of aliasing lets it
do _more_ or whether less undefined behavior sloppyness in Rust lets it do
_less_ of it than for C++.

Branch hint intrinsic: an accepted RFC but not yet implemented
[https://github.com/rust-lang/rust/issues/26179](https://github.com/rust-
lang/rust/issues/26179)

Prefetch intrinsic: Looks like a rejected rfc [https://github.com/rust-
lang/rfcs/pull/125](https://github.com/rust-lang/rfcs/pull/125)

Inlining: As far as I understand the attributes are #[inline(always)] and
#[inline(never)] respectively.

~~~
optforfon
Thanks for the links! This info is kinda hard to find if you're not in the
loop.

But it looks like low level optimization is a low priority for the Rust
project at the moment.

(prefetch is rejected b/c of insufficient testing and branch hinting might get
hampered b/c Rust developers aren't trusted to use them correctly)

Maybe I'll revisit it in the future! Appreciate the help =)

------
EugeneOZ
Finally I'll switch to Serde JSON :) I use beta and beta is 1.9 today, with
awesome features stabilized!

~~~
Perceptes
Which feature in 1.9 relates to Serde?

~~~
EugeneOZ
Looks like I was wrong. Sorry.

------
vbit
BTW, does rust come with some kind of ide support tools, e.g. a commandline
tool for autocomplete?

~~~
hokkos
Not natively for now, but racer can do it :
[https://github.com/phildawes/racer/](https://github.com/phildawes/racer/)

IDE is a current goal : [https://www.rust-
lang.org/ides.html](https://www.rust-lang.org/ides.html)

------
ysh7
Great news!! Yet is vagrant a real contributor? Or someone messed up his git
user.name?

~~~
steveklabnik
It's someone with a name 'vagrant' in their git info, yes. Not the company.

------
mtgx
Anything big (bigger than usual) planned for 2.0?

~~~
nemaar
After 1.9 1.10 will come. There is no plan for 2.0

~~~
steveklabnik
Yup. There's even one cool feature we already know will be in 1.10: stable
bootstrapping. You'll be able to build Rust 1.10 with Rust 1.9. And Rust 1.11
will build with 1.10. And so on and so on. This should help packagers
significantly.

~~~
kibwen
Is there a tracking issue for this?

~~~
steveklabnik
No, just a PR: [https://github.com/rust-
lang/rust/pull/32731](https://github.com/rust-lang/rust/pull/32731)

