[HN Gopher] Follow up to "Changing the rules of Rust"
___________________________________________________________________
Follow up to "Changing the rules of Rust"
Author : killcoder
Score : 69 points
Date : 2023-09-18 13:04 UTC (9 hours ago)
(HTM) web link (without.boats)
(TXT) w3m dump (without.boats)
| [deleted]
| tempodox wrote:
| [flagged]
| skavi wrote:
| Reader View works perfectly fine for me on iOS 16.6.1
| zellyn wrote:
| Looks fine in Firefox, Chrome, and Safari here. The red
| comments are a little hard to read, but aren't terribly
| important. If this truly is a contender for "worst contrast
| ever" for you, then something in your setup is messing things
| up.
|
| I guess it _is_ traditional to have a comment complaining about
| contrast on hackernews though, so... well done?
| karmakaze wrote:
| Yes, red text on black is a terrible combo.
| Georgelemental wrote:
| Looks fine to me, white text on very dark gray background (and
| works with Firefox on Android reader mode). Maybe there is an
| issue with your setup?
| atoav wrote:
| Option-Command-F5 to invert the screen colors.
| meepmorp wrote:
| The contrast was good for me (ever more presbyopic) and it
| worked fine in Safari's reader mode.
| Georgelemental wrote:
| Follow-up from the author on Reddit:
|
| > After a few more minutes thought:
|
| > When you upgraded `foo` from 2021 to 2024, `cargo fix` would
| have had to add a `Leak` bound to the parameter on the method.
| Removing that bound would be a breaking change. Therefore, the
| issue could actually be in `bar`. But this also highlights
| another issue: it's a breaking change to start allowing `!Leak`
| types to be passed to any generic method of a trait, even with
| this firewall. That means like `Iterator::map` can't take a
| closure which has a `!Leak` type in its state, for example.
|
| > But also what is the issue in `bar` if so? In 2021 edition, the
| interface of any trait you impl coming from a 2024 edition crate
| is tested under 2024 edition somehow? Does that work? What does
| the error message say to you?
|
| > My point is not that this is impossible, but that its not easy
| at all.
|
| https://www.reddit.com/r/rust/comments/16ltgn1/comment/k145i...
| [deleted]
| killcoder wrote:
| The discussion of the previous post is here:
|
| https://news.ycombinator.com/item?id=37545040
| dingi wrote:
| [flagged]
| baq wrote:
| 1943: built a computer
|
| 2023: still figuring out a strong theory of how to program the
| damn thing safely
| stouset wrote:
| There is nothing in the article discussing syntax changes.
| [deleted]
| [deleted]
| davidhyde wrote:
| > The first crate, foo, is in the 2024 edition, and defines a
| trait with a single generic method. The second crate, bar, is in
| the 2021 edition, depends on foo, and implements that trait for
| its own type.
|
| I wasn't aware that an early edition of rust can reference crates
| for a later edition. It doesn't seem that terrible to prohibit
| this (Probably some very good reason to counter this though!).
| Editions give us the privilege of not having to constantly update
| crates that don't really need to be changed whenever a new rust
| version comes out. If I do end up making changes to my crate and
| updating my dependencies then I don't see it as such a pain to
| update the Rust Edition of my crate if said dependencies also
| happen to use a later edition.
|
| I do, however, see one downside to this though and experienced it
| first hand in c# .net standard where it was way better to use the
| earliest version possible of .net standard for your library to
| maximise compatibility with things that use it. No incentive to
| use a later standard and therefore there was stagnation. May not
| be applicable because you normally distribute compiled binaries
| but food for thought.
| proto_lambda wrote:
| > It doesn't seem that terrible to prohibit this (Probably some
| very good reason to counter this though!)
|
| The simple reason is that the whole point of editions is that
| you absolutely do not have to worry about which one you choose.
| They are entirely localized to your crate, and code written in
| any edition can interact with code written in any other
| edition. With your suggestion, updating the edition used by a
| library crate would suddenly make it unusable for all code
| using an older edition.
| satvikpendem wrote:
| Then what's the point of editions, if the crates are forward
| and backward compatible?
| kevincox wrote:
| The point is that crates written against different editions
| are forwards and backwards compatible, but how the crate is
| written isn't.
|
| So Rust can make a "breaking" change in a new edition. This
| isn't actually breaking because you need to "opt-in" by
| updating to the new edition. This allows many "breaking"
| changes without actually breaking the ecosystem. Each crate
| can upgrade whenever they feel like it (possibly never) and
| they can make this decision independently of any other
| crates.
|
| For example look at the breaking changes introduced in the
| 2021 edition: https://doc.rust-lang.org/edition-
| guide/rust-2021/index.html. Each item on the left menu is a
| breaking change that was able to be shipped due to the
| edition system.
|
| You are right that the edition system does create limits
| for what can be changed. However this is because doing so
| would have downsides. Notably if older editions couldn't
| depend on newer editions I may need to migrate my crate to
| a new edition in order to update a dependency to get a
| security fix. Edition updates are typically quite easy but
| it was still a conscious decision that they aren't ever
| required, unless you want to take advantage of the new
| features added in that edition.
___________________________________________________________________
(page generated 2023-09-18 23:02 UTC)