The very same type of mistakes happens in file systems even without URIs being involved. Directory traversal checks look simple but sooner or later need hard-to-understand symlink following rules. Enforcing processor policy has terrible portability there (it even only became practical on Linux with landlock), but nonetheless I think it’s preferable.
Not mixing URI parsers is a good advice for when processor policies are unavailable – but let’s try to make them available more often.

@snaggen I think the better lesson than “don’t mix URI parses” here is “don’t LBYL, rely on EAFP”. Many “Look before you leap” (LBYL) schemes are subject to variations of time-of-check/time-of-use errors. It’s preferable to not sanitize input, but tell the processor what the policy on processing is; when it comes to a violation, it’s easier to ask forgiving (i.e. report the error) than permission (EAFP).

@0xsaksham @snaggen Last polls I saw, the #RustLang hashtag (it’s case sensitive, but capitalization helps for accessibilisy) was a tad more popular than #Rust due to the latter’s ambiguities.

@jvisick That process is completely intransparent to anyone approaching this without preexisting knowledge of that Lemmy instance. Do you know who runs that account? They should really make a note in its metadata.

Last time I checked, GTK could do laziness well where it matters (lists /trees), but admittedly that was some time ago.

My impression is that they are using WASM primarily from the browser, which really is a no-std shaped environment. Using WASI there would be as much of a band-aid as is emscripten.

Coroutines are one means of implementing async; the way they are implemented in Rust is more like building a state machine out of the async function. It can still be mapped to coroutines, and there are probably crates that use async and macros to make coroutines usable on stable, but the effort to have a stable language feature is still ongoing, with https://lang-team.rust-lang.org/design_notes/general_coroutines.html giving the overview.

@Vorpal Having a free implementation of 802.15.4 is very good news. The initialization blob is still a downside compared to Nordic chips, but it’s good progress and shows that they’re interested in doing it right. I’m hoping it’ll be blob-free eventually for all their radios.