
Announcing Rust 1.18 - steveklabnik
https://blog.rust-lang.org/2017/06/08/Rust-1.18.html
======
kibwen
Looking ahead to 1.19 (currently in beta, which you can try out easily via
rustup), the RFC for unsafe (C-style) unions recently stabilized, which closes
IMO the biggest remaining hole in Rust's FFI story. By removing the need for
various manual hacks to interoperate with unions from C libraries, this should
help bring greater safety to C code bound to Rust (or vice versa). Along with
`pub(crate)` discussed in the OP and the `?` operator from 1.15, this makes
for the third real language-level "feature" that Rust has added in the past
two years, though I'd say these are more quality-of-life improvements than
anything earth-shaking. Now, when `impl Trait` lands (recently accepted, but
yet unimplemented), _that_ will be a big deal. :P

~~~
cpr
What will `impl Trait` do, for us Rust-interested onlookers?

~~~
steveklabnik

      fn foo() -> impl Trait {
    

means "this function returns something that implements the Trait trait, but
I'm not gonna tell you what that concrete type is."

This is primarily useful in two cases: first, in an effort for static
dispatch, some types can get really long. For example, imagine you wanted to
return an iterator of some kind, like this:

    
    
        foo.iter().map(|x| x + 1).filter(|x| x % 2 == 0)
    

the type of this is something like

    
    
        Filter<Map<Iter<'_, {integer}>, [closure@<anon>:2:27: 2:36]>, [closure@<anon>:2:45: 2:59]>
    

which is pretty gross. First of all, you'll notice the type `Filter<Map<Iter`,
as you keep adapting the iterator, you get more types. With iterators it's
normally not huge, but if you're using Tokio or Diesel, it can get very bad.
Here's a type error I ran into recently with Diesel
[https://pbs.twimg.com/media/C6l_OwSXAAA_Fmo.jpg:large](https://pbs.twimg.com/media/C6l_OwSXAAA_Fmo.jpg:large)

So, we could write

    
    
        fn foo() -> impl Iterator<Item=i32> {
    

and be done, no matter how many adapters we use. In current Rust, you can do
this:

    
    
        fn foo() -> Box<Iterator<Item=i32>> {
    

but now you've introduced a heap allocation and dynamic dispatch; impl Trait
has no allocations and statically dispatches.

The second bit is also present in that type, which is this bit

    
    
      [closure@<anon>:2:27: 2:36]
    

Closures have an anonymous type in Rust, and so you cannot write a function
that returns a closure without using a Box like above. impl Trait will fix
that, by letting you write

    
    
        fn foo() -> impl Fn(i32) -> i32 {
    

or whatever the type of the closure is.

~~~
mrkgnao
Would that be related to an existential type of the form

    
    
        foo :: a -> (forall b. Show b => b)
    

from Haskell?

~~~
steveklabnik
Yes, it is. Generics are universals and impl Trait is extisentials. For more,
the RFC gets into it [https://github.com/rust-
lang/rfcs/blob/master/text/1951-expa...](https://github.com/rust-
lang/rfcs/blob/master/text/1951-expand-impl-trait.md#universals-any-versus-
existentials-some)

------
hacker_9
_" compiling rustc itself is now 15%-20% faster. Each commit message in this
PR goes over the details; there were some inefficiencies, and now they’ve been
cleaned up."_

Good to hear work is being done to speed up the compiler. It's the only reason
I haven't tried Rust out yet, as it often comes up as a problem when others
review the language.

~~~
steveklabnik
We've been putting in a massive amount of work, and are continuing to do so.
Each release gets a little faster. Incremental recompilation is on the way.
It's something we care about a lot.

To be clear though, this PR is about improving the speed of compiling the
compiler, not for using the compiler on other programs.

~~~
kibwen
Which isn't to say that the compiler itself (not counting incremental
compilation here) isn't getting faster, but the improvements are gradual
rather than the dramatic numbers seen in the OP. We have a website for
tracking general compiler perf on a few representative programs:
[http://perf.rust-lang.org/](http://perf.rust-lang.org/) . In the benchmarks
there it looks like we've shaved off about half a second from the compilation
time on most benchmarks since March, though some have improved by multiple
seconds and others have remained the same. In the long-term, we're looking at
improvements to typechecking (via Chalk:
[http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowe...](http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-
rust-traits-to-logic/) ), improvements to linking (via LLD), improvements to
debug codegen (via Cretonne: [https://internals.rust-lang.org/t/possible-
alternative-compi...](https://internals.rust-lang.org/t/possible-alternative-
compiler-backend-cretonne/4275) ), and of course incremental recompilation.

~~~
infogulch
What's that jump at Apr 22 [1]?

[1]: [https://github.com/rust-
lang/rust/compare/cb4065b9ce4e2bb2c3...](https://github.com/rust-
lang/rust/compare/cb4065b9ce4e2bb2c37994762462da76272d6907...252d3da8a6c715ccafcf77d83b826f6fb899cfe5)

~~~
Manishearth
[https://github.com/rust-lang/rust/pull/41469](https://github.com/rust-
lang/rust/pull/41469)

Whole bunch of perf fixes at once.

------
vvanders
> Finally, Cargo now supports Haiku and Android!

Does this mean you can now build Android targets without a standalone NDK?
That part wasn't quite clear from the PR.

~~~
steveklabnik
Cargo now runs on an Android host. I'm not an Android dev so I don't know what
that means regarding the NDK.

[https://github.com/rust-
lang/cargo/pull/3885/files#diff-27a1...](https://github.com/rust-
lang/cargo/pull/3885/files#diff-27a1525c20fcb2ec7c4c41e750113a93R18) would
imply to me that oyu still need an NDK.

~~~
vvanders
Ah, gotcha.

Yeah, the Standalone NDK is a bit of a pain since the .cargo/config requires
absolute paths to the linker/ar. It makes it hard to commit a common config
file for multiple people working in one repo.

~~~
anonova
I use the executable name in the config and tell people to add
$STANDALONE_NDK/bin to $PATH.

    
    
      [target.arm-linux-androideabi]
      ar = "arm-linux-androideabi-ar"
      linker = "arm-linux-androideabi-gcc"

~~~
vvanders
Yeah, it'd be cleaner if you could include env vars in the config since I'm
not a huge fan of polluting my PATH and usually NDK_HOME or similar is already
defined.

------
equasar
Any update on the progress of the language ergonomics?

~~~
kibwen
The ergonomics initiative is composed of many independent tasks. I don't know
if these are all tracked centrally somewhere, but e.g. there's currently an
RFC in its final comment period regarding improving the ergonomics of matching
references: [https://github.com/rust-
lang/rfcs/pull/2005](https://github.com/rust-lang/rfcs/pull/2005)

~~~
akavel
There seems to be something here: [https://github.com/rust-lang/rust-
roadmap/issues/17](https://github.com/rust-lang/rust-roadmap/issues/17) ?

------
mmport80
Rust is another language which gives us the kitchen sink, allows anyone to do
anything when they are in a bind.

\- quoting Jon Carmack -

whatever the compiler allows in, will eventually be included in your codebase

It's an improvement over C. But where were the hard decisions? Where is the
line in the sand on safety? (I am hopingg to bbe educatted! ; ))

It's not the future, just more of the past.

