Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 1.34.0

blog.rust-lang.org

Post reply on HN
Print view View original

51–60 of 149 posts

Re: Rust 1.34.0

#51

Post by geogriffin »

mintplant wrote: post #38
steveklabnik wrote: post #8

Earlier quoted context omitted.

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…

> 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.

I have ran into a couple places I needed GATs while writing abstractions, without realizing beforehand it'd lead to needing GATs. This is especially true with lifetimes, which I'm not used to thinking about as part of an abstraction.. I think it will naturally open up doors for everyone without anyone necessarily realizing it apriori.

Re: Rust 1.34.0

#52

Post by indentit »

saghm wrote: post #36
indentit wrote: post #15

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...

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

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-...

Re: Rust 1.34.0

#53

Post by cornstalks »

steveklabnik wrote: post #42
cornstalks wrote: post #40

Earlier quoted context omitted.

> There will not be a Rust 2.0. Isn’t Rust 2018 effectively Rust 2.0 (since it introduced new keywords and requires changes to old code if a user opts in to Rust 2018)? So the function could be made unsafe in Rust 2021 (or whatever it’s called).

No, because it is opt in. All existing code keeps compiling as-is. The standard library cannot change with editions for exactly this reason. It’s compiled with a particular edition, like any other crate, and so can’t work differently in different editions.

You’re conflating Cargo, Rust (the language), and std/core libraries, and rustc (the compiler). This is one of the difficult parts of Rust and when people say “there won’t be a Rust 2.0” they don’t clarify which part they’re talking about.

Given the tight relationship of all of these parts (despite each one being capable of being individually versioned), it would seem feasible to add a cfg attribute for the Rust edition, and then make the function unsafe if the user had opted in to Rust 2021 (or whatever).

Re: Rust 1.34.0

#54

Post by Grollicus »

mintplant wrote: post #38
steveklabnik wrote: post #8

Earlier quoted context omitted.

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…

> 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.

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

https://rust-lang.github.io/rfcs/1598-generic_associated_typ...

Re: Rust 1.34.0

#55

Post by the_duke »

indentit wrote: post #52
saghm wrote: post #36

Earlier quoted context omitted.

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

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-...

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.

Re: Rust 1.34.0

#56

Post by steveklabnik »

cornstalks wrote: post #53
steveklabnik wrote: post #42

Earlier quoted context omitted.

No, because it is opt in. All existing code keeps compiling as-is. The standard library cannot change with editions for exactly this reason. It’s compiled with a particular edition, like any other crate, and so can’t work differently in different editions.

You’re conflating Cargo, Rust (the language), and std/core libraries, and rustc (the compiler). This is one of the difficult parts of Rust and when people say “there won’t be a Rust 2.0” they don’t clarify which part they’re talking about. Given the tight relationship of all of these parts (despite each one being capable of being individually versioned), it would seem feasible to add a cfg attribute for the Rust edit…

I am not conflating anything. The compilation model of the language does not permit such a thing, independently of implementations of any of those pieces. This is a crucial aspect of the design of the language and the edition system.

Think of it this way: crate A uses edition 2015. Crate B uses edition 2018. There’s only one copy of the standard library. It can’t be compiled both ways.

If, in theory, we let you have multiple copies of the standard library, maybe that could work, but that’s not possible nor desirable for a host of reasons.

Re: Rust 1.34.0

#57

Post by sanxiyn »

steveklabnik wrote: post #39
sanxiyn wrote: post #37

Earlier quoted context omitted.

I think another big item is const fn and compile time function evaluation.

That’s under “const generics”, but yes. Technically const fn is already stable, it’s just expanding what it can do, generally, so we tend to talk about them as one thing.

In my mind const generics and const fn is a completely different feature. Proof: you can use const fn without any const generics.

Re: Rust 1.34.0

#58

Post by gbear605 »

steveklabnik wrote: post #50
korethr wrote: post #46

Earlier quoted context omitted.

>> We can’t get rid of it because we have a commitment to not breaking users’ code. Totally the correct way to go about it, IMO. Thus my comment about deprecation. >> There will not be a Rust 2.0. >> Note that upon using it, you’ll get a warning, so everyone will at least be notified. :/ That I've mixed feelings about. Why not? Is it because of the fiascos between Perl 5/6 and Python 2/3? Deprecations and warnings ab…

It’s partially that, it’s partially that systems people are very conservative, and it’s partially Rust’s own history before 1.0. People do view major breaking changes very differently these days due to those specific situations, and some people still think Rust changes daily. Systems languages tend to have a stability timeline of “forever.” Rust does have a strong commitment to safety, but not an absolute commitment…

Would it be reasonable to introduce a compiler flag that is enabled by default to mark this category of warnings as errors, or would even that need a major version bump?

Re: Rust 1.34.0

#59

Post by steveklabnik »

sanxiyn wrote: post #57
steveklabnik wrote: post #39

Earlier quoted context omitted.

That’s under “const generics”, but yes. Technically const fn is already stable, it’s just expanding what it can do, generally, so we tend to talk about them as one thing.

In my mind const generics and const fn is a completely different feature. Proof: you can use const fn without any const generics.

Sure. They rely on the same internals, which is why they tend to be wrapped together when talking about them as a feature, that’s all I’m saying.

That also doesn’t change that const fn is stable today, so saying “it’s coming this year” muddies the waters a bit. You have to explicitly say “the capabilities of const fn will be expanded”, or you risk the wrong impression.

Re: Rust 1.34.0

#60

Post by Buttons840 »

gbear605 wrote: post #58
steveklabnik wrote: post #50

Earlier quoted context omitted.

It’s partially that, it’s partially that systems people are very conservative, and it’s partially Rust’s own history before 1.0. People do view major breaking changes very differently these days due to those specific situations, and some people still think Rust changes daily. Systems languages tend to have a stability timeline of “forever.” Rust does have a strong commitment to safety, but not an absolute commitment…

Would it be reasonable to introduce a compiler flag that is enabled by default to mark this category of warnings as errors, or would even that need a major version bump?

Already possible I believe: https://doc.rust-lang.org/rustc/lints/levels.html
Post reply on HN