[muraiki]

For event-driven microservices, I think Perl 6 is actually a great choice. I have experience writing some small things in Go and Node.js, but Perl 6 offers much more powerful high-level features for handling async, concurrency, and parallelism.

Promise combinators are built into the language to provide composable concurrency. But unlike using something like Q in Node.js, you can truly perform tasks across promises in parallel (and with static typing to boot!)

Perl 6 has channels for when you want Go style semantics, but you also have Supplies for when you want their dual: instead of pushing events through channels you pull them reactively. This allows you to write highly declarative code; see https://gist.github.com/muraiki/222814d5928f648be3c1

I think that P6 will also be awesome for data munging. Here's a pipeline that processes text from a file with 4 parallel workers.

  my $lines = open('foo.json', :r).lines.hyper(batch => 20, degree => 4)
  my $filter = $lines.grep: -> $line { $line ~~ /someregex/ };
  my $json = $filter.map: &from-json;
  my $foos = $json.grep: *<some_property> == 'foo';
  say $foos.list[8];

Since the operations are done in scalar context, they essentially operate lazily, pulling one value through the chain at a time. The pipeline is only activated once coerced to list context at the end, and only enough values as are required to find the 9th match are processed.

I've used Elixir before. It has some great features and having the power of BEAM and OTP is quite awesome. But sometimes the actor model is not what you want. I think that Perl 6 will be not just a great glue language, but also a powerful language for writing multi-paradigm applications that meet the demands of modern systems.

[raiph]

Fyi, Jonathan recently wrote:

> Also, the name channel is evocative of the concept in Go, but our channels aren't like that. They don't block senders until the receiver is ready, for example. While a blocking queue is a very useful thing to have in a language, and we should keep it, we may want to stop calling it Channel, to avoid confusion (and keep the name free for something that has the Go-ish semantics).

(from https://gist.github.com/jnthn/a56fd4a22e7c43080078)

(note that most of the changes mentioned in the gist have since been implemented)