Community-written annual Advent calendar of posts about the Raku programming language, covering its features, Unix philosophy, and practical uses.
HN commenters recommend it for Raku, DSLs, and LLM code generation, and praise features like atomic integer types. It is also cited in Perl discussions.
> isn't cpan pretty much the grandfather of "oh there's a library for that"?
The TeX CTAN in 1992 [1] was clearly the inspiration for CPAN a year or three later [2] (in both name & thing). So, maybe CTAN is the great grandfather? :-)
{ My intent is only to inform, not be disputatious. I know you said "pretty much". }
To be fair, C has an ecosystem. OS package managers/installers are a thing. There is surely a list of much >1 "core libs/programs" (terminfo/curses/some text editor/compilers/etc.) that would be in most "bare bones" OS installs upon which you could develop. One certainly depends upon OS kernels and device drivers. IMO, at least one mistake "language" package managers make is poor integration with OS package managers. Anyway you cut it, it is hard to write a program without depending upon a lot of code. Yes, some of that is more audited.
As the "lump" gets giant, dark corners also proliferate. There was a recent article [3] and HN discussion [4] about trying to have the "optimal chunkiness/granularity" in various ecosystems. I agree that it is doubtful we will solve any of that in an HN sub-to-the-Nth thread. I think that article/discussion only scratched the surface.
I will close by saying I think it's relatively uncontentious (but maybe not unanimous) that packaging has gone awry when a simple program requires a transitive closure of many hundreds of packages. FWIW, I also often write my own stuff rather than relying on 3rd parties and have…
I don't know much about Perl but am aware of Tau Station, which was launched a few months ago. I recall reading somewhere that it includes a new Perl codebase with approaching a million lines of well written modern code.[0]
Raku is a different language, a very young one that has its adoption-for-serious-applications curve mostly ahead of it. Thus you get articles like the advent one from a few weeks ago that seriously documents a serious Raku application in a notably unserious way.[1] It's apparently only 7K or 13K lines of code, depending how you count, but well written Raku code is typically a fraction of the length of well written Perl code, so there is that.[2]
[0] https://taustation.space/blog/category/technology/
[1] https://raku-advent.blog/2020/12/20/day-20-a-raku-in-the-wild/
[2] https://p6steve.wordpress.com/2020/04/17/raku-vs-perl-save-70/
I continue to be rather impressed by raku's 'Atomic Int' type plus the atomic operators (and while normally I dislike emoji in identifiers, them using the atom symbol to make the atomic operators stand out when debugging actually seems rather neat in this scenario).
See the example near the end of https://raku-advent.blog/2021/12/01/batteries-included-generating-thumbnails/ for what I mean.
Perl's maxim - there's more than one way to do it (TMTOWTDI) can make Perl easy to write but harder to read.
Thankfully LLMs can de-obfuscate even the gnarliest Perl with command line utilities like wat (https://raku-advent.blog/2024/12/02/day-2-wat-llm-coding-tool-do-you-want-for-christmas/)
There are some interesting posts on the https://raku-advent.blog this year ... certainly recommended reading for anyone interested in domain specific languages, predictacble code gen from LLMs and general -Ofun!
Very well, thank you.
You could e.g. check out this year's Advent Posts: https://raku-advent.blog/category/2021/
Or the Weekly Rakudo News: http://rakudoweekly.blog/blog-feed/