HN user
hn@kuber.com.ar
I don't think using an example that includes licensing, plenty of regulations governing drivers, the cars themselves and the built environment, enforcement, and plenty of research on the impact of passive infrastructure to make things safer (bollards, daylighting, raised pedestrian intersections, curbs, traffic lights, etc.) makes the case you seem to be trying to make.
There's a material difference on one taking risks for oneself and one taking risks where the brunt of the consequences fall on others.
that just lost his most popular open source project
As they state in the article, they started the migration a year and a half ago, something that happened a few weeks back would never come into the decision making process.
Are there any drawbacks to Rust editions?
That they can't (yet) be used to influence name resolution, so that they can't be leveraged for std API evolution. Work is being done on that front.
Older documentation that people find on the internet might be out of date and claim things that don't work but do on later editions, or vice-versa when trying out something that exists in a new edition in an older one. The mitigation for this is that if something is accepted in one edition but not another it must be taken into account in diagnostics so that the divergence is explained.
Does it make the compiler and other tools larger and more complex for each new edition?
With editions 2015, 2018, 2021 and 2024, there are ~120 branches in the compiler for changes in behavior, including for changing diagnostics to be more specific. For comparison, just rendering a type error for if else having different types in its arms checks for 4 different conditions. 120 checks is a drop in the bucket compared to the number of things the compiler already has to check for, and the growth rate is very manageable accruing in the double digits over the course of 4 years.
Are the migration tools always fully automatic, quick to execute, and flawless? Is any manual work, or expertise, required for upgrading in the worst case?
Fully automatic
For most code, it is. We spend the time creating migration lints that can change your code as part of your upgrade, and we test those using crater to detect the cases that people are using in public libraries. It is conceivable that a project in a private repo is using a pattern that wasn't detected through that, so an appropriate structured suggestion isn't emitted, but I haven't heard of such a situation.
quick to execute
it is as fast as cargo check
flawless
If the compiler produces a structured suggestion marked as machine applicable, and I believe all edition suggestions are, our level of confidence on them being the right thing to do to get the users' code to compile with the intended behavior is high. Bugs can happen, but don't recall seeing any "incorrect suggestion" in edition lints.
If I read a blog about Rust, and the blog forgot to mention which edition it uses for its code examples, can that cause any problems? Should I just skip the blog if it is old?
Differences between editions are actually quite small. You should be able to pick up The Book from 2015 and still learn the language. There are just things that The Book says don't work that now do, or features that were introduced that it doesn't talk about (both impl Trait and + use<'_> were introduced years later).
If I see an interesting repository that I would like to learn from, but it was written in an old edition that I do not want to learn the rules for, will I have to upgrade the codebase myself before learning from it, or should I just skip it?
Just use the old edition or upgrade, either thing will just work. You seem to think that the behavior divergences are bigger than they are, and anything that does diverge should be emitting a diagnostic telling you what code to write instead. These are things like "in a previous edition you had to borrow here, in the next edition you don't".
Are there any Rust projects that stay in an old edition for whatever reasons? How large a proportion of Rust projects that are still downloaded and used, are not on edition 2024? As an example, why are these popular projects still on Rust edition 2021?
Yes, there are crates that stay in older editions so that they can be used in projects that are frozen in time, like those that are shipped in some distros. (Edit: "frozen in time" as in "they won't update their toolchain", an earlier edition will always work on later ones due to backwards compat guarantees, the other way around of course can't.) To get a sense for it, serde which is a dependency that's almost inescapable is on 2021 edition and targets Rust 1.56. If a project decides that the impact on the ecosystem is bigger than the benefit of using newer language features, then it makes perfect sense to remain in an older edition.
https://lib.rs/stats sadly doesn't include statistics about the set edition, but it does have the graph at the bottom showing you rustc versions that the ecosystem supports, both for all crates and for the most recently updated. For reference, looking at releases.rs to refresh my memory, 1.31 is the introduction of edition 2018, 1.56 2021 and 1.85 2024. Those corresponds with the jumps in the chart. Note that looking at the chart it only tells you the likelihood of a random crate working on an older toolchain.
How much work is it to upgrade someone else's codebase to a newer edition?
Not any more than updating your own codebase (and if you're upgrading someone else's it is because you've taken ownership of that code), which is to say, not much.
Does upgrading a large project require intimate knowledge of that project in the worst case?
I can't think of any feature that would require that.
How do Rust editions and macros interact?
The compiler has the concept of `Span`s, which is the byte offset pointing at a piece of your code. Every node in the AST has a `Span`, and is subsequently used in every later stage. It's what is used to render the diagnostics. But they also carry "context" information: whether a token comes from a macro expansion. And they also carry edition information. This let's you have a macro defined in one edition and use it in another, and the behavior will be the correct one, regardless of how you mix them.
Does definition of macros or usage of macros make upgrading a Rust edition harder? If yes, how much harder in the worst case? Is upgrading always automatic?
The only situation I can think of is if there is a change in the parsing of macro arguments. For example, if Rust edition 20XX started parsing `A | B` as an anonymous enum type, then the macro call for `foo!(A | B)` would likely be parsed differently between editions <20XX and edition 20XX. That would be the kind of work you'd have to do. This has happened before in edition 2024, with expressions: https://doc.rust-lang.org/reference/macros-by-example.html#m.... In 2024 `expr` started not matching on `_` and `const {..}`. What was done then was introducing an `expr_2021` matcher with the prior behavior. When you update your edition to 2024 and apply the suggestions, your macro definitions get updated to use `expr_2021` instead of `expr`.
From your other comment
Reading between the lines, it is as if you consider there to be large problems with Rust editions, but you do not wish to make Rust, Rust editions, nor the programming language concept of editions, look bad.
Reading your lines, it is as if you already had the conclusion that editions are bad, and are looking for a confession.
Does upgrading a large project require intimate knowledge of that project in the worst case? How much work is it in the worst case?
I can't think of a situation where intimate knowledge of the project is needed.
How do Rust editions and macros interact? Does definition of macros or usage of macros make upgrading a Rust edition harder? If yes, how much harder in the worst case?
Answered earlier.
I think that everyone has the power to be wrong, but to be very wrong with convincing arguments, you must be smart.
A smart person can come up with post-hoc rationalizations that hold up under some scrutiny, to the point it is very hard to convince them otherwise. Add to that people who became famous or successful on the back of "being right" on some subject matter, getting used to "being right even in the face of overwhelming push back", and you have a recipe for very smart people being very wrong in very visible/loud ways.
And some programmers are so good that some issues are self-explanatory and they write good code to note a thing but don't write a test, because implementing the test is more expensive.
You don't write a test (just) to verify that your change fixed the issue, but to ensure it doesn't regress in the future after an unrelated refactor.
If anything comedy is an excellent way of learning a language: the use of double and triple entendres helps to quickly get exposed to alternate meanings and misunderstandings of words. Comedy aimed at learners or multilinguals can also help, plenty of anglos who learned Spanish can relate to "feeling pregnant" early on :)
Someone who can speak English on top of their mother tongue is already multilingual. Anecdotally, people who live anywhere close to a border in Europe tends to speak at least two languages, often more than two, regardless of class or profession.
In Latin America, most countries speak Spanish (with the obvious exception of Brazil and smaller colonies from the other European countries), so the every day pressure to learn another language isn't there and English becomes the "obvious" choice. I don't quite get why you seem to discount English entirely.
There's always been a Lingua Franca. It hasn't always been the same one. There will likely always be one.
You sure come across as calm and collected, looking for a good faith discussion...
In cycling threads you always have comments both telling cyclists to stay out of sidewalks and others telling cyclists that they "only* belong in sidewalks (and away from the road they drive in).
It is legal in some places, illegal in as many others, and has caveats almost everywhere (children are almost always allowed, in other places it is based on speed, etc.).
We can't individual responsibility our way out of systemic problems. Cyclists on sidewalks generally signals terrible bike infrastructure.
There are people on bikes that ride like an asshole. There are people on cars that drive like an asshole. Both cause (different levels of) risk for pedestrians. There's only so much we can do about assholes, social ostracism works only so far and social change is much harder to accomplish than modifying our built environment to reduce or eliminate conflict points.
As an aside, I've noticed people get startled when I'm on my bike stopped but balancing on my bike while I wait for then to cross. I think some people intuitively model bikes on the same category as cars, so being anywhere close causes them to react as if a car hard crept close.
Yes, that would be one way of doing it. You can model off of the Typed Builder pattern:
struct Builder<const A: bool, const B: bool> {
a: Option<u32>,
b: Option<u32>,
}
struct Val {
a: u32,
b: u32,
}
impl<const B: bool> Builder<false, B> {
fn set_a(self, a: u32) -> Builder<true, B> {
Builder {
a: Some(a),
b: self.b,
}
}
}
impl<const A: bool> Builder<A, false> {
fn set_b(self, b: u32) -> Builder<A, true> {
Builder {
a: self.a,
b: Some(b),
}
}
}
impl Builder<true, true> {
fn build(self) -> Val {
Val {
a: self.a.unwrap(),
b: self.b.unwrap(),
}
}
}
This is in effect a state machine, and when you have a type system more complex than C's you can encode state transitions in the type system (either by having state transitions explicitly return a new return type or by using sum types). You still need to architect the system to encode the invariants in types. No language will fix all logic bugs for free. But you can leverage language features to reduce their number.
Like DVD before it, Blu-ray includes region locking as a feature (but apparently ~70% of disks don't bother with it, notably Paramount and Universal don't). Non-locked disks are marked as ABC (A is the Americas and Asia, B is Europe/Africa/Aus/NZ, C is Russia/India/China).
The movie itself is generally encoded at a higher bitrate than what you can find in streaming or torrents.
The media includes bonus features that generally aren't available in streaming or torrents.
The media will not suddenly stop existing if some server breaks down, some company goes under or some contract expires.
The movie will not suddenly get "patched" with an AI-upscale or censored scene one day while watching it.
You can lend the media to someone else to watch without having to ask for permission to anyone else.
A lot of people talking about how displaying the flag at all could get somebody in Russia in trouble. You could see the increasing of the likelihood as helpful then, because the flag could always appear. By making it come up more often it communicates to the user that it can appear it gives a chance to the user to notice it in a "safe" situation and not use xsnow if they are in a situation where it could cause trouble for them. The existence of the flag is not quite mentioned at https://www.ratrabbit.nl/ratrabbit/xsnow/, and the site is loading too slow to see if it is shown in https://www.ratrabbit.nl/ratrabbit/xsnow/visuals/index.html.
This is a problem I'm seeing a lot of countries rushing full steam ahead. The age of a single physical ID that's only rarely needed and ubiquitous cash payments seems to be coming to an end. For anyone who travels a lot, migrants first settling in a place, or citizens abroad, this makes things even harder than they already were.
This kind of thing is one of the reasons crates.io distributes source only, and that published crate dependencies can't depend on other repositories (that might allow for that attack).
Feel free to point at 1 thing that the rust-lang didn't do because the Foundation blocked it.
Open source projects tend to be (and Rust certainly is) a showupocracy. Shit gets done when people that care about that shit does it. This means that important stuff that everyone agrees is important but not important enough for me to do, doesn't get done. And that some things end up being 80% solutions that scratch the itch of the person driving a project and progress stalls beyond that.
1) Trawl registry for packages owned by domains.
2) Note expired domains and register them yourself.
3) Supply chain compromise.
That, and not wanting people to fork out money for a domain as a requirement to participate in the ecosystem.
Not only does that not have anything to do with texting, but it has nothing to do with the roads.
From both the NYT video and their article:
And that increase is unique to the US. Most other wealthy countries haven't seen a similar surge, suggesting that possible culprits, like the raise of smartphones, don't tell the whole story.
---
If you hit someone with a tall-ass truck in Portugal, I'm pretty sure he's going to fall over just like he would in the USA.
How popular do you think the tall-ass trucks are in Portugal?
Or, put another way, 1% of every traffic fatality, or 8% of every pedestrian killed by cars. Those are not a small number being affected by a single variable.
Because the effects are explicitly called out for US roads and not other locales.
Could it be that the other differences are driven by differences in the built environment? Like narrower roads making people drive slower, or bollards, or alternatives to driving making it less likely to have people that shouldn't be driving doing so?
Also, 10% is a huge effect.
What would make non-Americans text less?
But everyone is building them not just American manufacturers
But for, and driven by, the American market.
I would hazard a guess that Silverados sold outside of US, Canada, Mexico and Australia can fit in a single parking lot.
I'm not a doctor and certainly not an oncologist.
The CDC mentions that not smoking and wearing condoms also lower the risk.
https://www.cdc.gov/cervical-cancer/prevention/index.html
Anecdotally people smoke less thant they uses to. Don't know what condom usage rates have done in the past quarter century.
I assume that this particular shot is not the only thing that has reduced cervical cancer deaths in women under 30.
Why would you assume that when presented with a study that tracks with long standing belief in the medical community that the HPV vaccine works?
https://www.thelancet.com/journals/lancet/article/PIIS0140-6...
The BBC article had that more comparable information: https://www.bbc.com/news/articles/c621z28z138o
Between 2020 and 2024, no cervical cancer deaths were recorded in women aged 20 to 24 - the first time that had happened over a five-year period.
Without vaccination, around 23 deaths would have been expected.
Note the first chart in the link showing the historical trend for the 20-24 cohort since 2000 plumetting from 25 to 0.