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

111–120 of 149 posts

Re: Rust 1.34.0

#111

Post by arve0 »

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

> so you want the error type to be !.

For others having trouble to grok that sentence, ! is the never type. Should never happen. https://doc.rust-lang.org/std/primitive.never.html

Re: Rust 1.34.0

#112

Post by littlestymaar »

nicoburns wrote: post #96
eikenberry wrote: post #23

Earlier quoted context omitted.

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

This will probably be a big win if/when it lands [0] (adding the ability to replace LLVM with cranelift) [0]: https://github.com/bjorn3/rustc_codegen_cranelift/issues/381

This is only for debug builds though, cranelift. Isn't going to offer good enough performance for a release mode binary anytime soon (and probably never will).

Re: Rust 1.34.0

#113

Post by irishsultan »

steveklabnik wrote: post #56
cornstalks wrote: post #53

Earlier quoted context omitted.

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…

Currently when you have crate A with a deprecated function there is no warning until crate B tries to actually use that deprecated function, so clearly there is some place that crate B can look at to see whether a particular method is deprecated, there is even place for a note field that will get printed when crate B tries to access it.

Why would it not be possible to have some additional information that says "from rust edition 2021 onwards this is actually obsolete". Whether crate B merely gives a warning on compilation or an error then depends on crate B's edition.

Sure that means you can still use the method if you really want to (by using older editions), and it also means that if some of your dependencies are still on an older edition you can't prevent it from being used by them, but it would be a higher hurdle to accidental usage.

Re: Rust 1.34.0

#114

Post by hyperman1 »

steveklabnik wrote: post #105
nixpulvis wrote: post #104

Earlier quoted context omitted.

Just so I'm clear, are you saying then that it's not possible or desireble to have Rust 201X code link against Rust 201Y STD? Or would that work? Sorry if I'm not making my thought very clear.

It is not possible to have the standard library be different for different editions; it must be the same in all of them. There’s no #[cfg(edition=“”)] construct.

Can't there be a # [deprecate(untiledition=2018)] to solve this? The standard library contains all the old stuff but it becomes inaccessible in all editions after 2018.

Re: Rust 1.34.0

#115

Post by burntsushi »

littlestymaar wrote: post #112
nicoburns wrote: post #96

Earlier quoted context omitted.

This will probably be a big win if/when it lands [0] (adding the ability to replace LLVM with cranelift) [0]: https://github.com/bjorn3/rustc_codegen_cranelift/issues/381

This is only for debug builds though, cranelift. Isn't going to offer good enough performance for a release mode binary anytime soon (and probably never will).

If Cranelift makes debug builds much faster, then that's still a huge win. In my line of work, I do tend to compile things in release mode a lot purely because I often need to debug performance related problems, and for that, debug mode doesn't work. However, most of the test suites in my crates are built and run in debug mode. For example, the test suite for regex-syntax is fairly large, and it can take several seconds to build after making a change. Incremental compilation helped a lot with this, but there's still an annoying waiting period to run the tests. I'd be very happy to see Cranelift reducing the time it takes to run tests.

Re: Rust 1.34.0

#116

Post by phaylon »

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…

> We can’t get rid of it because we have a commitment to not breaking users’ code.

This is not really true though. The commitment is about publicly visible and crater-testable code. If you have your own code in-house, there isn't much guarantee unless all syntax/code you use is widely used in public as well. A known change in language grammar will be evaluated on its publicly visible impact, not on its general breakiness.

It's really disappointing to keep reading about guaranteed backwards-compatibility and then being told in RFC discussions that those don't exist.

Re: Rust 1.34.0

#117

Post by phaylon »

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.

I still feel that there is more to language compatibility than "Can rustc run it with the right setting". Rust 2018 is a new version, the fact that it's not called 2.0 is just semantics. And I still believe "version interopability" would have been a better term than misusing "backwards compatibility".

Re: Rust 1.34.0

#118

Post by steveklabnik »

hyperman1 wrote: post #114
steveklabnik wrote: post #105

Earlier quoted context omitted.

It is not possible to have the standard library be different for different editions; it must be the same in all of them. There’s no #[cfg(edition=“”)] construct.

Can't there be a # [deprecate(untiledition=2018)] to solve this? The standard library contains all the old stuff but it becomes inaccessible in all editions after 2018.

There can not.

Re: Rust 1.34.0

#119

Post by steveklabnik »

phaylon wrote: post #117
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.

I still feel that there is more to language compatibility than "Can rustc run it with the right setting". Rust 2018 is a new version, the fact that it's not called 2.0 is just semantics. And I still believe "version interopability" would have been a better term than misusing "backwards compatibility".

All existing code continues to compile as-is. That’s the definition of compatibility.

Re: Rust 1.34.0

#120

Post by steveklabnik »

phaylon wrote: post #116
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. This is not really true though. The commitment is about publicly visible and crater-testable code. If you have your own code in-house, there isn't much guarantee unless all syntax/code you use is widely used in public as well. A known change in language grammar will be evaluated on its publicly visible impact, not on its general breaki…

That’s not true. We have rules. some of those rules allow us to make changes based on that kind of thing, but it’s still done relatively little.
Post reply on HN