• 0 Posts
  • 6 Comments
Joined 27 days ago
Cake day: March 12th, 2025
  • ferric_carcinization@lemmy.mltoLinux@lemmy.ml•Building native packages is complicated | Packaging Anubis as native packagesEnglish
    0·
    7 days ago

    It might be pretty difficult to implement the work part of proof of work without JS in a practical way. Of the three languages available on the web, HTML, CSS & JS (+ WebAssembly, which requires a bit of JS IIRC & would probably not be available) JS is the only one that allows you to perform the work in a sane way. (It might be possible to use CSS magic with remote resources, but that has its own problems if it’s even possible.)

    It would be possible to use a dedicated program or another website to perform the work, but it would be far from seamless to users.

  • ferric_carcinization@lemmy.mltoLinux@lemmy.ml•How do you backup?English
    0·
    20 days ago

    I haven’t used either, much less benchmarked them, but the performance differences should be negligible due to the IO-bound nature of the work. Even with compression & encryption, it’s likely that either the language is fast enough or that it’s implemented in a fast language.

    Still, I wouldn’t call the choice of language insignificant. IIRC, Go is strongly typed while Python isn’t. Even if type errors are rare, I would rather trust software written to be immune to them. (Same with memory safety, but both languages use garbage collection, so it’s not really relevant in this case.)

    Of course, I could be wrong. Maybe one of the tools cannot fully utilize the network or disk. Perhaps one of them uses multithreaded compression while the other doesn’t. Architectual decisions made early on could also cause performance problems. I’d just rather not assume any noticeable performance differences caused by the programming language used in this case.

    Sorry for the rant, this ended up being a little longer than I expected.

    Also, Rust rewrite when? :P