5 ms·

From my perspective (over a decade of Perl programming now doing Go): * It has no concurrency primitives that are anywhere close to other popular languages

by pravus 3y ago

From my perspective (over a decade of Perl programming now doing Go): * It has no concurrency primitives that are anywhere close to other popular languages * Tooling is good and works but is archaic, slow, and cumbersome * The community hasn't positioned itself to be anything other than lightweight backend services and small webapps (smaller than rails) * The community isn't really all that inviting or fun to be around Basically Perl offers me nothing that Go doesn't. I'm just as fast in Go as Perl and it's much easier to get stuff done. It's sad because it has some really good features that I miss but I just rewrote a final project from Perl to Go and am never looking back.

mst 3y ago
> It has no concurrency primitives that are anywhere close to other popular languages I can switch between writing async/await based $other_language and use Mojo::Base -signatures, -async_await; for my p3rl.org/Mojolicious code and keep all the same concurrency based patterns just fine. Trivial example of the sort of code I can write given that 'use' line: async sub url_body ($self, $url) { my $tx = await $self->ua->get($url); return $tx->res->body; } It's fair enough if you prefer go's lightweight threading plus channels CSP model but async/await is IMO a perfectly reasonable approach. (the -async_await feature flag is powered by p3rl.org/Future::AsyncAwait which works fine with p3rl.org/Future and p3rl.org/Future::Utils as well as p3rl.org/Mojo::Promise in a single process - and since p3rl.org/Mojo::IOLoop and p3rl.org/IO::Async will share an event loop I often find myself using things based on both since it's all await-able) p3rl.org/App::cpanminus plus p3rl.org/Carton (or my p3rl.org/App::plx) doesn't tend to be archaic or cumbersome to me (classic CPAN.pm, sure, but since cpanminus and plx are both distributed as p3rl.org/App::FatPacker bundled script s via github you can bootstrap them without ever loading CPAN.pm) - I generally find it less of an aggravation to deal with than most other languages' approaches (go's isn't bad at all, but e.g. virtualenv is very much not my cup of tea). As for slow, the main thing that makes installation from CPAN slower is that our tooling tends to run tests by default - I'm aware that these days "verifying your dependencies actually work at install time" has gone out of fashion in favour of faster installs, but if you're happy with that trade-off pretty much everything has a 'notest' flag available.
- pravus 3y ago
  Yay, more bolt-ons. Like I said, I left all this behind.
- mst 3y ago
  Far too late to edit now but I'd note that Future::AsyncAwait is implemented using only public APIs - it adds the keywords using the pluggable keyword API that was added in 5.14 and 5.16 (though while code written against the 5.14 version continues to work AFAIK given we're on verion 38 of perl5 now I wouldn't bother even looking at it except out of historical curiosity). So, basically, adding new keywords to perl via CPAN is a first class citizen and has been for over a decade now and we've gotten pretty good at it in that time (see also http://p3rl.org/Object::Pad http://p3rl.org/Object::Pad - which has acted as a proving ground for a lot of the ideas that have gone into Cor - for another good example) and while I wouldn't at all object to F::AA eventually migrating into being a core feature, from a user POV it would just mean a slightly different 'use' line and maybe a few percentage points' speedup. As such, I personally believe that while I understand that some environments have unfortunate issues with having dependencies, every other reason I've heard articulated for treating a keyword module as an inferior bolt-on as compared to a core keyword has proven unsupported in actual use. Generally I code to (a) core perl only, mostly for one-liners embedded in shell scripts and occasionally for really small stuff, (b) pure perl dependencies only so I can easily deploy a single file with App::FatPacker or no file at all with Object::Remote, and (c) this project is best done using XS stuff and I'm willing to accept the trade-offs. I'd note that Future::AsyncAwait itself sits in an interesting middle-ground because with a little help from my http://p3rl.org/Babble http://p3rl.org/Babble source transformer (needs more documentation though the current release manager has improved a lot of things over the 'just enough to do what I needed at the time' I originally released) I wrote http://p3rl.org/PerlX::AsyncAwait http://p3rl.org/PerlX::AsyncAwait which rewrites most F::AA using code successfully to pure perl for fatpacking, at the cost of you ending up with an implementation that's mildly bizarre at first look and will be substantially slower on microbenchmarks. (I say 'most' because I presume there's at least one bug and I'm certain that F::AA has added support for additional perl syntax constructs since that I've not gotten around to going back and adding yet, but so far in the situations where I want a fatpacked async/await using script badly enough PerlX::AsyncAwait has worked well -enough- overall that I've yet to feel the need to give it an overhaul even if I'm happy to admit it would probably benefit from one)
cutler 3y ago
Comparing Go to Perl is apples to oranges.

by pravus 3y ago

mst 3y ago

> It has no concurrency primitives that are anywhere close to other popular languages I can switch between writing async/await based $other_language and use Mojo::Base -signatures, -async_await; for my p3rl.org/Mojolicious code and keep all the same concurrency based patterns just fine. Trivial example of the sort of code I can write given that 'use' line: async sub url_body ($self, $url) { my $tx = await $self->ua->get($url); return $tx->res->body; } It's fair enough if you prefer go's lightweight threading plus channels CSP model but async/await is IMO a perfectly reasonable approach. (the -async_await feature flag is powered by p3rl.org/Future::AsyncAwait which works fine with p3rl.org/Future and p3rl.org/Future::Utils as well as p3rl.org/Mojo::Promise in a single process - and since p3rl.org/Mojo::IOLoop and p3rl.org/IO::Async will share an event loop I often find myself using things based on both since it's all await-able) p3rl.org/App::cpanminus plus p3rl.org/Carton (or my p3rl.org/App::plx) doesn't tend to be archaic or cumbersome to me (classic CPAN.pm, sure, but since cpanminus and plx are both distributed as p3rl.org/App::FatPacker bundled script s via github you can bootstrap them without ever loading CPAN.pm) - I generally find it less of an aggravation to deal with than most other languages' approaches (go's isn't bad at all, but e.g. virtualenv is very much not my cup of tea). As for slow, the main thing that makes installation from CPAN slower is that our tooling tends to run tests by default - I'm aware that these days "verifying your dependencies actually work at install time" has gone out of fashion in favour of faster installs, but if you're happy with that trade-off pretty much everything has a 'notest' flag available.

pravus 3y ago
Yay, more bolt-ons. Like I said, I left all this behind.
mst 3y ago
Far too late to edit now but I'd note that Future::AsyncAwait is implemented using only public APIs - it adds the keywords using the pluggable keyword API that was added in 5.14 and 5.16 (though while code written against the 5.14 version continues to work AFAIK given we're on verion 38 of perl5 now I wouldn't bother even looking at it except out of historical curiosity). So, basically, adding new keywords to perl via CPAN is a first class citizen and has been for over a decade now and we've gotten pretty good at it in that time (see also http://p3rl.org/Object::Pad http://p3rl.org/Object::Pad - which has acted as a proving ground for a lot of the ideas that have gone into Cor - for another good example) and while I wouldn't at all object to F::AA eventually migrating into being a core feature, from a user POV it would just mean a slightly different 'use' line and maybe a few percentage points' speedup. As such, I personally believe that while I understand that some environments have unfortunate issues with having dependencies, every other reason I've heard articulated for treating a keyword module as an inferior bolt-on as compared to a core keyword has proven unsupported in actual use. Generally I code to (a) core perl only, mostly for one-liners embedded in shell scripts and occasionally for really small stuff, (b) pure perl dependencies only so I can easily deploy a single file with App::FatPacker or no file at all with Object::Remote, and (c) this project is best done using XS stuff and I'm willing to accept the trade-offs. I'd note that Future::AsyncAwait itself sits in an interesting middle-ground because with a little help from my http://p3rl.org/Babble http://p3rl.org/Babble source transformer (needs more documentation though the current release manager has improved a lot of things over the 'just enough to do what I needed at the time' I originally released) I wrote http://p3rl.org/PerlX::AsyncAwait http://p3rl.org/PerlX::AsyncAwait which rewrites most F::AA using code successfully to pure perl for fatpacking, at the cost of you ending up with an implementation that's mildly bizarre at first look and will be substantially slower on microbenchmarks. (I say 'most' because I presume there's at least one bug and I'm certain that F::AA has added support for additional perl syntax constructs since that I've not gotten around to going back and adding yet, but so far in the situations where I want a fatpacked async/await using script badly enough PerlX::AsyncAwait has worked well -enough- overall that I've yet to feel the need to give it an overhaul even if I'm happy to admit it would probably benefit from one)

cutler 3y ago

Comparing Go to Perl is apples to oranges.