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

101–110 of 149 posts

Re: Rust 1.34.0

#101

Post by zengid »

ben0x539 wrote: post #99

> People maintaining proprietary/closed-source code cannot use crates.io, and instead are forced to use git or path dependencies. This is usually fine for small projects, but if you have a lot of closed-source crates within a large organization, you lose the benefit of the versioning support that crates.io has. I'm surprised that making people run their own registries is the preferred way to address this, instead of…

I don't think it's unheard of though: my employer has their own Nuget package server for internal packages.

Re: Rust 1.34.0

#102

Post by steveklabnik »

ben0x539 wrote: post #99

> People maintaining proprietary/closed-source code cannot use crates.io, and instead are forced to use git or path dependencies. This is usually fine for small projects, but if you have a lot of closed-source crates within a large organization, you lose the benefit of the versioning support that crates.io has. I'm surprised that making people run their own registries is the preferred way to address this, instead of…

There’s a ton of people who want a variety of solutions for a ton of things; many people require on-prem for this kind of thing. We’re building out a variety of solutions, this one happened to land first.

Re: Rust 1.34.0

#103

Post by ben0x539 »

steveklabnik wrote: post #102
ben0x539 wrote: post #99

> People maintaining proprietary/closed-source code cannot use crates.io, and instead are forced to use git or path dependencies. This is usually fine for small projects, but if you have a lot of closed-source crates within a large organization, you lose the benefit of the versioning support that crates.io has. I'm surprised that making people run their own registries is the preferred way to address this, instead of…

There’s a ton of people who want a variety of solutions for a ton of things; many people require on-prem for this kind of thing. We’re building out a variety of solutions, this one happened to land first.

Sure, but they have probably on-prem git then anyway, now they need two on-prem things?

Re: Rust 1.34.0

#104

Post by nixpulvis »

steveklabnik wrote: post #93
nixpulvis wrote: post #91

Earlier quoted context omitted.

I think it could be an edition thing though... just say Rust 2019 will not allow `Command::before_exec`. By turning on edition 2019 you've accepted the new brakages that it imposes on you, and this is one of them. Never mind the fact that the function is still a symbol in the STD library. I understand if this is too much complier magic, though it seems like the correct idea to me anyway. Am I missing something? P.S.…

Please see the discussion below; I already discussed this at length :)

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.

Re: Rust 1.34.0

#105

Post by steveklabnik »

nixpulvis wrote: post #104
steveklabnik wrote: post #93

Earlier quoted context omitted.

Please see the discussion below; I already discussed this at length :)

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.

Re: Rust 1.34.0

#106

Post by nixpulvis »

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.

Gotcha, thanks for taking the time to explain.

I hope I didn't come off as being to negative about the change. Warnings are still a pretty good solution here.

Re: Rust 1.34.0

#107

Post by akiselev »

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

And a funny addendum for context (from the same r/rust thread as the above quote):

> The never type [is] for computations that don't resolve to a value. It's named after its stabilization date.

Re: Rust 1.34.0

#108

Post by steveklabnik »

nixpulvis wrote: post #106
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.

Gotcha, thanks for taking the time to explain. I hope I didn't come off as being to negative about the change. Warnings are still a pretty good solution here.

It’s all good!

Re: Rust 1.34.0

#109

Post by [deleted] »

mintplant wrote: post #38
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…

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

[deleted]

Re: Rust 1.34.0

#110

Post by MaulingMonkey »

zengid wrote: post #101
ben0x539 wrote: post #99

> People maintaining proprietary/closed-source code cannot use crates.io, and instead are forced to use git or path dependencies. This is usually fine for small projects, but if you have a lot of closed-source crates within a large organization, you lose the benefit of the versioning support that crates.io has. I'm surprised that making people run their own registries is the preferred way to address this, instead of…

I don't think it's unheard of though: my employer has their own Nuget package server for internal packages.

It can be useful to run your own package server even if you're not creating your own packages. You can use this to keep a curated list of packages that your team finds commonly useful / has audited / has had the license blessed by legal / ???, or to be productive during an internet outage, slowdown, or lockdown, etc.
Post reply on HN