Re:Announcing Rust 1.18
by kibwen on Thursday June 08, 2017 @12:49PM
(#14515389)
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
Re:Announcing Rust 1.18
by steveklabnik on Thursday June 08, 2017 @01:27PM
(#14515632)
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:
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
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
Re:Announcing Rust 1.18
by kibwen on Thursday June 08, 2017 @01:51PM
(#14515810)
> you cannot write a function that returns a closure
This is true for your specific example, but in the interest of completeness there are cases where such a thing is possible. The full story is that you can't name the closure's type, so you can only write the type signature in certain cases. For example, the following function returns a stack-allocated closure just fine today (with example usage to prove it):
fn foo<F: Fn(i32)->i32>(bar: F) -> F {
bar
}
fn main() {
let x = |y| { y + 2 };
let z = foo(x);
z(5);
}
This is mostly pedantry, though, because it's true in that the majority of the time that you want to return a closure it's a closure that was created within that function, not passed in. This is where `impl Trait` is crucial.
Re:Announcing Rust 1.18
by jeeyoungk on Thursday June 08, 2017 @01:37PM
(#14515707)
is there a RFC link for this? I got bitten by this once by attempting to return a derived iterator similar to `x.iter().map(...).filter(...)` example you had, but I couldn't figure out the return type of such function as Rust forbids type inferencing for return types.
Re:Announcing Rust 1.18
by kzrdude on Thursday June 08, 2017 @01:41PM
(#14515734)
Yes it hasn't been properly possible to return such an iterator chain that uses closures before, unless the iterator is manually boxed. With impl Trait that is now fixed.
Re:Announcing Rust 1.18
by kzrdude on Thursday June 08, 2017 @01:34PM
(#14515682)
Extends the reach of unboxed statically typed values. It's awesome in its power that way, while still using the same type checked trait model for generics.
Re:Announcing Rust 1.18
by kibwen on Thursday June 08, 2017 @05:08PM
(#14517212)
For some reason I can't bring myself to consider a specific new attribute to be a "language-level feature", regardless of how much machinery it takes under the hood. To me, that's an API. :P
Re:Announcing Rust 1.18
by hacker_9 on Thursday June 08, 2017 @12:39PM
(#14515318)
"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.
Re:Announcing Rust 1.18
by steveklabnik on Thursday June 08, 2017 @12:45PM
(#14515358)
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.
Re:Announcing Rust 1.18
by kibwen on Thursday June 08, 2017 @12:54PM
(#14515416)
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/ . 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... ), improvements to linking (via LLD), improvements to debug codegen (via Cretonne: https://internals.rust-lang.org/t/possible-alternative-compi... ), and of course incremental recompilation.
Re:Announcing Rust 1.18
by vvanders on Thursday June 08, 2017 @12:36PM
(#14515304)
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.
Re:Announcing Rust 1.18
by vvanders on Thursday June 08, 2017 @12:45PM
(#14515360)
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.
Re:Announcing Rust 1.18
by steveklabnik on Thursday June 08, 2017 @01:28PM
(#14515642)
We hope to have a status report on all of our yearly goals out sometime soon; we had a core team meeting reviewing progress yesterday.
The short of it is "it's all in various stages of development, nothing has hit stable yet." I don't think there's anything major in the next release either, the one after that may or may not have something, we'll see.
Re:Announcing Rust 1.18
by kibwen on Thursday June 08, 2017 @01:56PM
(#14515836)
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
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:
the type of this is something like 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:largeSo, we could write
and be done, no matter how many adapters we use. In current Rust, you can do this: 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
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 or whatever the type of the closure is.This is true for your specific example, but in the interest of completeness there are cases where such a thing is possible. The full story is that you can't name the closure's type, so you can only write the type signature in certain cases. For example, the following function returns a stack-allocated closure just fine today (with example usage to prove it):
This is mostly pedantry, though, because it's true in that the majority of the time that you want to return a closure it's a closure that was created within that function, not passed in. This is where `impl Trait` is crucial.The latest RFC is https://github.com/rust-lang/rfcs/pull/1951 ; it was in several.
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.
To be clear though, this PR is about improving the speed of compiling the compiler, not for using the compiler on other programs.
[1]: https://github.com/rust-lang/rust/compare/cb4065b9ce4e2bb2c3...
Whole bunch of perf fixes at once.
Does this mean you can now build Android targets without a standalone NDK? That part wasn't quite clear from the PR.
https://github.com/rust-lang/cargo/pull/3885/files#diff-27a1... would imply to me that oyu still need an NDK.
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.
The short of it is "it's all in various stages of development, nothing has hit stable yet." I don't think there's anything major in the next release either, the one after that may or may not have something, we'll see.
- 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.