brakl

This is a losing proposition. Because just like in Python, it may also generate endless debates on "ok, but what exactly is the idiomatic way for this particular thing here"? Is it A, or B, or maybe C? Since many are always possible, each optimizing for slightly different things, like simplicity, or maintainability, or performance, or readability, or coverage, etc. Groups may form furiously asserting that the idiomatic way must be C, others defending B, or A, and for what. Why does it matter? A young language free from cruft, after a long history of various decisions that led it on certain paths, can boldly claim such nonsense, but makes one wonder how it may look in 30 or 40 years, when other languages/ecosystems will point at its mistakes. Arguably Perl had it right all along, it's just a simple fact of life, expressed in such a generic manner that there is no need to fight it, since it's obviously true. Python's retort at the time was just clever marketing (aka lies), that worked (fooled a lot of people), it targeted Perl specifically just because that was the main competition back then.

No, I did not get that far, would've meant a larger rewrite of the ecosystem, the data files were created by other tools, already in "alternate form" [1] needing to be used by other programs as well. I stopped trying to load them with re2 (both Go and C++), after glancing over all those gigabytes of RSS, while Perl kept them in the 2-300 MB range. PCRE was a good compromise at the time, but with other tradeoffs, because C libs seem to be frowned upon in the Go community, ie. semi-official voices arguing how best to avoid them. :/ (eg: blocking inside C isn't under the gomaxprocs limit, costly overhead crossing the C boundaries, static binary troubles, less portability and so on)

#1. perl -MRegexp::Assemble -E'my @list = qw< foo fo0z bar baz >; my $rx = Regexp::Assemble->new->add( @list )->re; say $rx'

(?^:(?:fo(?:0z|o)|ba[rz]))

Go has regexps, and a very good implementation at it.

In my experience, porting code from Perl to Go, Go's regexp package is vastly inferior to Perl's, in multiple areas, speed, memory, unicode handling (eg: \b works on ascii-only in Go), etc. For example, for some large regexps handling url blacklists, reduced programmatically with Perl's awesome regexp assembly tools, I had to rely on PCRE in the end, Go just could not cope with that (not even the c++ re2). I do avoid regexps, regexps are usually best avoided, and all that, but there are areas in which they are by far the best option. In those areas, I postulate, from my own experience, that Perl's implementation is king. Speed, memory usage, Unicode.

I'd be fine with the swearing if it'd be backed up by some knowledge and experience, but that smug attitude is just incredibly irritating when coupled with such level of ignorance. First decide what are you going to bash. Some libraries, some applications, the entire programming environment ? Using induction from DBI->quote/CGI and a few old apps to bash the entire Perl ecosystem is just boringly stupid. It is fine and useful to patch those old apps, but to give an arrogant lecture as if all programmers use the same broken approaches in 2014 is just ignorant.

It is extensively documented to prefer placeholders when working with DBI, that is, if you even use DBI directly and not via an OO mapper. CGI as an approach is entirely deprecated on all languages/platforms not just Perl. List expansion ? It is a feature, use it or leave it. You have the option to use references. If you prefer Python, just use Python. It's like bashing C for having pointers. So, what else ? Try PHP with those examples. Find some Ruby apps prone to sql injection. Bash some NodeJS libraries. If Perl is dead already, be a rockstar bashing the new stuff, why even bother with the ghosts ? I think it is because deep down all Pythonistas know that Perl is a far superior platform and they all carry a deep ancestral envy. Otherwise they'd just be happy with their choice already. :)