• 34 Posts
  • 765 Comments
Joined 3 years ago
cake
Cake day: November 24th, 2023

help-circle












  • In the case of France there’s two possible broken laws (not a lawyer btw):

    • If the glasses wearer upload the video/photo online, you are one of the primary subject of the frame (aka not just in he background), and didn’t consent to being on the internet, you can sue.

    • Companies must legally ask you for your concent to collect personal and identifying information. If the video/photo is sent to meta for big data/ai training, they must ask for consent

    Edit: “primary subject” is kinda vague and may change depending on the context. If you do a VLOG and someone does something funny in the background, not aware of the camera, and the video is re-uploaded to only feature the guy, then it becomes the primary subject, and must be asked for concent





  • I actually use it to run krita, prism launcher when the Minecraft mood peek in, inkscape, MusicBrainz picard, Alistral, peazips, libre Office.

    Aka, anything that I don’t use enough to warrant opening my config and adding them in (and forgetting when I do open my config.

    Although krita is currently being installed through flatpack because nixpkgs ship broken alpha versions…



  • Most of the time, async tutorial makes you learn tokio, not async. If your program can run with only tokio::main, then you learned async. If not, you learnt tokio (except if you are spawning a future that should never stop)

    For example, my pet project only uses tokio::main to do async stuff. The only instances of tokio::spawn is make sure some SQLite transactions get polled to completion. I do need to replace them with a proper mechanism now that sqlx supports smol-rs


  • A lot of the time it’s not about options. It’s about not messing up the async pattern.

    If you have something that either:

    • requires a lot of CPU time
    • requires to run permanently, independently to the caller’s future polling. Then you can spawn it on a global tokio executor.

    If not, just use future polling tricks like the futures::join!() macro or a stream with .buffered(). It won’t be slower. The bottle neck is IO. Not the program.

    Personally I even try to replace the heavy reqwest library with ureq + blocking, and it works perfectly and compiles faster (you can see that in the api_bindium crate)






  • Tbh the borrow checker isn’t a problem for 75% of cases. If you actually need the performance/memory optimization then yes you will have to deal with it… Otherwise just .clone()

    And if you find the borrow checker annoying in async rust, that’s mostly a tokio issue. Look into smol-rs as it offers alternatives

    If you want real cons…

    • Compile times
    • easy build time arbitrary code execution
    • trait bounds spaghetti