It's funny how commenters keep clinging to Erlang as if I said it was purely functional, when I'm actually talking about writing purely functional Perl (and to the extent that it's possible, C).
That's exactly why I wrote Crypt::Util... Generating, and worse, transferring a nonce is annoying each time, so Crypt::Util just generates one unless explicitly told not to, and includes it in the ciphertext.
By being lazier (using a convenience wrapper) I have no choice but to do it right (unless I try hard), whereas if I'm too lazy to generate a nonce and put in a #FIXME i'm likely to forget it.
Unfortunately we still have to "trust" the ciphertext at least to extract the nonce, that's what my comment about 64KiB was about.
I totally agree that "refactor your problem" should be the MO for anyone trying to use crypto, but it's a little idealistic.
The problem with TLS and PGP is that they require public key cryptography, which requires key management, at least to some extent. That can add a lot of complexity to the app, even if that's not part of the domain, you often need to expose key management decisions to the user.
Secondly, a large number of people still don't understand public key encryption. Hell, they don't understand shared key encryption. Even roll-your-own managed code type software is completely flawed by design but still makes scammers a living. Technically it's no different than obfuscation (the key is in the encrypted data as metadata, after all).
TLS/GPG is hard to use, even if you're more likely to use it right if you succeed. You not only need to understand the concepts behind public key cryptography at the high level, but the low level too (the semantics of the trust models, for instance), and on top of that the engineering constraints (generating SSL certs is still a bit of a dark art).
You don't get multiple CPUs with ruby and python either.
By overriding the IO handling you can interleave IO (including DBI for drizzle and postgres).
You can interact with a normal multithreaded server by nesting the whole perl interpreter for all its coros in a single posix thread.
That said, for high volume websites there is the question of convenience. Coro is well suited for long running tasks when the concurrency is high but the load is low.
For web applications both ithreads and processes both provide more than enough concurrency because tasks are short lived, so you can reuse threads or processes quite easily.
AnyEvent and Coro are a good fit for network heavy applications that which exhibit long lived connections, especially when access to shared data simplifies things.
Perl has cooperative threads mapped to a single posix thread with Coro.
Python and Ruby both have preemptive threads on top of posix threads. A mutex ensures only one posix thread is actually running at any given point in time.
Ruby versions before 1.9 also used a single posix thread, requiring memcpy to swap the stack. Coro suffers from a similar problem (the contents of the PADLISTs of every sub found on the context stack has to be swapped in and back out).
Preemptivity for Coro can be implemented very similarly to Ruby and Python (e.g. using Async::Interrupt).
The "lightweight" that unifies all implementations is that only a single thread runs at any given point in time, even when SMP is available. This means that even though it's not a shared nothing model (like ithreads), there's no need to take a mutex or spinlock for every variable access.
Memorizing 4 variants of the perfection loop, which really isn't a general purpose knot is just plain silly.
Wikipedia is a much better resource for finding out about the different types of knots and how they relate to each other (for instance, loops and bends are usually related), and has good descriptions and interlinking so you can easily find the a handful that is easy for you to remember.
If you are more of the geek then understanding the taxonomy of knots and their engineering principle is a fun hobby (and it's much easier to remember a knot if you understand how it works). For that the Ashley Book of Knots and a few other websites are a much more interesting resource.
Interestingly, C suffers from a somewhat similar ambiguity, where not the results of runtime-at-compile-time but rather type definitions affect the parsing.
There's nothing preventing symbol table modifications done by Perl modules at compile time to be reified into some sort of linkage unit, with which a parser could then statically parse the code.
Similarly it's possible to prove that a certain block of code does nothing but link in such deterministic units, removing the nondeterminism of function prototypes.
Most of the source code out there can be parsed statically without resorting to anything drastic. The semantics of this hypothetical Perl 5 variant do differ, but as a strict subset it will still properly most of the useful code out there.
the delimitation is not for data (that is closed over like any normal closure), it's for control.
when you apply a reified delimited continuation as a function it returns a value to that call site, to do the same with a traditional continuation you need to apply the reified continuation using call-cc, and it needs to know what to do with this continuation.
this is solved ore cleanly with escape continuation/exceptions.
Perl also provides 'last LABEL', which is handy (lets you break out of any level of nesting).
I guess in a language like C where you can have neither and function calls are slow so the 'return' escape continuation is also unusable there is a reason to use goto for this.