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

141–149 of 149 posts

Re: Rust 1.34.0

#141

Post by iopq »

MaulingMonkey wrote: post #110
zengid wrote: post #101

Earlier quoted context omitted.

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.

If there is no Internet, I'm going home. You can't seriously expect me to work without StackOverflow

Re: Rust 1.34.0

#142

Post by mlindner »

phaylon wrote: post #132
steveklabnik wrote: post #129

Earlier quoted context omitted.

1. Depends on the new project, of course. Just like any language. 2. Same thing. You can construct an example that breaks any language in existence. 3. Yes. 4. Yes. 5. Yes. 6. You’re using an idiosyncratic definition, so yes, it’s not the same. Backwards compatibility is about the same thing continuing to compile, not about changing things and expecting it to still compile; that’s forwards compatibility.

Once again something is at odds here. You give resounding "Yes" comments, but in the backwards compatibility discussions I had with language team members, those "Yes" comments were actually "not really our problem" answers. I also don't know how current code running in a future compiler is forward-compatibility. And the Rust guarantee only kind-of holds if you define "code" as "crate". Everything outside of or crossi…

When he says "version" he means "version". Are you taking "version" to mean "edition"? No matter how many version upgrades the rust compiler gets it will still compile 2015 edition (and 2018 edition) code.

Re: Rust 1.34.0

#143

Post by MaulingMonkey »

iopq wrote: post #141
MaulingMonkey wrote: post #110

Earlier quoted context omitted.

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.

If there is no Internet, I'm going home. You can't seriously expect me to work without StackOverflow

There's plenty I can work on without SO - that large backlog of things to document, for example. And just because your dev machines are on a locked down network doesn't mean you have no internet.

If perforce is down, however, I'm starting a riot ;)

Re: Rust 1.34.0

#144

Post by ben0x539 »

iopq wrote: post #141
MaulingMonkey wrote: post #110

Earlier quoted context omitted.

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.

If there is no Internet, I'm going home. You can't seriously expect me to work without StackOverflow

It's also nice to not have your CI/deploys depend on third-party sites being up.

Re: Rust 1.34.0

#145

Post by eddyb »

ben0x539 wrote: post #139
Manishearth wrote: post #127

Earlier quoted context omitted.

What do you mean by "versioning support for git dependencies"? We do support pulling in git dependencies based on a branch (I think tags work?) We also support checking the version of the git dep. It's fetching the dep that's the problem. Git has no uniform protocol for talking about versions, especially when it comes to resolving SemVer ("you asked for 0.2.1 but I also have 0.2.5, here you go") If you want go-style…

"Versioning support" is the wording from the release notes. I don't know why cargo's version resolution logic can't be applied to git dependencies, treating a tag like "v4.2" or "4.2" as a version 4.2 doesn't seem very contentious. I also don't know what you mean by local git dep.

> I also don't know what you mean by local git dep.

Presumably, the `git` URL for dependencies, in `Cargo.toml`, can point to a local git repository. That should let you refer to a branch / commit of that repository, other than the one currently checked out (which is what using a `path` dependency would give you).

Re: Rust 1.34.0

#146

Post by phaylon »

mlindner wrote: post #142
phaylon wrote: post #132

Earlier quoted context omitted.

Once again something is at odds here. You give resounding "Yes" comments, but in the backwards compatibility discussions I had with language team members, those "Yes" comments were actually "not really our problem" answers. I also don't know how current code running in a future compiler is forward-compatibility. And the Rust guarantee only kind-of holds if you define "code" as "crate". Everything outside of or crossi…

When he says "version" he means "version". Are you taking "version" to mean "edition"? No matter how many version upgrades the rust compiler gets it will still compile 2015 edition (and 2018 edition) code.

An edition is just another word for version. If the language were truly backwards compatible, you wouldn't have to tell tools like `rustc` which version/edition your code is written in.

Re: Rust 1.34.0

#147

Post by Manishearth »

eddyb wrote: post #145
ben0x539 wrote: post #139

Earlier quoted context omitted.

"Versioning support" is the wording from the release notes. I don't know why cargo's version resolution logic can't be applied to git dependencies, treating a tag like "v4.2" or "4.2" as a version 4.2 doesn't seem very contentious. I also don't know what you mean by local git dep.

> I also don't know what you mean by local git dep. Presumably, the `git` URL for dependencies, in `Cargo.toml`, can point to a local git repository. That should let you refer to a branch / commit of that repository, other than the one currently checked out (which is what using a `path` dependency would give you).

"local git dep" was a mistake, I meant "git dep", which can be used in a way that approximates Go's import system if you use versioned tags.

(The "local" comes from it being in-house but that's confusing)

Re: Rust 1.34.0

#148

Post by ben0x539 »

Manishearth wrote: post #147
eddyb wrote: post #145

Earlier quoted context omitted.

> I also don't know what you mean by local git dep. Presumably, the `git` URL for dependencies, in `Cargo.toml`, can point to a local git repository. That should let you refer to a branch / commit of that repository, other than the one currently checked out (which is what using a `path` dependency would give you).

"local git dep" was a mistake, I meant "git dep", which can be used in a way that approximates Go's import system if you use versioned tags. (The "local" comes from it being in-house but that's confusing)

Ah, that's cool to hear. Which features of cargo versioning am I missing out on then?

Re: Rust 1.34.0

#149

Post by Manishearth »

ben0x539 wrote: post #148
Manishearth wrote: post #147

Earlier quoted context omitted.

"local git dep" was a mistake, I meant "git dep", which can be used in a way that approximates Go's import system if you use versioned tags. (The "local" comes from it being in-house but that's confusing)

Ah, that's cool to hear. Which features of cargo versioning am I missing out on then?

Actual semver based version resolution.

And yes, this _can_ be added with some ad hoc scheme that requires you to use a certain kind of git tag, but that's not what people are asking for.

Post reply on HN