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

121–130 of 149 posts

Re: Rust 1.34.0

#121

Post by steveklabnik »

irishsultan wrote: post #113
steveklabnik wrote: post #56

Earlier quoted context omitted.

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…

> Why would it not be possible

There may be a way in which it is possible, but it is not currently possible. We’d have to have a different design.

Re: Rust 1.34.0

#122

Post by nox_ »

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…

Cf. `try` becoming a keyword, when there are hundreds of calls to a method named `try` in Servo, one of the largest Rust projects in existence.

Re: Rust 1.34.0

#123

Post by phaylon »

steveklabnik wrote: post #120
phaylon wrote: post #116

Earlier quoted context omitted.

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

I've had many discussions and much pain about this topic. Can you tell me what I wrote that was specifically wrong?

If backwards compatibility is guaranteed, turbofish cannot be "fixed". I can't find the link currently, but from my reddit post on this discussion the crucial quote from a language team member was:

> Our bar for doing backwards compatibility breaks has never been soundness fixes. We have in the past done changes given future-compatibility warning with lints and then made such changes without an edition.

The turbofish discussion also contains this quote:

> This RFC technically amounts to a backwards incompatible change without using the edition mechanism. However, as the RFC notes, a crater run was made and the syntax was not encountered at all.

Re: Rust 1.34.0

#124

Post by phaylon »

steveklabnik wrote: post #119
phaylon wrote: post #117

Earlier quoted context omitted.

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.

Can I copy a module from an old project into a new crate and it will always work without adjustments?

What about code examples from StackOverflow, or Github issues? Will these work without adjustments in my local project?

Will a future syntax highlighter always be able to highlight the code in my old Rust articles?

Will future tooling always be able to read my current code?

Can I make editor macros and snippets that will keep working in every version of Rust?

If I can write code in one crate and it will compile, but then write it again in another, newer crate and it doesn't, then it isn't backwards compatible. Plus, as noted above, "code will keep compiling" isn't even a guarantee that the language team gives you.

Re: Rust 1.34.0

#125

Post by Manishearth »

jithesh wrote: post #11

Now that alternate registries to crates.io is available, hoping artifactory could add support for rust... - https://www.jfrog.com/jira/browse/RTFACT-13469

Note that Rust has supported mirroring ("source replacement") for a while now. https://doc.rust-lang.org/nightly/cargo/reference/source-rep...

This feature is for alternate registries that _supplement_ crates.io

Re: Rust 1.34.0

#126

Post by steveklabnik »

nox_ wrote: post #122
phaylon wrote: post #116

Earlier quoted context omitted.

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

Cf. `try` becoming a keyword, when there are hundreds of calls to a method named `try` in Servo, one of the largest Rust projects in existence.

However, none of that affects a crate until it opts into the new syntax. So everything keeps building just fine.

Re: Rust 1.34.0

#127

Post by Manishearth »

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…

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 import resolution use a local git dep. That works fine. It's specifically when you want all the features of cargo's version resolution -- which git doesn't understand -- you need to use a custom registry.

Re: Rust 1.34.0

#128

Post by steveklabnik »

phaylon wrote: post #123
steveklabnik wrote: post #120

Earlier quoted context omitted.

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.

I've had many discussions and much pain about this topic. Can you tell me what I wrote that was specifically wrong? If backwards compatibility is guaranteed, turbofish cannot be "fixed". I can't find the link currently, but from my reddit post on this discussion the crucial quote from a language team member was: > Our bar for doing backwards compatibility breaks has never been soundness fixes. We have in the past don…

Yes, there are some lang team members that want to change this policy, but it is not the current policy. Those changes were for soundness fixes.

You can see how controversial that RFC was, and for that exact reason.

Re: Rust 1.34.0

#129

Post by steveklabnik »

phaylon wrote: post #124
steveklabnik wrote: post #119

Earlier quoted context omitted.

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

Can I copy a module from an old project into a new crate and it will always work without adjustments? What about code examples from StackOverflow, or Github issues? Will these work without adjustments in my local project? Will a future syntax highlighter always be able to highlight the code in my old Rust articles? Will future tooling always be able to read my current code? Can I make editor macros and snippets that…

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.

Re: Rust 1.34.0

#130

Post by phaylon »

steveklabnik wrote: post #128
phaylon wrote: post #123

Earlier quoted context omitted.

I've had many discussions and much pain about this topic. Can you tell me what I wrote that was specifically wrong? If backwards compatibility is guaranteed, turbofish cannot be "fixed". I can't find the link currently, but from my reddit post on this discussion the crucial quote from a language team member was: > Our bar for doing backwards compatibility breaks has never been soundness fixes. We have in the past don…

Yes, there are some lang team members that want to change this policy, but it is not the current policy. Those changes were for soundness fixes. You can see how controversial that RFC was, and for that exact reason.

No, that wasn't for soundness fixes. This is from the discussion surrounding syntax changes like turbofish or chained if-let bindings.

Can you point me towards an authoritative post in the turbofish discussion that says that it can't happen because of backwards-compatibility changes? Because before it was locked it seemed that the language team wanted to go ahead.

I've been repeatedly told by language team members that the policy you're promising people doesn't exist. I would really appreciate it if there was further clarification.

Post reply on HN