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

61–70 of 149 posts

Re: Rust 1.34.0

#61

Post by steveklabnik »

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?

It’s not really feasible. Maybe in an extreme case, but this just isn’t one. We have done this for fixing language soundness holes, but it is extremely rare. The spirit of the law matters as much, if not more, than the letter.

Re: Rust 1.34.0

#62

Post by steveklabnik »

Buttons840 wrote: post #60
gbear605 wrote: post #58

Earlier quoted context omitted.

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

It’s a policy question, not a technical question. We can absolutely do it technically.

Re: Rust 1.34.0

#63

Post by servilio »

pjmlp wrote: post #25
servilio wrote: post #21

Earlier quoted context omitted.

Why binary dependencies, what for?

Compile speed, not compiling the same dependencies all over the time. Many commercial use cases require distribution of binary libraries, Rust community might care about winning those customers, or just let them go and leave them to keep using the languages that fulfil such use cases.

> Compile speed, not compiling the same dependencies all over the time.

Sounds like caching these would be a simpler but solution.

> Many commercial use cases require distribution of binary libraries [...]

Good use case, and in this case another cache would solve the issue as well. Defining a protocol for binary caches and being able to add your own could solve this very well. The same solution could help solve the previous one too.

BTW, if you are in either case, have you looked into Nipxkgs[1]? They might be able to do both, the basic capabilities are there, not sure if the Rust infrastructure[2] already provides it.

[1] https://nixos.org/nixpkgs [2] https://nixos.org/nixpkgs/manual/#users-guide-to-the-rust-in...

Re: Rust 1.34.0

#64

Post by benesch »

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…

With all due respect, I do think you're conflating the way things are with the way things have to be.

glibc has a similar commitment to never breaking user code, and yet symbols have been removed from glibc! The trick is to use "symbol versioning"; code compiled against old versions of glibc is transparently rewritten to use the old versions of symbols, while code compiled against new versions is rewritten to use the new versions of the symbols. [0][1]

You can imagine something similar for the Rust standard library, whereby both the unsafe and safe versions are provided, and packages are transparently rewritten to use the correct version based on their specified edition. You don't need two copies of the stdlib; just of the symbols that have diverged. In this case, you wouldn't even need two versions of the symbol in the resulting binary, since the addition of `unsafe` doesn't change the codegen of the function, but merely restricts what code is accepted by the compiler.

It's true that this would require some serious shenanigans in the stdlib, but it's a tractable problem. It's also, in my mind, quite acceptable for the standard library to play games like this, since the compiler, the language, and the stdlib are always going to be tightly coupled, and the complexity can be shielded from users.

All that said, it sounds like the list of deprecated stdlib features is nowhere near long enough to justify adding this kind of complexity.

[0]: https://gcc.gnu.org/wiki/SymbolVersioning

[1]: Note that symbol versioning is kind of a quagmire, but that's because it's seriously underdocumented and practically no developers are aware that it exists. The idea itself is sound.

Re: Rust 1.34.0

#65

Post by lewisinc »

Datenstrom wrote: post #14
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.

Agreed! I definitely have a handful of hand-rolled `try_from` definitions that I'm excited to erase from existence.

Re: Rust 1.34.0

#66

Post by ainar-g »

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. 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 there were things removed from C++ specifications as well; please correct me if I am wrong. Did Rust decided to never break stdlib compatibility because the mechanism of editions was considered from the start, or was this rather ad-hoc?

[1]: https://tip.golang.org/doc/go1compat#expectations

Re: Rust 1.34.0

#67

Post by steveklabnik »

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…

We do reserve the right to make changes for soundness holes. In theory, you could argue that this is a soundness hole, and so we can remove it.

We have to do such things extremely judiciously though. Users can only tolerate so much breakage, even if you say “we did say we reserved the right to do this.” This API is just so rarely used that it was judged not a good time to pull the “technically we are allowed to do this” card.

Re: Rust 1.34.0

#68

Post by burntsushi »

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.

> 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
    maxmem  702 MB
    faults  0
That's a >3x wall-clock speedup over the past 2.5 years on a cold start. That's pretty good.

Re: Rust 1.34.0

#69

Post by Perceptes »

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, but it was finally decided to simply use this temporary `Infallible` type, which would be mostly forwards compatible with the never type itself.

I've followed the issue closely because it's one of the features used in Ruma, my Matrix homeserver and libraries. In fact, for the library components of the project, it was the last unstable feature. With the stabilization of these APIs, I'll finally be able to release versions of the libraries that work on stable Rust. This will happen later today!

Re: Rust 1.34.0

#70

Post by seeekr »

Grollicus wrote: post #54
mintplant wrote: post #38

Earlier quoted context omitted.

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

This RFC has an explanation of Higher-Kinded Types that enabled me to understand what is meant by HKTs for the first time. Unexpected & awesome! Thanks for linking!
Post reply on HN