This is a consequence of money getting more expensive. When rates are low, investors pile money into non-revenue producing startups in hopes that something will return 1000x. Now rates are up and the smart money is moving elsewhere.

> Now rates are up and the smart money is moving elsewhere.

That would only explain drops in future investments, but we're seeing profitable companies with astronomical revenues from their cash cows diving into a massive firing spiral.

More importantly, growing interest rates is not exactly the definition of a downturn.

Interest rates go up, future revenue becomes less valuable, companies lay people off to add to their margins to preserve their valuations.

> Interest rates go up, future revenue becomes less valuable (...)

I don't think this is true at all. Central banks hike interest rates to limit and reign in inflation. It's the exact opposite of what you claimed.

In terms of people deciding to invest in a company, high interest rates definitely make future revenue less valuable in terms of discounted cash flow models.

Growing interest rates propagate throughout the economy. The goal of higher interest rates (aside from debt & borrowing becoming substantially more expensive) is to bring down demand and slow the economy.

Yes. As well as asbestos and occupational exposure to inhaled particles.

Also radon remediation has become more prevalent

You'd still have your token though.

You are not affected, but there are people in the world besides yourself who do things differently than you.

Huh? I thought the title was a perfect description of the article. A dude who mostly uses ruby optimizes a piece of Python code. That's it.

The "rubyist" is completely irrelevant to the article. The optimizations might apply as well in any number of languages, because they all are related to minimizing heap allocations and keeping the execution pipeline lean (e.g. by minimizing function calls).

It's fairly easy to think from the title that the article is going to be something about how clever the rubyist is compared to Python programmers or how slow Python is or some such, as an intrinsic property of "rubyists" or Python.

I think AWS needs a good UX designer. I find that using AWS can be overwhelming at first. Here's a few suggestions:

1. Take "Amazon" out of every product name. Have a look at this list for example: http://docs.aws.amazon.com/general/latest/gr/aws_service_lim... This adds nothing but clutter to the page.

2. Stop calling everything "Simple". If it's simple, people will be able to tell for themselves. Calling things simple potentially makes people feel dumb if they have a problem with it.

3. The sheer number of offerings (over 18 groups with multiple items) on the "Services" tab of the AWS management console is overwhelming. I'd have a designer see if there was a better way of organizing things.

There are only 10 or so remaining issues in the beta milestone.

When I run the benchmark in C-ruby (2.0.0) I get:

  real	2m35.450s
  user	2m35.257s
  sys	0m0.139s

On jruby with invokedynamic:

  time ruby -Xcompile.invokedynamic=true file2.rb C-large-1.in

  real	1m17.711s
  user	1m15.618s
  sys	0m0.830s

In jruby without invokedynamic time ruby file2.rb C-large-1.in

  real	1m37.856s
  user	1m39.260s
  sys	0m0.854s

Salting the password should defeat the rainbow table, right?

Using a salt would require the attacker to include an entry for each possible salt for each password candidate. If the salt is only one bit, this makes the attack take twice as long (or, requires tables twice as large). If the salt sufficiently long it makes the attack infeasible.

Thanks for this question! The answer is complicated. :D

Let me tell you first why it does not help! In order to build a rainbow table, we must be able to build a lookup table (since they're just compressed lookup tables). But a lookup table is basically a brute force attack on a certain category of passwords! So, if your password would fall to a modern rainbow table, it can be brute-forced by modern computational clusters. Salting does not change that. Intrinsically the password is no more secure than it was before. (To make it more secure, use bcrypt, scrypt, or pbkdf2. Seriously, even PHP has pbkdf2 nowadays, you have no excuse[1].)

Now let me mitigate that naysaying a bit. If you salt every password with a random 12-character base64 string, you do indeed prevent building a lookup table for the database. And that's actually not bad. Security is best measured not in bits or in operations, but in dollars. If the value of the information is much smaller than the cost to crack it, you'll defeat a rational attacker.

Rainbow tables can be built in a highly parallel way, with attackers pooling their resources and attacking multiple systems. So it will generally cost more to brute-force a password than it will to break it with a rainbow table: the rainbow table lookup can be done with one CPU; but brute forcing may require a botnet or lots of GPUs.

[1] Okay, there is one excuse: you might want to be able to do password administration from phpMyAdmin using only built-in MySQL functions. If you are stuck in this particular case the REPEAT() and SHA1 commands can have a similar effect:

    create function pw(salt char(12), password varchar(255)) returns char(40) 
        return sha1(repeat(concat(salt, sha1(password)), 100000));

but if you're not in this case, use something better.