But I wanted to showcase the power of ${ignore}, as it can be cleaner and/or more powerful in some cases where extra patterns and recursing expansions can get messy and hard to track.
First of all, unsafe famously doesn't disable the borrow checker, which is something any Rustacean would know, so your intro is a bit weird in that regard.
And if you neither like the borrow checker, nor like unsafe rust as is, then why are you forcing yourself to use Rust at all. If you're bored with C++, there are other of languages out there, a couple of which are even primarily developed by game developers, for game developers.
The fact that you found a pattern that can be alternatively titled "A Generic Method For Introducing Heisenbugs In Rust", and you are somehow excited about it, indicates that you probably should stop this endeavor.
Generally speaking, I think the Rust community would benefit from making an announcement a long the lines of "If you're a game developer, then we strongly advise you to become a Rustacean outside the field of game development first, before considering doing game development in Rust".
Post the original code to !rust@programming.dev and point to where you got stock, because that AI output is nonsensical to the point where I'm not sure what excited you about it. A self-contained example would be ideal, otherwise, include the crates you're using (or the use statements).
Federation is irrelevant. Matrix is federated, yet most communities and users would lose communication if matrix.org got offline.
With, transport-only distributablity, which i think is what radicale offers, availability would depend on the peers. That means probably less availability than a big service host.
Distributed transport and storage would fix this. a la something like Tahoe-LAFS or (old) Freenet/Hyphanet. And no, IPFS is not an option because it's generally a meme, and is pull-based, and have availability/longevity problems with metadata alone. iroh claims to be less of a meme, but I don't know if they fixed any of the big design (or rather lack of design) problems.
At the end of the day, people can live with GitHub/GitLab/... going down for a few minutes every other week, or 1-2 hours every other month, as the benefits outweigh the occasional inconvenience by a big margin.
And git itself is distributed anyway. So it's not like anyone was cut from committing work locally or pushing commits to a mirror.
I guess waiting on CI runs would be the most relevant inconvenience. But that's not a distributable part of any service/implementation that exists, or can exist without being quickly gravely abused.
Until the parallel compiler feature (-Z threads=<n>) stabilizes and becomes more complete.
It's also always worth mentioning that the choice of linker is important. Using mold or lld can significantly speed things up in some use-cases.
Beyond that, codegen-units and lto profile options are also important.
And finally, for development purposes, the code generator is important, as cranelift provides much faster compile times, but resulting binaries are not as optimized as LLVM-generated ones.
Definitely don't use axum, which provides a simple interface for routes by using derived traits. Their release cycle is way shorter, which makes them more dangerous, and they're part of the same github user as tokio, which means they're shilling their own product.
How can the total number of all Desktop Linux users or devices be known to anyone?
The fact of the matter is, none of these stats actually measure the number of users. Most of them are just totally flawed guestimates based on what is often limited web analytics data collected by them.
In fact, not even the developers of a single distribution can guess the number of people/devices using/running that specific distribution. A distribution like Debian for example has mirrors, and mirrors to some mirrors, and maybe even mirrors to some mirrors to some mirrors. So if Debian developers can't possibly know the number of Debian users, do you think OP's site knows the total number of Desktop Linux users?
And let's not get into the fact that the limited data they collect itself is not even reliable. View desktop site on your Android phone's browser. Congratulations! Now you're a desktop Linux user. No special user-agent spoofing add-on needed. You're even running X11. Good choice not following the Wayland fad too soon.
As predicted, none of you got what I was referring to. Although simply doing the search would have got you there.
The EMBAG law stipulates that all public bodies must disclose the source code of software developed by or for them, unless precluded by third-party rights or security concerns.
Also as predicted, this escape hatchet exists for skipping compliance.
Actually, I may have been too finicky about this myself.
Since I often write my own wrapping serialization code for use with non-serde formats, I didn't realize that chrono::DateTime<chorono_tz::Tz> wasn't serde-serializable, even with the serde feature enabled for both crates. That's where the biggest problem probably lies.
In the example, using chorono_tz::Tz, and only converting to-be-serialized values to FixedOffset would probably put better focus on where the limitations/issues actually lie.
Like do you really not see this as something that shouldn’t be mentioned in a comparison between these crates? You must recognize the difference between what you’re doing and just plopping a Zoned in your struct, deriving Serialize and Deserialize, and then just letting the library do the right thing for you.
If that's how it was framed in the comparison, it would have been fine. But my original objection was regarding the Local+FixedOffset example which, IMVHO, toys, if ever so slightly, with disingenuity (no offense or aggression intended, I'm a fan).
I think you also glossed over some of my other points. How do you write your serialization code using Chrono? Does it work with both chrono-tz and tzfile?
Why is the full presentation non-ephemerally stored instead of (timestamp, timezoe)?
Is the use-case strictly limited to checking the validity of a future date that was generated with assumptions based on current tzdata info? That's valid, but quite niche I would argue.
And one can adjust the wrapper to have (timestamp, timezone, assumed_offset_at_ts). But yes, it can be argued that it's not idiomatic/automatic/antecedently obvious anymore.
What I meant is, someone who wants to serialize zoned dt info using chrono can basically send a timestamp and a timezone name on the wire, e.g. (1721599162, "America/New_York").
It's not built-in support. It's not a single human-readable string containing all the needed info that is being sent on the wire. But it does provide the needed info to get the correct results on the other side. And it's the obvious solution to do, and it's doable with trivial wrappers. No Local+FixedOffset usage required. And no wrong results inevitable.
That's fine. I didn't look at the code, but from what I gather, Jiff serializes the timezone name (not detailed tz info). chrono users would communicate the same thing, but it's not built-in functionality in the dt type itself.
The example I referred to however may imply that chrono users would be inclined do the wrong thing, and get the wrong result as a sequence.
(humble personal opinion bit) It feels like it's a case where the example was pushed a bit extra to fit into the "jump into the pit of success/despair" reference. A reference many, young and old, wouldn't recognize, or otherwise wouldn't care for anyway.
You scared me for a moment there. I don't know why you thought that.
Needless to say, even with the first example, metavar expressions are not strictly needed here, as using a second pattern and recursing expansions would work.
But I wanted to showcase the power of
${ignore}, as it can be cleaner and/or more powerful in some cases where extra patterns and recursing expansions can get messy and hard to track.