develooper Front page | perl.perl5.porters | Postings from July 2020

Re: Announcing Perl 7

Thread Previous | Thread Next
Kent Fredric
July 3, 2020 19:20
Re: Announcing Perl 7
Message ID:
On Sat, 4 Jul 2020 at 06:29, Scott Baker <> wrote:

> As far as I know no other language requires you to opt in to latest version like this. Certainly not the languages I play in: C, C++, Python, PHP, Javascript.

Of these, neither PHP or JavaScript are extensively deployed for
"system level tasks", and so the risk of breakinging things outside
somebody's webapp are small.

C and C++ both have the benefit of a compile time isolation, which
means if you upgrade your compiler, even though your code may have
incompatibilities with the newer compiler, your existing applications
don't spontaneously break due to the upgrade.

But Perl is used for the same sort of tasks C is used for in systems,
but doesn't have the luxury of being able to avoid breakage when your
language updates.

Rust, for comparison, does have some version system where your build
chain states the edition of rust it targets, and that declaration lies
in either a config file (which is then later passed to rustc), or in a
manual invocation of rustc.

But you simply can't do that with perl, because you need to retain the
information *after* you deploy it to the target system, and it gets
re-evaulated *every* run.

So to be fair, the only thing on that list that is comparable to Perl,
in all of "scale", "usecases", and "problems with not having a compile
stage", is Python.

And the Python 2 -> Python 3 situation, as a vendor, can only be
described as "a tragedy".

Right now, quite literally hundreds of python2 packages/programs are
getting somewhat unceremoniously nuked, and users will never be able
to use them again, as a result  of their failure to adopt python3 (
due to upstream dying ).



Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About