I'm so fucking glad she got fired. I hope she gets fired from life. People and their fake outrage can die in a fire, or a Walmart trampling.

Too many people overreacted on this one. You did too. Congratulations.

And no animated ads. I use adblock, but there are several sites which make unobtrusive relevant ads. I've unblocked them, and even sometimes I find something interesting enough to buy.

Ok, NOW I know how this could happen: http://thedailywtf.com/Articles/Stargate-Code-of-the-Replicators.aspx. Looks like JavaScript is the future.

Already done. http://www.3ders.org/articles/20120920-laywoo-d3-new-fdm-filament-can-print-wood-with-tree-rings.html

Most of them didn't even heard about diff...

The same could be said about mp3. Just like mp3 is compressing data in frequency domain instead of time domain, this codec changes pixel grid representation into vector representation.

But if you didn't submit translation in Italian, it wouldn't be valid in Italy. Now it will be.

Instead you need lawyers speaking in French, German and English. Which for Italian speaking inventors might be very expensive. Previously this wasn't required, because if someone wanted to have their patent valid in Italy, he had to translate it.

Significantly - you don't (typically) catch exceptions in erlang. You plan what to do after some process fails.

If your state is corrupted, you should either restart or try to fix the state. Restarting is often simpler, fixing state may even add more errors.

I did many times. What can you really do when FileReader.close() can throw an exception?

It's good design decision in this case. Consider this:
You call library function A().
Library function A() calls some function B(), but you don't know this (closed source).
Library function B() can throw some error, how can you know it? Either it should be catched in A or declared as thrown in A, so that you know that this exception CAN be thrown from A.

Not only telephony. Also in erlang you can make stateful servers, you just don't have shared state. Instead you send messages about data changes between processes. It's like many people talking and updating their knowledge of some situation.

It's only philosophy. In erlang you CAN catch errors (there is even try ... catch and throw). But typically you are encouraged to write programs so that when something fails, you just restart it. I've recently written a server in java which had errors and null pointer exceptions, but it survived, just logged the errors and restarted connection, so you CAN write something like this in other languages. Erlang just gives you some tools to make this even easier.

That's the philosophy of erlang, "Let it crash". Apparently this leads to some of the most reliable systems. http://www.erlang.org/download/armstrong_thesis_2003.pdf
Apparently OP didn't heard about it, because this is the third way.