Rust backwards compatibility
Rust backwards compatibility
Posted Aug 19, 2024 20:37 UTC (Mon) by lukegb (subscriber, #106233)Parent article: FreeBSD considers Rust in the base system
Obviously the time crate regression itself is out of scope here if we're considering that FreeBSD base would not have any dependencies on crates from crates.io, but it's also worth noting that any FreeBSD base breakage that would have resulted from this would have been completely invisible to the Rust regression tooling because it's not on crates.io.
Posted Aug 19, 2024 20:52 UTC (Mon)
by josh (subscriber, #17465)
[Link] (1 responses)
That said, one huge advantage of the FreeBSD way of doing things over most other software distributions is that they have all the code in one place and can patch all software in the same commit that upgrades tools.
Posted Aug 21, 2024 9:46 UTC (Wed)
by dev-ardi (guest, #172609)
[Link]
Out of curiosity, who of the many Joshes in the project are you?
Posted Aug 19, 2024 21:09 UTC (Mon)
by atnot (guest, #124910)
[Link] (11 responses)
Posted Aug 20, 2024 5:35 UTC (Tue)
by roc (subscriber, #30627)
[Link]
Posted Aug 20, 2024 6:17 UTC (Tue)
by ralfj (subscriber, #172874)
[Link] (9 responses)
He's doing a lot of work, and some mistakes. If you only look at what happens in Rust when there's an outcry, of course you will only see his mistakes.
Posted Aug 20, 2024 10:19 UTC (Tue)
by khim (subscriber, #9252)
[Link]
That's the trouble with extremely talented people: they are so accustomed to being right when their opponents are wrong that, in rare cases where they are actually wrong, it takes absolutely ridiculous effort to convince them that yes, this time they are wrong for real. I guess one just have to accept that our our shortcomings are a continuation of our strengths and spend that effort when needed.
Posted Aug 20, 2024 13:25 UTC (Tue)
by atnot (guest, #124910)
[Link] (7 responses)
It wouldn't be this harsh if this was completely unrelated to him and out of his control. Just the best we could do. But that's not the case, because what happened instead is that he deliberately, secretly sabotaged the addition of reflection to the language out of an unknown mixture of racism and powertripping at the thought of his kingdom of macros becoming slightly less relevant. And then spent more than half a year having other, lovely people with more integrity than him (some of which I consider friends) take the fall for him.
So instead of a great feature which everyone could use right there in the language and would, not coincidentally, make a lot of these things so trivial to implement they wouldn't even need to be a library, we get this. And all everyone ever says you can't criticize the guy because he's selling the "top 10 crates" cure to the situation he created.
If this sounds bitter, yeah. Correct.
Posted Aug 20, 2024 14:16 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (6 responses)
Sounds spicy. Can I read about this somewhere in more detail?
Posted Aug 20, 2024 16:01 UTC (Tue)
by khim (subscriber, #9252)
[Link] (5 responses)
I think this is the best you may find. The question of who exactly did what and when to whom is still not answered (and I'm not sure it can be answered, at this point).
Posted Aug 20, 2024 16:56 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (2 responses)
I must be missing additional context.
Posted Aug 20, 2024 17:16 UTC (Tue)
by khim (subscriber, #9252)
[Link] (1 responses)
The keynote was about ongoing work on the way to add reflection to Rust. And that work was stopped after they keynote fiasco. Whether that was deliberate sabotage or not, but the end result: no one works on reflection in Rust anymore.
Posted Aug 20, 2024 17:18 UTC (Tue)
by intelfx (subscriber, #130118)
[Link]
That's a damn shame.
Posted Aug 20, 2024 16:58 UTC (Tue)
by atnot (guest, #124910)
[Link] (1 responses)
Here's my TL;DR of the timeline:
And that's where things remain today.
(But if you have way, way, too much time on your hands here's the most recent thing I know of that attempts to summarize what happened: https://dragon.style/@pyrex/111005018693053136)
Posted Aug 25, 2024 23:09 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Summary of the summary:
1. People pull strings to win. Sad but business unfortunately as usual. Even the best language in the world is still affected by politics and non-technical issues.
2. The person who pulled the strings was racist because... the "victim"[*] is black and the evil guy is white. Wow. If you found anything tangible that I missed then please correct me. If not, that's sheer and obvious defamation.
Ironically, the racism accusation comes after a truckload of other, more substantiated accusations that are 10 times enough to explain what is supposed to have happened.
There is nothing tangible to prove that the guy is _not_ racist either. I naively assumed that in such a void, everyone had a right not to be called racist but maybe I don't spend enough time on this new social media thing.
[*] quotes because that term is normally used for bigger life problems than being rejected from Rust.
Posted Aug 19, 2024 21:57 UTC (Mon)
by roc (subscriber, #30627)
[Link] (3 responses)
In the past I don't think this kind of regression would have been tolerated. Maybe something has changed.
Posted Aug 19, 2024 22:17 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
Note that "technically permitted" is not necessarily the same thing as "a good idea in practice." The RFC itself warns about this distinction. What appears to be happening now is that the Rust folks are reassessing whether the RFC is a good enough standard, or if there should be more elaborate rules for cases like this. Which is the normal and healthy thing you would expect to see a language's developers do in a situation like this.
Tangent: IMHO the existence of documents like this also demonstrates why SemVer's use of MUST instead of SHOULD was misguided. If you purport to forbid doing something that is not actually required for your standard to "work," then people are just going to introduce more definitions to explain why they're not really doing the thing you thought you prohibited. SemVer's operative MUSTs (i.e. the ones that people actually care about, not the obvious "don't use irregular numbering that makes no sense" MUSTs) are de facto SHOULDs in the context of Rust, and in practice, I suspect that most other projects which purport to follow SemVer also treat those MUSTs as very strong SHOULDs. But at least Rust is honest about doing so (and clearly defines the boundaries of doing so).
Posted Aug 21, 2024 16:28 UTC (Wed)
by mrugiero (guest, #153040)
[Link] (1 responses)
Posted Aug 22, 2024 12:45 UTC (Thu)
by khim (subscriber, #9252)
[Link]
The real funny thing is that not releasing version Means you can rely on version 0.5.13 of SQLx to be compatible with version 0.5.0 of SQLx, but version 0.8.0 of SQLx may require changes to the code. It's almost like difference between two major version, in fact on technical level it's exactly the same. Difference lies in social contract: crates with major version larger then zero usually promise to support certain version for some time, while crates with major version zero usually ask you to change the code if you want bugfixes. IOW: if you use old version of zero-version crate then your code wouldn't, suddenly, break when new version is released, but if you want to file a bug then you need to first upgrade to the latest version. That's closes to the difference between normal and LTS kernels than to anarchy without any SemVer support.
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
- thephd et.al. get strongly encouraged by a wide array of people to work on reflection
- They receive a sudden reversal of some decision out of the blue and nobody wants to be responsible for it or tell them what it's about. They smell a rat and demand a technical explanation of why the work was not considered up to scratch.
- Receiving no such explanation they nope out, correctly detecting the telltale signs of someone pulling strings against them behind the scenes (a thing any black person living in the US will be keenly attuned to)
- Big drama, everyone blames someone else, it was nobody's fault, it was actually legitimate concern, etc. (fasterthanlime post happens here)
- Lots of people step down from various roles as a result of letting this happen and/or protecting the person who did it, which nobody names.
- Much later, word gets out that dtolnay was in fact pulling strings behind the scenes and just let everyone take the fall for him. He responds to this with a bizarre github gist full of verifiable bs. And then reaches out to thephd asking for how to resolve this. They, once again, demand a technical critique of their work.
- Dtolnay can't offer it. thephd reaffirms that they will not return to Rust until such a technical critique is made. This has not happened even after david's name was known, evidencing thephd's hunch that such a critique never existed. (https://cohost.org/ThePhD/post/7169013-weird-question)
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
Rust backwards compatibility
1.0 in a Rust world, doesn't free you from confines of SemVer: cargo just assumes that if the major version of some crate is zero then next number is the actual major version.