
Rust 1.34.0 - steveklabnik
https://blog.rust-lang.org/2019/04/11/Rust-1.34.0.html
======
Perceptes
The history of TryFrom/TryInto has spanned 3 years, from when it was
originally proposed as an RFC in 2016. For a seemingly simple API, it's gone
through a lot. Especially unusual was that it was stabilized a few releases
ago and then had to be destabilized when a last-minute issue was discovered
with the never type (`!`). The never type had been the primary blocker for
stabilizing these APIs for the last year or so, but it was finally decided to
simply use this temporary `Infallible` type, which would be mostly forwards
compatible with the never type itself.

I've followed the issue closely because it's one of the features used in Ruma,
my Matrix homeserver and libraries. In fact, for the library components of the
project, it was the last unstable feature. With the stabilization of these
APIs, I'll finally be able to release versions of the libraries that work on
stable Rust. This will happen later today!

~~~
swsieber
Here's a funny quote about that...

>> Can you eli5 why TryFrom and TryInto matters, and why it’s been stuck for
so long ? (the RFC seems to be 3 years old)

> If you stabilise Try{From,Into}, you also want implementations of the types
> in std. So you want things like impl TryFrom for u16. But that requires an
> error type, and that was (I believe) the problem.

> u8 to u16 cannot fail, so you want the error type to be !. Except using ! as
> a type isn’t stable yet. So use a placeholder enum! But that means that once
> ! is stabilised, we’ve got this Infallible type kicking around that is
> redundant. So change it? But that would be breaking. So make the two
> isomorphic? Woah, woah, hold on there, this is starting to get crazy…

> new person bursts into the room “Hey, should ! automatically implement all
> traits, or not?”

> “Yes!” “No!” “Yes, and so should all variant-less enums!”

> Everyone in the room is shouting, and the curtains spontaneously catching
> fire. In the corner, the person who proposed Try{From,Into} sits, sobbing.
> It was supposed to all be so simple… but this damn ! thing is just ruining
> everything.

> … That’s not what happened, but it’s more entertaining than just saying
> “many people were unsure exactly what to do about the ! situation, which
> turned out to be more complicated than expected”.

[https://this-week-in-rust.org/blog/2019/03/05/this-week-
in-r...](https://this-week-in-rust.org/blog/2019/03/05/this-week-in-rust-276/)
[https://www.reddit.com/r/rust/comments/avbkts/this_week_in_r...](https://www.reddit.com/r/rust/comments/avbkts/this_week_in_rust_275/ehe2kre/?context=1)

~~~
ComputerGuru
> new person bursts into the room “Hey, should ! automatically implement all
> traits, or not?”

Lol; that was me (although there were probably others). I approve of the
dramatic rendition.

[https://github.com/rust-lang/rfcs/issues/2619](https://github.com/rust-
lang/rfcs/issues/2619)

------
korethr
Hmm, fn before_exec strikes me as a thing that should be gotten rid of
entirely in favor of unsafe fn before_exec if the former indeed turned out to
actually have the potential to cause undefined behavior. But that'd probably
be a breaking change which would require a major version number bump, so
deprecation is absolutely the right thing IMO. And it also sets the stage to
get rid of it outright come the next major version bump.

This is the first such instance of "oops, turns out that wasn't safe after
all, that should have been unsafe" that I've heard of in Rust. Is that because
this is the first such mistake since the 1.0 milestone (the rest of `unsafe`
having been nailed down before 1.0), or have there been other such mistakes
that I didn't hear about because I haven't read the notes for all of the prior
releases of Rust?

~~~
steveklabnik
We can’t get rid of it because we have a commitment to not breaking users’
code. There will not be a Rust 2.0.

There have been some small soundness holes in the typesystem that we have
fixed, resulting in breakage, but since that’s in the language, that’s the
only way. A library API is different. There haven’t been many of these though.
We did have some point releases which immediately fixed some library errors
that were introduced by a release, see 1.15.1. But that was in a new API, and
so the chance of breakage was extremely low. This API has been around for
years. It is also not used much, given it’s a *NIX specific extension you have
to explicitly import.

Note that upon using it, you’ll get a warning, so everyone will at least be
notified.

~~~
ainar-g

      We can’t get rid of it because we have a commitment to not breaking users’ code. There will not be
      a Rust 2.0.
    

This is interesting. The C Standard people have, for example, removed “gets”
from the C11 standard. Go, too, has exceptions to its Go 1 Compatibility
Promise[1], which include security, unspecified behaviour, and bugs, both in
the language and in the standard library. I don't remember for sure, but I
think there were things removed from C++ specifications as well; please
correct me if I am wrong. Did Rust decided to never break stdlib compatibility
because the mechanism of editions was considered from the start, or was this
rather ad-hoc?

[1]:
[https://tip.golang.org/doc/go1compat#expectations](https://tip.golang.org/doc/go1compat#expectations)

~~~
steveklabnik
We do reserve the right to make changes for soundness holes. In theory, you
could argue that this is a soundness hole, and so we can remove it.

We have to do such things extremely judiciously though. Users can only
tolerate so much breakage, even if you say “we did say we reserved the right
to do this.” This API is just so rarely used that it was judged not a good
time to pull the “technically we are allowed to do this” card.

------
jithesh
Now that alternate registries to crates.io is available, hoping artifactory
could add support for rust... -
[https://www.jfrog.com/jira/browse/RTFACT-13469](https://www.jfrog.com/jira/browse/RTFACT-13469)

~~~
pythonist
and [https://newreleases.io](https://newreleases.io) to support at least
[https://crates.io..](https://crates.io..).

~~~
epage
Looks like thats a site for notifying you of new dependencies?

I think I'd prefer PRs like [https://dependabot.com/](https://dependabot.com/)

------
FullyFunctional
No mention of RISC-V support? It sounds like RV64GC finally landed (Hurra and
thanks!):

"riscv64imac-unknown-none-elf and riscv64gc-unknown-none-elf targets are now
on stable rustc 1.34.0 :slightly_smiling_face: [https://github.com/rust-
lang/rust/blob/master/RELEASES.md#ve...](https://github.com/rust-
lang/rust/blob/master/RELEASES.md#version-1340-2019-04-11")

[https://github.com/rust-
embedded/wg/issues/218#issuecomment-...](https://github.com/rust-
embedded/wg/issues/218#issuecomment-482307010)

EDIT: Mea culpa, I somehow missed that it _is_ in the release notes, but
still, it's worth pointing out. I hope it'll find its way into Fedora/RISC-V.

------
trzeci
Such a boring release. That's why I love Rust.

~~~
pjmlp
For me the best releases will be when it matches D/Delphi/Ada/Eiffel/.NET
Native compile times and cargo supports binary dependencies.

The language as such is already quite good, in spite of one or other possible
improvements on borrow checker ergonomics (e.g. callbacks).

~~~
eikenberry
> For me the best releases will be when it matches D/Delphi/Ada/Eiffel/.NET
> Native compile times [..]

Any ideas on when this will be? There has been talk about faster compile times
for years now without that much apparent progress.

~~~
burntsushi
> There has been talk about faster compile times for years now without that
> much apparent progress.

Really? What makes you say that? Have you tried it?

    
    
        $ git clone git://github.com/BurntSushi/ripgrep
        $ cd ripgrep
        $ git checkout 0.4.0
        $ time cargo +1.12.0 build --release
        
        real    1:09.13
        user    2:06.08
        sys     2.839
        maxmem  359 MB
        faults  1292
        $ cargo clean
        $ time cargo +1.34.0 build --release
        
        real    22.484
        user    2:32.66
        sys     3.380
        maxmem  702 MB
        faults  0
    

That's a >3x wall-clock speedup over the past 2.5 years on a cold start.
That's pretty good.

~~~
Thaxll
The memory doubled?

~~~
pcwalton
I don't know about that specific measurement, but memory usage of the Rust
compiler has not doubled in general. If it did, we'd notice immediately, as
the script crate in Servo would probably OOM.

------
ben0x539
> People maintaining proprietary/closed-source code cannot use crates.io, and
> instead are forced to use git or path dependencies. This is usually fine for
> small projects, but if you have a lot of closed-source crates within a large
> organization, you lose the benefit of the versioning support that crates.io
> has.

I'm surprised that making people run their own registries is the preferred way
to address this, instead of implementing versioning support for git
dependencies.

There's many bad things I say about golang, but "I wish this module system
additionally required me to host a language-specific package repository" is
not one of them.

~~~
Manishearth
What do you mean by "versioning support for git dependencies"? We do support
pulling in git dependencies based on a branch (I think tags work?)

We also support checking the version of the git dep.

It's fetching the dep that's the problem. Git has no uniform protocol for
talking about versions, especially when it comes to resolving SemVer ("you
asked for 0.2.1 but I also have 0.2.5, here you go")

If you want go-style import resolution use a local git dep. That works fine.
It's specifically when you want all the features of cargo's version resolution
-- which git doesn't understand -- you need to use a custom registry.

~~~
ben0x539
"Versioning support" is the wording from the release notes. I don't know why
cargo's version resolution logic can't be applied to git dependencies,
treating a tag like "v4.2" or "4.2" as a version 4.2 doesn't seem very
contentious. I also don't know what you mean by local git dep.

~~~
eddyb
> I also don't know what you mean by local git dep.

Presumably, the `git` URL for dependencies, in `Cargo.toml`, can point to a
local git repository. That should let you refer to a branch / commit of that
repository, other than the one currently checked out (which is what using a
`path` dependency would give you).

~~~
Manishearth
"local git dep" was a mistake, I meant "git dep", which can be used in a way
that approximates Go's import system if you use versioned tags.

(The "local" comes from it being in-house but that's confusing)

~~~
ben0x539
Ah, that's cool to hear. Which features of cargo versioning am I missing out
on then?

~~~
Manishearth
Actual semver based version resolution.

And yes, this _can_ be added with some ad hoc scheme that requires you to use
a certain kind of git tag, but that's not what people are asking for.

------
indentit
It will be nice when Cargo dependencies can use pre-built binaries instead of
having to compile the whole dep chain. One crate I contribute to has a 4 GiB
target folder and takes 20 mins to compile from scratch...

~~~
saghm
In the meantime, you can use sccache to at least save the time spent to
compile the same version of a crate more than once.

[https://github.com/mozilla/sccache](https://github.com/mozilla/sccache)

~~~
indentit
thanks for the recommendation. if I understand [1] correctly, this cache is
hosed when you upgrade rust?

[1]: [https://github.com/rust-
lang/cargo/issues/1139#issuecomment-...](https://github.com/rust-
lang/cargo/issues/1139#issuecomment-69350600)

~~~
the_duke
Yes, everything needs to be rebuilt with the new compiler after a ugprade, but
sccache still provides very valuable time savings when you work on multiple
Rust projects.

------
yash1th
I liked the concept of alternate registries in this release

~~~
pohl
I imagine this will unshackle some people who have been wanting to use Rust
within organizations.

~~~
steveklabnik
That is one of the main motivating factors!

------
fxfan
It feels like Rust is now 'stable'. Are there any major language related
things in the pipeline?

~~~
steveklabnik
The biggest one in the near future is async/await; you’ll see the precursors
land in the next few releases. There will also be a blog post soon outplaying
overall plans for the year, but const generics, GATs, and specialization are
the likely big-ticket items.

In general, this year of Rust will be about governance refactoring, finishing
off long-desired features like the ones above, and general polish. There isn’t
a lot of big plans for big new things coming anytime soon, more of finishing
what we’ve started and improving what we have.

~~~
mintplant
> GATs

Oh, fantastic! I realize I'm probably in a very specific minority here, but
I've been waiting on this one for literally years.

~~~
Grollicus
For people confused like me: GAT in this case means "Generic Associated Types"

[https://rust-
lang.github.io/rfcs/1598-generic_associated_typ...](https://rust-
lang.github.io/rfcs/1598-generic_associated_types.html)

~~~
tijs
Huh... Safari on iOS crashes on that page

~~~
steveklabnik
Interesting, it doesn’t crash for me!

------
adamnemecek
Rust is legit next gen, check it out today.

