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

31–40 of 149 posts

Re: Rust 1.34.0

#31

Post by sanxiyn »

korethr wrote: post #20

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 v…

There has been other instances. One is as_mut_slice, which resulted in 1.15.1 patch release. https://blog.rust-lang.org/2017/02/09/Rust-1.15.1.html Another is borrow checker bug, which resulted in 1.26.2 patch release. https://blog.rust-lang.org/2018/06/05/Rust-1.26.2.html

Re: Rust 1.34.0

#32

Post by sjroot »

pimeys wrote: post #13
vvillena wrote: post #6

Earlier quoted context omitted.

Async/await is probably the next "big" feature.

We are really waiting for it in Prisma and might need to start working with the unstable soon until it lands.

Is Prisma releasing a client library for Rust?

Re: Rust 1.34.0

#33

Post by steveklabnik »

korethr wrote: post #20

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 v…

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.

Re: Rust 1.34.0

#34

Post by [deleted] »

steveklabnik wrote: post #33
korethr wrote: post #20

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 v…

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…

[deleted]

Re: Rust 1.34.0

#35

Post by steveklabnik »

eikenberry wrote: post #23
pjmlp wrote: post #9

Earlier quoted context omitted.

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

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

We can only speculate about the lower bounds of compile times, but making things faster takes a lot of work. Rustc is a huge codebase, and making general leaps requires large architectural changes. We’ll just keep chipping away. It’ll take some time.

There has been a lot of progress, it’s just been slow and steady. For example, since the first of 2018: https://perf.rust-lang.org/compare.html?start=2018-01-01&end...

Re: Rust 1.34.0

#36

Post by saghm »

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

Re: Rust 1.34.0

#37

Post by sanxiyn »

steveklabnik wrote: post #8
fxfan wrote: post #3

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

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…

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

Re: Rust 1.34.0

#38

Post by mintplant »

steveklabnik wrote: post #8
fxfan wrote: post #3

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

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.

Re: Rust 1.34.0

#39

Post by steveklabnik »

sanxiyn wrote: post #37
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…

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.

Re: Rust 1.34.0

#40

Post by cornstalks »

steveklabnik wrote: post #33
korethr wrote: post #20

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 v…

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…

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

Post reply on HN