Rust 1.34.0 • Hacker News Board

Re: Rust 1.34.0

#11

Post by jithesh » Thu, Apr 11, 2019, 6:33 PM UTC

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

Re: Rust 1.34.0

#12

Post by pohl » Thu, Apr 11, 2019, 6:37 PM UTC

yash1th wrote: post #5

I liked the concept of alternate registries in this release

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

Re: Rust 1.34.0

#13

Post by pimeys » Thu, Apr 11, 2019, 6:42 PM UTC

vvillena wrote: post #6

fxfan wrote: post #3

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

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.

Re: Rust 1.34.0

#14

Post by Datenstrom » Thu, Apr 11, 2019, 6:44 PM UTC

trzeci wrote: post #2

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

Personally I am very excited about TryFrom, I have been waiting for that forever it seems.

Re: Rust 1.34.0

#15

Post by indentit » Thu, Apr 11, 2019, 6:44 PM UTC

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

Re: Rust 1.34.0

#16

Post by adamnemecek » Thu, Apr 11, 2019, 6:44 PM UTC

Rust is legit next gen, check it out today.

Re: Rust 1.34.0

#17

Post by steveklabnik » Thu, Apr 11, 2019, 6:46 PM UTC

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

See below, that is planned. Can’t guarantee a timeframe though.

Re: Rust 1.34.0

#18

Post by steveklabnik » Thu, Apr 11, 2019, 6:47 PM UTC

pohl wrote: post #12

yash1th wrote: post #5

I liked the concept of alternate registries in this release

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

That is one of the main motivating factors!

Re: Rust 1.34.0

#19

Post by whatshisface » Thu, Apr 11, 2019, 6:47 PM UTC

pjmlp wrote: post #9

trzeci wrote: post #2

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

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

We will soon have async/await syntax which will replace some of the use case of callbacks, and (I assume) reduce the borrow bookkeeping tedium.

Re: Rust 1.34.0

#20

Post by korethr » Thu, Apr 11, 2019, 6:48 PM UTC

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?