[daotoad]

Perl 6 is designed to be a large, feature rich language that can be learned and used incrementally. The intent is that, like users of natural languages, Perl 6 practitioners gain fluency and nuance in their expression over time.

So, if you want to learn Perl6, don't worry about writing "baby talk" Perl 6. Write something that works and solves your problem. Later on you may learn that there are multiple other ways to express the same ideas you wrote already. Maybe one of them better expresses the heart of your algorithm, then you update your code.

Now, you may think, how the heck am I going to maintain code written by a bunch of people at different phases of learning Perl6?

The Perl community has responded to this challenge by putting a huge amount of work into writing excellent documentation. Perl6 docs are readily searchable and carefully indexed. It's a big, new language with lots to write about, so the docs are not yet complete, but they are already fantastic and keep getting better.

So, please, just pick a problem to solve and jump on in. The water's fine.

[SwellJoe]

Also, errors are mostly pretty good and getting better. I think a big and overlooked part of learning a new language is the quality of the errors the language provides. Some do this better than others, and some get it right in the core language but by the time you've stacked up enough libraries and extensions to get things done nicely, the errors aren't so good anymore because they talk about things at a lower level than you're thinking of them (Perl 5 can fall prey to this latter problem, even though the core language has pretty good errors these days).

[oblio]

While I encourage OP to dive in and don't want to dismiss your points, in my experience life is more about perpetual intermediates: https://blog.codinghorror.com/defending-perpetual-intermedia...

As a result, a language like Perl is very nice and maybe even artistic but in many situations downright "dangerous".

[daotoad]

Perpetual intermediates exist in every field, many of them with far more nuance than any mere programming language has to offer. The way to extract productivity from these people is the same in software development as it is in any endeavor: leadership.

Good leaders identify and propagate conventions that can keep their teams functioning in a complex millieu.

You can't get rid of the irreducible complexity of any system. You can only move it around.

In my experience, if you use an expressive language well, you can fit the code to the problem domain in a way that better communicates the underlying approach you have taken to solving the problem.

Relying on strict, small languages, like Java, means that you gain a consistency of syntax by sacrificing flexibility.

I've seen monstrous turds written in many languages, the problem in all these cases was poor or absent leadership.