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

81–90 of 149 posts

Re: Rust 1.34.0

#81

Post by ComputerGuru »

swsieber wrote: post #76
Perceptes wrote: post #69

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

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

> 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

Re: Rust 1.34.0

#82

Post by BalinKing »

Thaxll wrote: post #80
burntsushi wrote: post #68

Earlier quoted context omitted.

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

The memory doubled?

Not sure if it’s the case here, but decreasing time complexity can often require a corresponding increase in space complexity.

Re: Rust 1.34.0

#84

Post by pcwalton »

Thaxll wrote: post #80
burntsushi wrote: post #68

Earlier quoted context omitted.

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

The memory doubled?

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.

Re: Rust 1.34.0

#85

Post by burntsushi »

Thaxll wrote: post #80
burntsushi wrote: post #68

Earlier quoted context omitted.

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

The memory doubled?

I wouldn't be surprised if it was due to paralellism, e.g., compiling multiple code units in parallel or even better parallelism at the Cargo level. My stat is just the maximum memory usage reported at any point in time. But that's just a guess. ripgrep itself uses more memory when using parallelism, just because of having more buffers.

Re: Rust 1.34.0

#86

Post by Jach »

ainar-g wrote: post #66
steveklabnik wrote: post #33

Earlier quoted context omitted.

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…

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

C, C++, Common Lisp, and others have the benefits of an ANSI standard. Any compiler that says it supports the standard, supports it, regardless of compiler version or breaking changes in future standards. My C89 code will continue to work as long as a compiler supports that standard. Worse comes to worst, I can create my own implementation.

When you don't have a standard, you're left at the mercy of languages promising not to break stuff. If they do anyway, your options aren't as clean as just sticking to the older standard.

Re: Rust 1.34.0

#87

Post by nixpulvis »

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…

I personally feel like this falls clearly into the soundness hole catagory and should be allowed to be removed in a breaking way. I understand the desire to avoid breaking changes, but soundness issues like this chip away at what "safety" in Rust really means.

I think I'd expect to see warnings about the existing safe method being deprecated for a while, then it's complete removal at the time of another edition of Rust. Users of older versions of Rust can still use the removed function, but newer editions ban it.

This could be implemented as a reserved STD function list in the compiler if it must, since as you've mentioned we only have one STD lib atm.

Re: Rust 1.34.0

#88

Post by tspiteri »

GolDDranks wrote: post #28
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…

I wonder if they could after some time make it a "harder" deprecation; fail by default, and enabled only with an `#[allow]` annotation.

That would still break existing code: you have to change it for it to compile. And if you are going to change the code, it makes more sense to change the code to use pre_exec in an unsafe block than to use before_exec with an #[allow] annotation.

Re: Rust 1.34.0

#89

Post by steveklabnik »

nixpulvis wrote: post #87
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…

I personally feel like this falls clearly into the soundness hole catagory and should be allowed to be removed in a breaking way. I understand the desire to avoid breaking changes, but soundness issues like this chip away at what "safety" in Rust really means. I think I'd expect to see warnings about the existing safe method being deprecated for a while, then it's complete removal at the time of another edition of Ru…

Yes, as I said below, this is technically a thing we’re allowed to remove. Maybe someday we will. But we want to be careful.

Editions cannot make this kind of change, as also discussed below.

Re: Rust 1.34.0

#90

Post by 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-embedded/wg/issues/218#issuecomment-...

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.

Post reply on HN