Announcing Rust 1.11 | Hacker News Reader

Announcing Rust 1.11

blog.rust-lang.org

321 pointseslaught92 comments

Most importantly, the finished MIR revolution [0] will finally allow developers to focus on new exciting features, like ergonomic "impl Trait" [1], incremental compilation, or even the beginnings of Gc [2].

[0]: https://github.com/rust-lang/rust/pull/35764

[1]: https://github.com/rust-lang/rust/issues/34511

[2]: http://manishearth.github.io/blog/2016/08/18/gc-support-in-r...

> even the beginnings of Gc [2]

I was surprised to hear this and immediately thought "but why would you do such a thing!?" but I read the blog post and I'm impressed with the forethought that I certainly lacked. This is freaking genius.

AFAIK the MIR isn't on in 1.11 yet.

Yes, the stable release is lagging behind a bit, as it must be stable :)

That's correct, and why it was described as "the groundwork for" in this announcement.

Adding to_degrees() and to_radians() methods to f32 and f64 seems a little out of place, considering f32 and f64 are numbers without units. Why not include to_celsius() and to_fahrenheit() then?

Technically radians and degrees are dimensionless since they're ratios.

More to the point, though, is 'sin' and 'cos' are also methods, so having 'to_degrees' as a method seems reasonable.

Also, methods can be called with a function-like syntax, if you prefer:

    let r = f32::to_radians(5.0);
    
    let x: f32 = 5.0;
    let r = x.to_radians();

Shouldn't to_degrees and to_radians be part of a trait that f32 and f64 (and potentially other types) both implement, rather than being independent methods directly on f32 and f64?

Over the course of Rust's history, we have tried a number of times to get a trait hierarchy for numerics working, and it's always had problems. It's still a general open question.

I'm not suggesting a trait hierarchy for numerics, or a numerical tower. I'm purely suggesting putting individual methods or families of related methods into independent traits that each numeric type can implement. For instance:

    trait AngleConversion {
        fn to_degrees(&self) -> Self;
        fn to_radians(&self) -> Self;
    }

    impl AngleConversion for f32 {
        ...
    }

    impl AngleConversion for f64 {
        ...
    }

Operators like + and / already live in traits; why not put methods like these into traits as well, so that users can implement them for their own types (variable-precision floats, decimal floating point, etc)?

(As a side note, can a trait accept an AsRef<Self> in place of &self or self, so that register-sized objects implementing Copy don't need to use &self?)

As always, it's a tradeoff. Doing something as a trait is hard for its own reasons, at least in a standard library. Should radians and degrees be two traits, or one? If we pick wrong, are we okay with having that be stable forever?

Plus, since you can define your own traits, if this is functionality you need, you can just do it, and delegate to the inherent implementation for those two types.

We really do need to spend time on the numerics APIs though... I would love to pour some time into it again... just figuring out how to fit it in with all the other stuff I'm doing :(

I agree with the caution though. This takes time to get right.

The advantage of the current approach is that you can just define the traits you need in your crate, and the standard library does not have to stabilize unrefined interfaces.

I'm kinda weirded out by non-idempotent `to_foo()` methods...

So you can write

  value.to_radians().to_radians()

then? Weird.

Why? It's like pressing some button on scientific calculator twice. It's just a function.

These are the sorts of things type systems try and help avoid. Having the same crappy behavior as an '80s scientific calculator isn't exactly something to strive for.

That said, this is probably such a simple use that it's not worth having Degree and Radian classes in core.

Not really. I'm for strong typing, but not all mathematical concepts need to be a separate type. Should we have separate type for 'ratio' or 'real' or 'natural'? A radian is still represented as a number -- specifically a float, generally. This is more like Rust building out a standard Math library, a la Node.js or C/C++. Since rust is aiming at being a C replacement, I can understand why they'd include this.

It's a number associated with a unit. Making it a distinct type, even when the underlying representation is a float, makes it harder to make mistakes by substituting or combining units inappropriately.

This sort of stuff works really well when the type system incorporates units of measure directly (usually as some kind of generic type parameter). F# is a good example.

This is similar to having 3D position and direction in different types (e.g. point and vector instead of a generic 4-component vector). It looks nice in theory, and it is 'type safe' (e.g. you can't add 2 points, only point+vector or vector+vector), but writing real-world code with this is awkward.

Some languages do include "natural" in their numeric tower.

Hm, I'm likely thinking about it wrong, but I don't see why you'd even necessarily want a type system to stop that... Is it not similar to running, which I expect to work?:

    var s1 = "blah"
    var s2 = s1 as string
    var s3 = s2 as string

edit: Nevermind, I guess you're wanting like types for units of measurement. Sounds interesting.

Most readers would expect the "as string" statement to be idempotent; to_radians() isn't, because it's actually implicitly degrees_to_radians(). If your type system isn't going to keep track of which quantities were already degrees, then your function names should be a little more explicit about the fact that value.to_radians().to_radians() is both converting and reinterpreting, twice.

I see, I had missed that detail. Thanks for the explaining it!

Is the best way to solve that problem by introducing "unit measurement" types that are more specific than general numerical types? Or is there another way? Or even a general concept I can go read about? Thanks in advance!

Last I checked, scientific calculators had degrees and radians as modes. This made pressing the button idempotent, an appropriate compromise given the lack of types.

Probably because those are normal mathematical operations to convert between different units of measurement for the same abstract thing in math.

I'm enjoying that bors is a named contributor. Finally the recognition our robot overlords deserve

Bors does a lot of work every release! Bots are people too :p

Wow~~~~Just see it.

crate-type = ["cdylib"] sounds really interesting!

"With this PR a "hello world" cdylib is 7.2K while the same dylib is 2.4MB, which is some nice size savings!" [1]

1. https://github.com/rust-lang/rust/pull/33553#issue-154141126

> We’re excited about features like MIR becoming the default and the beginnings of incremental compilation, and the 1.11 release has laid the groundwork.

The changelog is silent about these two points, so does it mean that -Z orbit defaults to "on" in 1.11 and -Z incremental can be used in 1.11?

I think it's on in the 1.12 beta, which was also published today. The orbit switch was switched on during the cycle that just ended, so I'd be surprised if it was already on on the stable.

Additionally, 1.13 removes the [old AST backend](https://github.com/rust-lang/rust/pull/35764) so MIR will be on by default.

Not merged yet, but removing drop flags is a major milestone. So awesome

Congratulations and thank you to the Rust team/community!

As always, I've updated my Docker image: https://hub.docker.com/r/jimmycuadra/rust/ (available on quay.io also if you prefer that)

The tags "latest" and "1.11.0" are now both Rust 1.11.

Good job! Why don't you support beta/nightly versions? Here's mine btw: https://hub.docker.com/r/scorpil/rust/

It's been discussed before. Here's an example of an attempt at doing that and discussion about why it wasn't accepted: https://github.com/jimmycuadra/docker-rust/pull/4

From the documentation of Iterator.sum https://doc.rust-lang.org/std/iter/trait.Iterator.html#metho...

> When calling sum and a primitive integer type is being returned, this method will panic if the computation overflows.

I thought Rust's strategy for numeric overflow is to panic only in debug mode. Has that strategy changed or is this a special case?

This _might_ just be an oversight, would you like to file a bug? If not, I can.

I don't think it's an oversight; the implementation calls `checked_add` and `checked_mul` explicitly -- https://github.com/rust-lang/rust/blob/1744c46e47434d8c0b63a...

You go ahead.

https://github.com/rust-lang/rust/issues/35807

> Build scripts can now emit warnings.

Nice! This one bit me pretty bad when first getting into Rust so it's nice to see it improved.

Quick Rust noob question: I heard there's a new book in writing. Should I wait for it or read the current one?

Author here!

You can check out the new book here: http://rust-lang.github.io/book/

We're working on the new book because the old book isn't as good as it could be, but that doesn't mean it's bad: a lot of people have told me that they really love it. But I am hyper-critical of my own work, and there's a lot of ways you can improve something that's already good :)

As you can see, the new book isn't really far enough along to fully teach you Rust yet. I would maybe check out the new material first, and then just read the existing book afterwards.

By the way, you've helped me multiple times in multiple mediums - it appears you're both very active and very productive. It is very appreciated, thank you.

(I'm sure some random strangers thank you doesn't mean much, but it's hard to not notice your work. And i just wanted to make sure i expressed my appreciation.)

No, it helps a lot, and I appreciate it. Thanks.

Cool! One thing I hope you can fix: That page hijacks cmd-option-{left, right}, which are (or can be) used in Safari for tab switching. Very annoying. Apps that hook the arrow keys should always check for whether shift/alt/ctrl/meta keys are also down, to avoid trampling on people's keyboard shortcuts.

> Apps that hook the arrow keys should always check for whether shift/alt/ctrl/meta keys are also down, to avoid trampling on people's keyboard shortcuts.

The majority of pages shouldn't intercept up/down either, because that breaks the ability to scroll the page. Only pages that will never involve scrolling (such as whole-screen web apps or games) should do that.

Left/right can be OK, as long as you never expect your page to need horizontal scrolling.

Ah! I will file a bug against mdbook tomorrow, Thanks.

FWIW, I am one of those people who really loves it. I'm excited for a new book, but I feel it's worth saying that the old one has been not only instrumental in my efforts to learn Rust, but also a flat-out enjoyable read. Thank you!

I am really, really glad to hear it. Thank you :)

Would you also make builds available in epub/mobi?

Hopefully someday, though the new book will also be published by No Starch, so if you don't want to wait, I'll bet you can buy one from them (proceeds going to charity).

And html as well.

HTML has always and will always be available.

Fantastic, thanks!

Read the rustbyexample book: http://rustbyexample.com/hello.html

If you ask me it's better. Assuming you are not new to programming.

Amazing Rust announcements (core and third party) have been coming in constantly for quite a while now.

So much win.

Does the addition of MIR have any immediate positive impact on compile times or binary optimization?

Servo's compile time went down by about 20% or so. We think that it's because non-zeroing drop enabled LLVM's memcpy optimizer (which is currently pretty fragile pending the MemorySSA rewrite) to do a better job.

As with any large-scale change, it depends. We did testing across the ecosystem before turning it on by default (that will be in a future release, not 1.11) and there weren't any major regressions, at least. Some small improvements are there.

For example: https://github.com/rust-lang/rust/pull/34096#issuecomment-22...

It doesn't seem like it -- the benefits will be developed over time, for example MIR-based optimization passes.

Can't wait for the bottled homebrew for it to drive it around. It's still at 1.10.

--HEAD just hangs forever on 'Checking out branch master' for some reason for me.

Any specific reason for using Homebrew? Rustup [1] works great.

https://www.rustup.rs

I did just that now. Wasn't even aware of it. Main page of Rust offered me pkg only.

Yes, rustup.rs is still technically in beta. We will make it the official, recommended way when it's ready.

(I've been using it daily for months and it works well for me)

It's listed in Downloads https://www.rust-lang.org/en-US/downloads.html That's how I found it. Didn't know rustup.rs was affiliated domain, so I didn't want.

It says right on it that "rustup is an official Rust project. ", though I can see why you might not trust that. If you ask in IRC, most people will point you to it first these days.

Of course it says, but I can also state I am a Queen of England. Should've been stated on rust-lang.org that it's legit! :)

Yeah. It does link to the rust-lang-nursery org, but I totally understand the hesitancy. Then again, it is just in beta, so it's not as hyper-important right this moment for everyone to use it.

Reply on news.ycombinator.com