[vessenes]

From a consumer (developer consumer) point of view, I hear you.

From a project point of view, there are some pretty strong contra-indicators in the last 20 years of language development that make this plan suspect, or at least pretty scary — both Perl and Python had extremely rocky transitions around major versions; Perl’s ultimately failing and Python’s ultimately taking like 10 years. At least. I think the last time I needed Python 2 for something was a few months ago, and before that it had been a year or so. I’ve never needed Perl 6, but if I did I would be forced to read a lot of history while I downloaded and figured out which, if any, Perl 5 modules I’m looking for got ported.

I’d imagine the numpy devs probably don’t have the resources to support what would certainly become two competing forks that each have communities with their own needs.

[librasteve]

i think it’s fair to say that perl6 has been an “extremely rocky transition” ultimately it was renamed raku to reflect this and avoid camping on the perl5 version numbering

raku has good package compatibility via Inline::Perl5 and Inline::Python and FFI to languages like Rust and Zig

among the many downsides of the transition, one upside is that raku is a clean sheet of paper and has some interesting new work for example in LLM support

I have started work on a new raku module called Dan::Polars and would welcome contributions from Numpy/Pandas folks with a vision of how to improve the APIs and abstractions … it’s a good place to make a real contribution, help make something new and better and get to grips with some raku and some rust.

just connect via https://github.com/librasteve/raku-Dan-Polars if you are interested and would like to know more

[vessenes]

Thanks for this — Perl 4 was my first serious programming language, and every five or so years I come back and check out what’s up. Seems like a quick raku tour could be fun.

One huge pain point for me in perl 5 was just how incredibly slow CPAN was compared to `go import`, like two orders of magnitude slower. I remember putting up with those times in the ‘90s because package management was a kind of miracle over FTP sites, but it’s a big ask in today’s world.

What’s raku’s story here, out of curiosity?

[librasteve]

(I suggest you start with https://raku.guide (like the Rust Book) and also take a look at https://docs.raku.org/language/5to6-nutshell)

the raku package manager - zef comes bundled with the rakudo compiler - I use https://rakubrew.org

https://raku.land is a directory of raku packages

I would say that zef is very good (it avoids the frustrations of Python package managers like pip and conda) like perl before it, raku was designed with packages and installers in mind with a concern for a healthy ecosystem

for example, all versions (via the META6.json payload descriptor) carry versioning and the module version descriptor is a built in language type https://docs.raku.org/type/Version that does stuff like this:

  say v1.0.1 ~~ v1.*.1;   # OUTPUT: «True␤»

and this

  zef install Dan::Pandas:ver<4.2.3>:auth<github:jane>:api<1>

and this

  use Dan::Pandas:ver<4.3.2+>:auth<github:jane>:api<1>;

(of course, authors must authenticate to upload modules)

[sestep]

Could you elaborate further on this? Is it not the case that they'll still need to support numpy 1.x for at least the near-term future? My understanding was the parent comment was specifically talking about the technical difficulty of multiple versions for the same Python package, not the social problem of project and community management across breaking changes.

[vessenes]

Yes, agreed they’ll need to support 1.x for (probably) quite a while, depending on API and interface changes between major versions.

My point, or at least the point I had in mind, was that the social and technical go together in a lot of subtle and sometimes surprising ways; in this case, I’d bet the idea of a second package name a) is a bad one because it’s likely to create differing community expectations about whether or not it’s okay to keep using the 1.0 package, and b) would let people feel okay not upgrading for a while / demanding security and bug fix point releases on 1.x longer than if the package itself just updates its major version.

[rovr138]

For the near term future, they can use the latest 1 version