Inline-Perl5 VS ccheck

Verbatim from the documentation at https://github.com/niner/Inline-Perl5: use Inline::Perl5;

> Perl 6 was treated as the successor of Perl 5 -- and that was the mistake. It meant Perl 5 started dying,

Perl 6 took a long time to make, but how much did that matter? What was Perl going to do about Rails, Clojure, Go, Rust, JS/TS, and more? The world of programming languages used to be a lot smaller than it is today.

> Perl 6 had a new different syntax.

Inline::Perl5 [3] allows running legacy Perl 5 code in Perl 6 codebases.

[1]: https://docs.raku.org/language/5to6-nutshell#Regular_express...

[2]: https://github.com/atweiden/voidvault

[3]: https://github.com/niner/Inline-Perl5

Perl can be faster and defiantly nicer to work with than PHP but it's nowhere near as fast as some other options like Rust but that has the downside of being much harder to write and get working. Perl has the advantage of being prepackaged with the base system and on OpenBSD it's kept up fairly well with the system version currently being only one version behind the latest yearly Perl release. There are some patches added to the OpenBSD version so updating it each year takes time. The easiest way that I've found for running Perl websites is to leave the system modules as is and to install all of the modules that you need into a users home directory with local::lib and cpanm. That way the system install isn't contaminated with the extra modules and it makes deploying easy because it's all contained in one users home directory that can be rsync'd or tar'd. Another nice thing is you get access to pledge and unveil through Perl so you can lock down your website even further. I've recently been trying out doing things in Raku (Perl6 was renamed to Raku in 2019). It's slower than Perl most of the time but I find Raku to be so much more beautiful and expressive that it's a joy to code with. There aren't as many modules available right now for Raku but it gives you access to all of CPAN through the Inline::Perl5 module.

Interfacing with Perl 5 with Inline::Perl5:

I'll be happy to dialog about this compatibility, but the key thing is to start with an open mind; a recognition that the original vision predated Parrot; and a recognition that Rakoons have never relinquished that original vision even while many of us are delighted that Perl folk are keeping Perl healthy as a separate thing in its own right.

To be clear, the realization of Larry's original vision is not constrained to interop with Perl. Raku has extraordinary potential, some already realized, for pan-language compatibility via its [Inlines](https://modules.raku.org/search/?q=inline).

The steady improvement of [the exemplar Inline](https://github.com/niner/Inline-Perl5) for the last 6 years; its evident maturing; its suitability as a solid blueprint for upgrading all the others; all of this bodes well for being able to use a lot of the world's best existing code from within Raku this decade, with Inline::Python quite plausibly shining in this regard within the next 2-3 years.

[1] https://stackoverflow.com/a/45181464/1077672

The most polished of the Inlines, namely Inline::Perl5 (github repo) enables devs to instantiate Raku objects that are instances of Raku classes that are sub-classes of Perl classes. It does this even though Perl has pluggable OO, essentially arbitrary OO, with dozens of different OO systems available, all of which differ from Raku's, for example having a variety of MRO linearizations that aren't C3. So such things can be done.

Grab a friends computer and amass a large batch of good known files, make sure they are of all different file formats. I am pretty sure you will be able to find entire archives of test data in different formats online, to really reproduce this I am going to assume it should be multiple gb in size. Make sure it contains jpg, videos, text files, pdfs, etc. Now write a script or use some tool like this (https://github.com/jwr/ccheck) to basically compute the sha256 checksum of every file in this test package and write it to a file. Take this package of files and copy them to as many media sources as you have access to, CD/DVDs are great, thumb drive, your laptop, a nas with ZFS (and ECC ram) would be amazing, probably throw it up on cloud storage just to be safe. I would then have the same script run as a cron job, maybe on your main machine to basically continuously check that checksums match their original value. As soon as you notice a checksum mismatch you will want to isolate that file and locate the same one across all the other systems and do a deeper inspection. Open it up in a HEX editor and do a bit by bit comparison to see were the corruption occurred and how bad it is. This will start to give you a better picture of what may be going on.

Here's my "me too" — I've been happily using rclone for things like photo archives (together with my small consistency checker to check file hashes for corruption https://github.com/jwr/ccheck). I also use Arq Backup with B2 as the destination. This gives me very reasonable storage costs and backups I can access and test regularly.

Perl is very well suited for certain tasks (not large software systems, but programs that process data). It is also one of very few languages/ecosystems where you can expect your code to work after >10 years. This is why I sometimes use it, for example my fs consistency checker (https://github.com/jwr/ccheck) was written in Perl specifically because it's a long-term tool and I would like to be able to run it on any system in 15 years.

Compare this long-term approach with the fires in Python or (heaven forbid) Node ecosystems, where things break all the time.

This sort of thing scares me. It's why I started running consistency checks on my important archives (like my photo library), which I keep backed up in multiple places. We tend to think that in a digital world bits are just bits and do not get corrupted — which is decidedly untrue.

I wrote my own consistency checker, as I wasn't happy with what was out there. I wanted it to be simple, and maintainable in the long term (>10 years horizon). See https://github.com/jwr/ccheck if you need something like this. I now update my checksums regularly and check for corruption.

Good point about bitrot. This is why I wrote ccheck.pl (https://github.com/jwr/ccheck) — I wanted to be able to check and detect bitrot in a way that depends on as little technology as possible.