tpsreport

base+extension@domain type mail addresses are incredibly useful for legitimate people. For starters, they can be used to track who is leaking your personal information out.

So I hope this alarmist note does not prompt anyone into banning the "+extension" email addresses.

Nice article, whose central message ("don't bundle your tools") is widely applicable to domains other than monitoring. Small, specialized tools that can be combined together is the very essence of the Unix philosophy.

For me, this was the dead giveaway that the person writing the article had no idea what he was writing about:

>Software-wise, most large porn sites will use a very-high-throughput database such as Redis to store and serve videos

No video comes out of a database. Mostly because it can't, but also because it makes no sense to make it come out of a DB.

One of the co-founders has a long diatribe about how awesome it was to have dropped out of De Paul University.

Perhaps if he had stayed in school, he would have learned how not to be a misogynist, and maybe figured out how to spell as well.

On both a very unrelated and totally related note, one of the co-founders of Kiva, Rafaello D'Andrea, dominated robo-soccer for five years.

The point here is that this particular cargo cult around bcrypt (one subscribed to by some really loud people) has a shaky foundation and does not deserve its reputation. He's offering alternatives that have been better studied.

So, by all means, subscribe to a cargo cult for crypto. But pick the cult carefully.

What a sensible change. Kudos to the git team. Most other teams would be wary of a non-backwards compatible change on such a critical path for a widely used tool.

Wow, I had no idea that the OP was in high school. Kudos to him! His blog entry is close enough to other software dev blogs in quality that I think we can leave his age, identity and personality aside, and talk about what it takes to win people over to a new language.

Let me reiterate my constructive suggestion that the OP provide actual data. I can see how the author wrote a pop book, as he is quite verbose, but any engineer can tell you that he is also quite evasive on technical questions. "What's the baseline?" should not pose a tough question for anyone writing about performance improvements.

You have a knack for producing a lot of text with no supporting evidence. Especially of a quantitative nature.

This might go over well with a certain class of people, but it offends my engineering sensibilities.

If you're unhappy with Python as a baseline comparison, pick anything else you're happy with that other people understand and compare to that.

It's not like we're setting an impossibly high bar here. Just put forward a reasonable argument for why Go is cool. "Closures like salt shakers" will not win anyone over.

I'm still not seeing you report something that says "an operation that took X ms now takes Y ms." Note the absolute numbers whose units are in seconds. That's what I'd like to see for a baseline.

And I won't even comment on the "we did this 9 months ago and did not save the data" part. That kind of stuff would not fly in medicine or science or most traditional engineering fields. Why should you be exempt?

I simply summarized your article. There is nothing wrong with not being up to handling C++'s error messages. I don't feel up to that task myself most of the time.

But your arguments for Go rang hollow. I'd urge you to go through the "pro-Go" arguments point by point and describe why, say, they apply to Go but not to Python 3.0. And I'm not a Python zealot by any means; I mention it as a comparison point mostly because it's very commonly used.

There are undoubtedly lots of great reasons to use Go, but your article did not enunciate them in a way that would win people over.

Here's a summary of the article:

* author cannot write portable C sockets code

* author cannot handle C/C++

* author believes his app would be too slow in Python, later abandons App, but retains his bias against Python

* Go has no parens for if/for

* Go has unicode support

* Go has closures "like salt shakers"

* Go is cohesively designed

* Go has nice libraries

Go may or may not be a good language, but this kind of argument is not going to win me over.